KR20070112475A - Managing media server resources in a voip network - Google Patents

Abstract

Methods of managing media server resources are disclosed. In an embodiment, a media server resource broker (140) receives a request for a set of media server resources from an application server (120). The media server resource broker determines the service request should be handled by a first media server (160) based on the type of request and the availability of the first media server and provides an address of the first media server to the application server. In another embodiment, an IP node (210) provides a service request. An application server (120) receives the service request and sends a request for media server resources to a media server resource broker (140). The media server resource broker determines that the request should be handled by a first media server (160). The media server resource broker queries the first media server to obtain an IP address and port number for use in establishing a call between the IP node and the first media server. The media server resource broker then provides a signal to the IP Node so that it can establish the call with the appropriate port on the media server.

Description

MANAGING MEDIA SERVER RESOURCES IN A VOIP NETWORK}

This international application claims the benefit of Provisional Application No. 60 / 674,244, filed April 22, 2005, and US Patent Application No. 11 / 321,760, filed December 29, 2005, and US Patent, filed December 29, 2005. Claims priority of application number 11 / 321,734.

The present invention relates to the field of managing media server resources in a network configured for use with VoIP.

The use of VoIP is well known. Basically, VoIP encodes an audible conversation of an (analogin) person into (digital) data packets and allows, for example, but not limited to, digital packets to be transmitted over an Internet Protocol (IP) network. It requires the use of codecs such as G.711 in the law. As is well known, IP networks may transmit not only voice, but other types of traffic such as fax or video, for example in addition to data services (file transfer, email, instant messaging, etc.). Such converged or integrated networks are economical and offer operational benefits to network providers and users.

VoIP services require media-based caller interactions with devices in the network, typically media servers. Such interactions may be, for example, but not limited to, dual tone multi-frequency (DTMF) or speech prompt-and-collect routines (eg, free telephone services or May be used for voicemail retrieval), to listen to announcements, or to participate in audio conference calls. Such a concept has been generalized to services other than VoIP, more commonly known as services over IP (SoIP) that may include, but are not limited to, for example, fax storage and delivery or video conferencing.

Logic driving of how the media server provides a particular service may be provided by an application server. The basic architecture for using application servers with media servers is well known. However, there may be many application servers used with a large number of media servers. Thus, something is needed to manage the use of media servers with respect to various application servers.

Aspects of the present invention relate to a method for managing VoIP calls, more generally media server resources allocated to SoIP. In one embodiment, the application server receives service requests originating from IP nodes such as VoIP phones or other customer equipment. In response, the application server requests media server resources to provide the requested service. The media server resource request will be forwarded to the media server resource broker. The media server resource broker determines the appropriate media server to provide the requested service and provides this information to the application server. The application server can then connect the media server and the IP node, and the application server provides the logic that allows the media server to interact with the IP node as needed.

In another embodiment, the application server receives service requests originating from IP nodes such as VoIP phones or other customer equipment. In response, the application server requests media server resources to provide the requested service. The media server resource request will be forwarded to the media server resource broker. The media server resource broker determines the appropriate media server to provide the requested service and queries the media server to determine the IP address. The media server resource broker may then allow the media server to connect to the IP node. The application server can then provide logic that allows the media server to manage calls with the IP node.

BRIEF DESCRIPTION OF THE DRAWINGS The invention is illustrated by way of example and not by way of limitation in the figures, in which like reference numerals indicate like elements.

1 illustrates schematically an embodiment of a system for use in distributing VOIP in accordance with an aspect of the present invention.

2 schematically illustrates one embodiment of a system for use in distributing VOIP using an indirect method in accordance with an aspect of the present invention.

3 illustrates an embodiment of a method using the system shown in FIG. 2 in accordance with an aspect of the present invention.

4 schematically illustrates one embodiment of a system for use in distributing VOIP using a relay method in accordance with an aspect of the present invention.

5 illustrates one embodiment of a method of using the system shown in FIG. 4 in accordance with an aspect of the present invention.

6 illustrates one embodiment of an indirect method in accordance with an aspect of the present invention.

7 illustrates an embodiment of a relay method according to an aspect of the present invention.

8 illustrates a schematic embodiment of a set of distributed media servers in accordance with an aspect of the present invention.

As noted above, the architecture for providing VoIP is well known and is disclosed in a white paper, for example, as of December 22, 2003, entitled “Common VoIP Architecture”, AT & T Point of View / VoIP. Is incorporated herein by reference in its entirety. However, there are a number of application servers AS that support various services operating as a shared pool of media server MS, where the benefits of sharing are motivated.

The use of a shared pool of MSs can make the use of the resources used to provide VoIP more efficient. For example, it is more efficient if MS resources are managed at the local level. As the number of managed MSs increases, and the more dispersed the locations of MSs, the additional efficiency that can be obtained becomes more significant.

Returning to FIG. 1, a high level schematic of the system is shown. Each of the elements shown in the system may be a module that includes one or more physical or logical elements linked together. AS 120 is shown being connected with a call control element (CCE) 130. In general, an AS may provide services to users of a telephone system, such as, for example, voicemail, and these services may include network resources, such as, for example, a lightweight directory access protocol (LDAP) lookup. have. The AS can also handle the logic behind connecting multiple parties to a multicast conference behind the scenes, providing scripts to interact with users through the provision of audible prompts and the collection of responses to these prompts. have. Thus, the AS can provide the logic needed to provide the desired services to the sender, and the use of a particular protocol in communicating with other devices is not limited. In general, the AS will be programmed for specific functionality. Thus, in one embodiment, the AS processes the call to a call center by providing instructions for playing one or more recorded messages, provides structured responses to user inputs, and an interactive voice response (IVR). It can be programmed to provide the logic needed to handle received digits common to the interfaces.

In general, AS 120 does not perform media interaction with the end-user on its own, but instead will provide instructions to MS 160. In one embodiment, MS 160 may include a speech recognition engine, a conferencing bridge, a Text-To-Speech (TTS) engine, or a recorded message Can play and collect digits entered by the caller, the individual can interact with the logic provided by the AS 120.

AS 120 may potentially interact with signals received from an incoming call, which may be provided using the Session Initiation Protocol (SIP). However, it may be desirable to use a call control element (CCE) to act as a proxy for the AS 120. Thus, incoming calls can be routed by the CCE under the direction of service logic in the AS, and call legs can be added, modified or removed by the CCE as desired. Thus, as shown in FIG. 1, CCE 130 allows AS 120 to ignore the details of how calls access or leave the network, such that AS 120 instead processes the logic of how the calls are handled. To focus on.

The AS 120 may be configured not to handle incoming calls directly, while a certain amount of information from incoming calls may help to provide the desired service. Thus, AS 120 may be configured to communicate with CCE 130. SIP is used as one of the communication methods between the AS and the CCE 130. Additionally, AS 120 may be configured to communicate with MS 160 to indicate what to do about media interaction with the sender. Such communication may be, for example, but not limited to, Media Sessions Markup Langauge (MSML), Media Objects Markup Language (MOML) or Voice eXtensible Markup Language. ; May require VXML).

AS 120, CCE 130, and MS 160 handle details of instructions and processing calls. However, as shown in FIG. 8, AS 120a may interact with MS modules 161-166, where each MS module is located in a different region. As used herein, each MS module may consist of one or more physical servers, and a region may consist of a physical location, city, city, state, or country. Thus, management at the regional level will manage more than one region. It should be noted that the provision of MSs in different areas has the advantage of providing services to individuals located in those areas without having to reach close or wide distances. However, because simply knowing what is happening in a particular region cannot guarantee that the MS resources available globally in all regions are effectively used, the efficient use of various MSs becomes more complicated.

For example, additional ASs, such as AS 120b, may also use MSs 161-166 (not shown in FIG. 8 for connections between AS 120b and MSs for clarity). However, AS 120a and AS 120b may operate independently, may support different services, may be provided by different service providers, and may be AS 120a, AS 120b or MS 161. None can expect to know the load on MS 161 for other MSs.

Thus, media server resource broker (MSRB) 140 may be used to improve resource utilization. The MSRB 140 receives requests for MS services and, based on the request and the current use of the MSs, determines an appropriate MS to provide the requested service. MSRB 140 may be, for example, but not limited to, the geographic origin of the call, the proximity of the origin of the call with the various MSs, the capabilities of the MS, the number of call legs that need to be supported, the type of resources needed (eg, , A speech recognition engine or digit collection will be required), the length of time the call leg will be active, future reservations (e.g., minimum capacity for a given service, or upcoming scheduled conference call) and the use of the MS. Other parameters may be considered and additional parameters regarding usage other than the simple rate of use of the available bandwidth, such as delivery of the desired service may be considered. Some information that the MSRB 140 employs to select MS resources may be from the AS 120, for example, but not limited to, the type of codec required for the ports, the appropriate duration of port usage, geographic preference, required ports. Number of entries, preference for control protocol (eg, VXML or Media Server Control Markup Language (MSCML) or Media Resource Control Protocol (MRCP), etc.), conference identification number (scheduled For conferences), customer service from which the request is made, or attributes of the request, such as whether DTMF collection or type of speech recognition is required.

For example, returning to FIG. 1, the MSRB SIP controller 145 can receive a request for an MS with speech recognition capability. The request may include a request for 100 ports for two hours. As used herein, it should be noted that a port is not limited to a physical port but may represent a logical port instead. Thus, a port can be considered a unit with sufficient bandwidth and processing power and capabilities to provide the desired service for each incoming call. Thus, the need for 100 logical ports can be satisfied by using part of a single physical port with sufficient capacity to handle more than 100 calls simultaneously. Moreover, it is sufficient for the MSRB to identify and track resource allocations at that level, in contrast to identifying and tracking allocations of individual ports.

 The MSRB SIP controller 145 may be a server and may query the MSRB database 150 to determine the capacity, current usage, and scheduled usage of all available MSs in the network. Continuing the above example, after determining that the MS 160 has sufficient capacity to provide 100 ports for 2 hours, the address of the MS 160 is provided to the AS 120 through the CCE 130. Can be. In one embodiment, the AS and CCE will then be directly associated with the MS 160 along the connections 122 and 164 to establish call legs to the MS 160 without requiring the MSRB 140 anymore. . In an alternative embodiment, signals will flow through the CCE 130 onto the MSRB 140 and the MS 160. These two methods will be described in more detail below.

When the MSRB 140 provides the AS with an identification of the MS that can provide the requested services, the MSRB 140 stores the usage of the MS in the MSRB database 150. Thus, following the example above, future requests for MS services will take into account the fact that MS 160 has 100 ports allocated for two hours. Because MSRB 140 receives requests for all ASs using a set of MSs in the network, and MSRB 140 knows the allocation of all MSs on the network, based on both current requests and reservations. The MSRB 140 may provide greater use of the various MSs while ensuring that the services required by each AS are provided.

In the example above, 100 ports were requested for 2 hours, but after an hour almost all ports could be free. For example, if MS 160 was providing an IVR for calling customers responding to an advertisement such as infomercial, the termination of the informative would cause the number of incoming calls to be significantly reduced. Since the AS 120 is in the call signaling path, it can know how many call legs are connected to the MS 160 at any time. After an hour, the AS 120 handling the calls to the informal may determine that the incoming call volume needs only 40 ports for the rest of the hour, so that the AS 120 has many of the MS idle pools idle. 60 of the ports will be free by notifying MSRB 140 that it may be returned to the pool. This approach allows the MSRB to manage network resources more efficiently, and can also provide other potential benefits. As described, the communication path 175 is one such that the MSRB can track actual MS usage as a precautionary measure for the AS set and MSRB 140 out of sync due to such things as signaling errors or AS failures. It is provided between the above Operations Support Systems (OSS) 170 and the MSRB 140. The OSS can provide usage updates including elements such as, for example, reservations per service, reservations per meeting, MS scheduled downtime, MS unplanned downtime, MS equipment additions, and MS equipment deletions. have. In one embodiment, the MS usage information may come from the MS 160 via the OSS 170 to the MSRB 140 using the path 180. In alternative embodiments, the usage information may be provided directly using the route 162.

In one embodiment, for example, if the observed call volume is more than expected, instead of reducing the number of assigned ports, AS 120 may instead request additional ports from MSRB 140.

However, note that not all requests are met. For example, a request for X ports may be received at a first AS with a request from a second AS for Y ports and a request for Z ports from a third AS, where X, The sum of Y and Z may exceed the capacity of the N ports available on the MS. As can be seen, different MSs have different numbers of available ports and thus can have different usage levels. If the request for X ports from the first AS is for a conference call and the other requests are for an IVR, then one possible response provides a request for X ports to the AS and Y and Z ports. Provide some of the requests to the second and third ASs. The second and third ASs can then decide whether to accept the partial provision. If both the second and third ASs accept a partial offer, the MSRB records the number of ports allocated for each AS request.

In addition, a request for X ports to support a conference may overestimate (or underestimate) the number of callers to be connected, and also overestimate (or underestimate) the time of calls to be connected. . The AS can also change the request for the number and types of ports desired for the MSRB. The MSRB also knows the use of ports provided by other ASs. Thus, if ports are appropriate when used, they may be moved to support other ASs.

As shown in FIG. 1, an operational support system (OSS) 170 is connected to the MSRB 140. In one embodiment, OSS 170 may, in response to a request for future services, request the MSRB to schedule future usage of resources. For example, an individual who is planning a large conference call with 2000 call legs may schedule a conference call ahead of time to ensure that all of the 2000 people scheduled to participate in the conference call can actually join the conference call. You may want to: The MSRB may determine that the preferred MS processes the conference call based on any prescheduled usage. It should be noted that the MSRB can also coordinate the scheduled use of MSs to provide a more consistent level of use of each MS. Thus, in one embodiment with the first and second MSs, the MSRB may move the pre-scheduled use of the first MS to the second MS and schedule the first MS to process the new request. Changes may also be made in response to changing priorities (eg, allocation of ports for a conference call may take precedence over allocation of ports for an IVR). Further changes can be made in response to technical issues such as the loss of the MS. Thus, the MSRB provides a strong and efficient means of using MSs on a network.

As is well known in the use of VoIP technology, the underlying signaling among BE, CCE, MS and AS network elements and between BE and SIP phones is, for example, but not limited to, SIP, H.323, or MGCP (Media Some combination of protocols, such as Gateway Control Protocol. In one embodiment using SIP, this may be employed between any two of the aforementioned elements, such as a series of request messages (eg INVITE, BYE, ACK) and response messages (eg 180 Alerting). 200 OK) may be used to establish and clear media sessions. SIP messages carry address information to identify SIP signaling entities, for example in the form of a SIP URI. SIP messages also carry various types of payload information, including media information using Session Description Protocol (SDP), in which case the SDP content may contain media reception IP addresses and media characteristics (eg, G. 726-encoded audio) and media endpoints. The exchange of media addresses establishes a media connection. The media itself is delivered using protocols such as the Real-time Transport Protocol (RTP).

Additionally, Figure 1 represents a VoIP network. Devices such as BE, CCE, AS and MS implement specific types of groupings of functions that are equipped in VoIP networks. Accordingly, these elements should not be limited to the disclosed embodiments, but rather refer to elements that perform the described functions. For example, in one embodiment, the BE may be a Session Border Controller, transcoding functions for network-external entities, various security, policy, and protocol interworking. ), Which may include translation between network-internal and network-external addresses. In one embodiment, the CCE may be a Call Agent or Softswitch, and may perform basic calls that handle functions such as routing or AS invocations and interactions, for example. As can be seen, these elements are not limited, and other variations of the various elements may be used as appropriate.

2 and 3, a method of processing incoming calls is shown. First, in step 305, phone 210 is an IP node, for example, and sends an INVITE message to BE 215, which is the format used in SIP. The message may be provided in any other well-known protocol, which is an example of a service request. The INVITE message includes some indication of the destination address and / or the type of service desired. The BE 215 then determines whether to allow the call based on the logical policy (whether incoming signaling is from the allowed IP address or whether the requested call bandwidth is within the allowed parameters). A SIP phone (eg, but not limited to, Linksys RT41P2) is an example of a call originating device, which may be directly connected to the network or connected via intermediary networks.

Next, after allowing the call, in step 310, BE 215 sends an INVITE message to CCE 130. Upon receipt of the message, the CCE 130 queries the service broker (SB) to determine if there is any service feature associated with the telephone number (TN) or other information in the INVITE. can do. The SB may respond with the address of the appropriate AS. Thereafter, in step 315, CCE 130 sends an INVITE message to AS 120, which is an AS associated with the TN or other information contained in the INVITE.

In step 320, the AS 120 requests additional information from a network server (NS) 220. This request may be a directory request, may be provided by SOAP, LDAP, SMTP, or other protocols, and may be directed to a server within the network supported by the MSRB or outside the network (eg somewhere on the Internet). .

At step 325, AS 120 sends an INVITE message to CCE 130 requesting MS resources and desired MS attributes. In step 340, the CCE 130 forwards the request to the MSRB 140. The MSRB 140 may consist of multiple servers, and the CCE 130 may send a message to different servers in a round-robin fashion, although the MSRB 140 may be responsible for all of the MS resources. In order to be able to track activity, a single logical database of activities for all MSs associated with MSRB 140 is required. In other words, it should be noted that different MSRBs cannot use the same MS resources.

In step 345, MSRB 140 determines the appropriate MS in light of the request and the current / scheduled usage levels. In conferences, it would be preferable to use a single MS to handle all call legs in a given conference. However, multiple MSs can be used efficiently in IVR type calls, so the MSRB 140 is based on the existing use of the various MSs in a pure split or weighted allocation, where different MSs are requested ports. It can be determined that some of them can be provided.

In step 350, MSRB 140 provides the MS address and other appropriate information to AS 120 via CCE 130. If the AS request cannot be accepted as mentioned, the MSRB can alternatively respond (eg, while the request was for 100 in the eastern US, 50 ports can be provided in the western MS). . At step 355, AS 120 instructs CCE 130 to establish a call leg with MS 160. In step 360, the CCE 130 sends an INVITE message to the MS 160 and requests the MS 160 to join the call. In step 365, MS 160 sends a response to CCE 130 and accepts the call. At step 370, CCE 130 relays the response to BE 215. At step 375, the BE sends a response to the phone 210 so that the phone 210 and the MS 160 can establish a media link. At step 380, AS 120 provides instructions for MS 160 to handle a telephone call from phone 210. If the AS 120 determines that some or all of the MS resources are no longer needed, for example, if the call or conference is over or if ports are rarely needed, then the MSRB 140 may return all or a portion of the ports to the MS idle resource pool. Will communicate). In one embodiment, the AS may determine whether the current need for ports matches the initial request for the number, type, or mixture of types of ports. In addition, currently-assigned ports may require additional time. For example, the AS may initially request some ports with G.711 coding, and next time determine that a mix of G.711 ports 3/4 and G.726 ports 1/4 is required. . The AS may send a new request to the MSRB requesting a new mix. Based on which MS resources are available and whether the MS resources currently allocated for that conference can support G.726, the MSRB can connect to the AS with requested G.726 ports from the same MS resources or from different MS resources. You can respond.

The actual media stream travels between the phone 210 and the MS 160 via the link 280 (via the BE 215), so that the above description is directed to the service provided rather than the routing of the actual media stream. It is to be noted that the present invention relates to routing requests for related services and signals, which may be provided in a real time transport protocol (RTP).

As can be seen, the method described above allows the MSRB to initially determine the appropriate MS for the conference call up to X legs and provide information to the AS. From this, additional call legs wishing to join the conference call can simply be sent by the AS to an MS address that already knows about the MS resources handling the conference. The AS does not have to request the MSRB for each individual call. This "indirect" method using MSRB has several advantages over other methods, where the AS separates from requesting MS resources from the MSRB, establishing call legs from the MS, or removing call legs from the MS. Informed steps inform the MSRB when MS resources are no longer available. Some possible advantages may include the following. (1) In contrast to the MSRB inferring it from call clearing messages, it allows the AS to determine when allocated MS resources are no longer needed-for example, may be useful in a conference situation. (2) Allow the AS to modify the request for some or different resources for the call or set of calls. (3) Allow resource negotiation between AS and MSRB. (4) Allows conference calls to connect to multiple MS physical units, and allows the AS to be a network element that links them together and manages the conference as a whole. Indirect methods can also be used in IVR solutions. One possible drawback of the indirect method when IVR services are provided (in this scenario, it can be generally inferred that the MS port can be free when the call is dropped) determines that the MS port can be free. This can cause a lot of delays. However, the indirect method allows the AS to tightly control how to allocate resources and reduce the burden on the MSRB, and these advantages can outweigh other disadvantages.

The interaction between the AS and the MSRB can basically be regarded as database requests and responses, where the MSRB becomes the database. Although the foregoing description provides details about the communication between the AS and MSRB over the CCE using SIP, in an alternative embodiment, the AS and MSRB may communicate directly. In one embodiment, the AS and the MSRB can communicate using HTTP instead of SIP. For example, an AS may use HTTP GET messages to request MS resources and use HTTP POST messages to cause the MSRB to return them to an idle pool. As can be appreciated, any other suitable protocol may be used for direct communication between the AS and the MSRB.

4 and 5, an alternative embodiment of a method for handling incoming calls is shown. Steps 504 through 520 are essentially the same as steps 305 through 320 of FIG. 3. In step 524, the AS 140 sends an INVITE to the CCE 130, which is accompanied by both a request of MS resources for that call and a request to establish the call to the MS. In step 530, CCE 130 forwards the request for MS resources and call establishment to MSRB 140, which determines that MS 160 is appropriate in light of the request and known / scheduled use. In step 534, MSRB 140 sends an INVITE message to MS 160 to set up the call leg. At step 540, MS 160 accepts the incoming call request in response to MSRB 140. In step 544, the MSRB forwards the response message to the AS 120 via the path 460 such that information is passed through the CCE 130. In step 560, the AS 120 sends a call setup response message to the BE 415 via the CCE 130. In step 564 BE 415 provides call establishment response messages to phone 210. At step 570, MS 160 retrieves the script from AS 120. At step 574, MS 160 sends audio to phone 210 via link 280 to initiate a two-way service. At step 580, the call ends and the MSRB 140 infers from the SIP remove signaling that the MS resource can return to the idle pool state.

As can be seen, the MSRB 140 relays call establishment requests from the AS 120 to the MS 160. Thus, for services such as IVR, the embodiment of this "relay" method shown in Figures 4-5 provides a different interaction with the MSRB compared to one embodiment of the indirect method shown in Figures 2-3. The relay method allows the MSRB to determine more quickly that MS resources can return to idle if the call elimination can be inferred from what is observed, and fewer steps between the AS and the MSRB compared to the indirect method. I need to listen. However, the relay method may be more limited than the indirect method in terms of the amount of control the AS can use, as described above.

6 and 7 further illustrate the indirect method and the relay method, respectively. As can be seen, both methods have certain advantages.

First, referring to FIG. 6, at step 610, the AS requests MS resources. In one embodiment, the request may be to initiate a conference call that includes X ports. In step 615, the CCE forwards the request to the MSRB (as described above, this can be one or more physical servers sharing a single logical database). In step 620, the MSRB determines the MS location. This decision may include geographic elements to minimize transmission delay. In step 625, the MSRB sends a 200 OK signal along with the address of the MS to the AS via CCE.

In step 630, the CCE establishes call legs between the MS and the various phones at the request of the AS. In step 635, a control leg is established between the AS and the MS. The control leg may be used by the AS to mute all to the MS except for the leg voice input of the speaker, for example, to play a notice to all conference legs, or to create additional conferences. , Or N sounds can provide commands, such as mixing input from the largest legs. Furthermore, if all reserved ports are in use, the AS can request additional ports. This is generally not an issue, because a request can often include some additional ports to provide a safety factor. To avoid running out of ports, the ratio of the number of requested ports can be tentatively assigned during the call period, and once the AS determines that no ports are needed, they can be released for other use. . If extra ports are provided, it should be noted that this may act as a buffer against higher than the level of participation expected in the provided call, which may be shared in one or more calls.

In step 640, the call ends. This can be determined by the end of the final colleg. Once the call ends in step 640, in step 645 the AS signals the MSRB that resources may be unallocated. In one embodiment, the signal may be a BYE message. In step 650 the pre-allocated MS resources are returned to the idle pool state.

Returning to FIG. 7, a description of the high level relay method is shown, again assuming a telephone call scenario. In step 705, when the first call leg for the conference enters the network, the AS requests the MS resource with the same message requesting that the call leg be established at the MS. The request should include the type of MS resources required and the number of ports required. The request may also include information about the caller's geographic region as well as the expected time of the call, if known. In the described embodiment, the request is sent to the CCE in the form of an INVITE message. In step 710, the CCE sends an INVITE message to the MSRB with the same request information. In step 715, the MSRB determines the location of the appropriate MS and tracks the allocation in the MSRB database so that the allocation of the MS is currently maintained.

Next, at step 720, the MSRB sends an INVITE message to the MS to generate a call leg. As can be seen, less information can be provided to the MS since the MS does not need to determine its availability to other MSs. At step 725, the MS responds to the MSRB by sending a response message (eg, 200 OK) to the call establishment request indicating acceptance of the call. In step 730, the MSRB provides this information to the CCE so that the caller can connect to the MS. Note that the signaling path passes through the AS on the way to the CCE, so the signaling path from the phone to the MS passes from the BE to CCE-> AS-> CCE-> MSRB-> MS.

In step 740, the MS retrieves the necessary files and scripts from the AS. The script may be in VXML format and retrieval may be accomplished via HTTP or other suitable protocol. In step 745, the caller and the MS interact. Media interaction may take place on the link 280 (FIG. 4) between the MS and the phone, and may use any suitable protocol, such as RTP, to transmit the audio stream in a known manner.

Once the interaction is complete, at step 750 the AS removes the call to the MS and the caller. In step 755, the MSRB learns to remove the call and returns the MS resources to the idle pool. As can be appreciated, since the MSRB is in the signaling path to remove the call, the MSRB receives this as a quick notification when it can be inferred from the removal of the call leg that the port is no longer used. However, in large conferences, the fact that the MSRB is in the signaling path of each call leg can increase the workload of the MSRB.

Thus, indirect methods can allow the AS to have more control over how and where the ports are used, for example in handling large conference calls. However, the relay method can update the status of each call leg more quickly and may be desirable to handle IVR type calls. However, it should be noted that neither of these methods is limited to a particular type of call.

The invention has been described in terms of its preferred and exemplary embodiments. Many other embodiments, changes, and modifications will occur to those skilled in the art within the scope and spirit of the accompanying claims.

Claims (48)

In the method for providing services to IP node 210, (a) receiving a service request from an IP node at the application server 120; (b) requesting media server resources from a media server resource broker 140 in response to the service request; (c) using the media server resource broker to provide a selection of a first media server 160 to the application server, wherein the media server resource broker is the set of media servers and the request for media server resources. Using the media server resource broker to select the first media server from the set of media servers in response to one or more parameters regarding the use of the media servers; (d) establishing a call between the IP node and the first media server; And (e) providing instructions for managing the call from the application server to the first media server. The method of claim 1, And wherein said set of media servers comprises media servers in separate geographic regions. The method of claim 1, In (a), the service request includes Session Initiation Protocol, H.323, Media Gateway Control Protocol, Skinny Client Control Protocol, MiNet, CorNet-IP, and Inter. A service providing method provided by a protocol selected from the list consisting of Asterisk eXchange Protocol, Skype, and Jajah. The method of claim 1, and (b) the requesting step is made directly from the application server to the media server resource broker using a HyperText Transport Protocol. The method of claim 1, In (b) the request step, (i) sending an INVITE message to the call control element; And (ii) sending a second invite message from the call control element to the media server resource broker. The method of claim 1, The requesting step in (b) may include the nature of the media server usage, the number of ports required, the type of customer-subscribed service, the characteristics of the ports required, the duration of the port usage, the conference call identification, the And one or more attributes selected from a list consisting of a geographic preference for the location of a media server, and a preference for the control protocol to be used. The method of claim 1, One of the one or more parameters in (c) is the performance of each media server in the set, the number of available ports of each media server in the set, the geographic location of each media server in the set, each in the set And a list consisting of the current use of the media server and the scheduled use of each media server in the set. The method of claim 1, The establishment of the call in (e) uses a real time transport protocol. The method of claim 1, And the first media server comprises a plurality of media servers. The method of claim 1, Providing the instructions in (e), (i) Media Session Markup Language, Media Object Markup Language, Media Server Control Markup Language, Voice eXtensible Sending commands using a language selected from a list consisting of a Markup Language, a Call Control eXtensible Markup Language, and a Media Resource Control Protocol; How to Provide. The method of claim 1, In step (c) the selection step, (i) the first media server should provide the requested media server resources based on the number of available ports suitable for providing the requested media resources at each media server of the set of media servers. And determining the service. A method of controlling use of a set of media servers, the method comprising: (a) receiving a request for a media server resource at the media server resource broker 140; (b) determining the availability of the requested media server resource for each media server in the set of media servers; (c) providing an address of the selected first media server 160, wherein the media server resource broker selects the first media server from the set of media servers based on the determined availability. step; And (d) tracking a change in the allocation level of the first media server, wherein the change is based on a request for the media server resource. The method of claim 12, In (a), the request is based on the nature of the media server usage, the number of ports required, the type of customer-subscribe service, the characteristics of the required ports, the duration of the port usage, the conference call identification, the location of the media server. And one or more attributes selected from a list consisting of a geographic preference, and a preference for the control protocol to be used. The method of claim 12, The media server resource broker includes at least one server coupled to a database module, and in (d) the tracking step comprises: (i) updating a record of the allocation level of the first media server stored in the database module. The method of claim 12, And the set of media servers comprises a plurality of media servers located in different regions. The method of claim 12, Determining the availability in (b), (i) comparing the number and type of requested ports with the number and type of ports available at each media server in the set of media servers; (ii) the media server having the highest level of available spare ports after providing the requested number of ports so that the media servers can provide sufficient ports for the requested quantity and type. 1 Selecting a media server. The method of claim 12, (e) receiving an update regarding a usage level of the media server, wherein the update occurs from a module selected from a list consisting of a media server (160) and an operational support system (170). The method of claim 17, The update regarding the usage level may include scheduled downtime, unscheduled downtime, equipment additions, equipment deletions, per-service reservations, per-conference reservations, and And at least one element selected from a list consisting of media server usage states. The method of claim 12, (e) receiving a request for future media server resources at the media server resource broker; And (f) storing in the database module 150 a predetermined allocation associated with the request for future media server resources, and in (b) determining the availability of the media servers in the set of media servers. And the step of including the predetermined assignment. A method of processing teleconference call legs on a network, the method comprising: (a) based on an incoming call request received from a border element 215 associated with the first call originating device 210, a first request is made to connect to the conference controlled by the application server. Providing); (b) in response to the first request, providing a first resource request for media server resources to a media server resource broker (140); (c) receiving an address of a first media server (160) on the network from the media server resource broker; And (d) establishing a first call leg between the first call originating device and the first media server. The method of claim 20, The receiving in (c) is, (i) using the media server resource broker to determine that the first media server is available for processing the request; And (ii) providing the address of the first media server. The method of claim 20, In (b) the providing step, (i) receiving a request for media server resources from an application server; And (ii) providing the request to the media server resource broker, wherein the request includes a number of required ports and a preference for a geographic location. The method of claim 20, (e) providing a second resource request to the media server resource broker, wherein the second resource request modifies a parameter of the resources required to support the conference. The method of claim 20, (e) receiving a second request at the application server to connect to the conference call from a second call originating device (212); And (f) establishing a second call leg between the first media server and the second call originating device, wherein the second call leg is established without querying the media server resource broker. , Treatment method. In the method for providing services to IP node 210, (a) receiving a service request from the IP node at an application server 120; (b) in response to the service request, requesting a media server resource from a media server resource broker (140); (c) determining with the media server resource broker that a first media server 160 is available to satisfy the service request, the first media server in a request for media server resources and a set of media servers. Determining from the set of media servers in response to one or more parameters associated with the use of the media servers; (d) connecting the first media server with the IP node through the media server resource broker, wherein the connection is a port number and an IP address for use in establishing a call between the first media server and the IP node. Providing a connection step; (e) establishing a call between the IP node and the first media server; And (f) providing instructions for managing the call from the application server to the first media server. The method of claim 25, The set of media servers includes media servers located in separate geographical regions. The method of claim 25, In (a), the service request includes Session Initiation Protocol, H.323, Media Gateway Control Protocol, Skinny Client Control Protocol, MiNet, CorNet-IP, and Inter. A service providing method provided by a protocol selected from the list consisting of Asterisk eXchange Protocol, Skype, and Jajah. The method of claim 25, and the requesting step of (b) is made directly from the application server to the media server resource broker using a HyperText Transport Protocol. The method of claim 25, The requesting step of (b), (i) sending an INVITE message to the call control element 130; And (ii) sending a second invite message from the call control element to the media server resource broker. The method of claim 25, In (b) the requesting step may include the nature of the media server usage, the number of ports required, the type of customer-subscribe service, the characteristics of the ports required, the duration of the port usage, the conference call identification, the location of the media server And one or more attributes selected from a list consisting of a geographic preference for, and a preference for the control protocol to be used. The method of claim 25, One of the one or more parameters in (c) is the performance of each media server in the set, the number of available ports of each media server in the set, the geographic location of each media server in the set, each in the set And a list consisting of the current use of the media server and the scheduled use of each media server in the set. The method of claim 25, and the establishing of the call in (e) uses a real time transport protocol. The method of claim 25, And the first media server comprises a plurality of media servers. The method of claim 25, Providing the instructions in (f), (i) Media Session Markup Language, Media Object Markup Language, Media Server Control Markup Language, Voice eXtensible Sending commands using a language selected from a list consisting of a Markup Language, a Call Control eXtensible Markup Language, and a Media Resource Control Protocol; How to Provide. The method of claim 25, in (c) the determining step is based on the number of available ports suitable for providing the requested media server resources at the respective media servers of the set of media servers. A method of controlling use of a set of media servers, the method comprising: (a) receiving a request for a media server resource at the media server resource broker 140; (b) determining the availability of the requested media server resource for each media server (160) of the set of media servers; (c) providing the IP node 210 with the number of IP addresses and ports of the first media server; And (d) tracking a change in the allocation level of the first media server, wherein the change includes the tracking step based on a request for the media server resource. The method of claim 36, and in (a), said request is provided to a Session Initiation Protocol. The method of claim 36, The request in (a) may include the nature of the media server usage, the number of ports required, the type of customer-subscribe service, the characteristics of the required ports, the duration of the port usage, the conference call identification, the location of the media server. And one or more attributes selected from a list consisting of a geographic preference for, and a preference for the control protocol to be used. The method of claim 36, The media server resource broker includes at least one server coupled to a database module, and in (d) the tracking step comprises: (i) updating a record of the allocation level of the first media server stored in the database module. The method of claim 36, And the set of media servers comprises a plurality of media servers located in different regions. The method of claim 36, Determining the availability in (b), (i) comparing the number and type of requested ports with the number and type of ports available at each media server in the set of media servers; (ii) the media server having the highest level of available spare ports after providing the requested number of ports so that the media servers can provide sufficient ports that meet the requested quantity and type. Selecting the first media server. The method of claim 36, (e) receiving an update regarding a usage level of the media server, wherein the update occurs from a module selected from a list consisting of a media server (160) and an operational support system (170). The method of claim 42, wherein The update regarding the usage level is from a list consisting of scheduled downtime, unscheduled downtime, equipment additions, equipment deletions, reservations per service, reservations per meeting, and media server usage status. And at least one element selected. The method of claim 36, (e) receiving a request for future media server resources at the media server resource broker; And (f) storing the scheduled usage of the request in a database module (150), and determining the availability in (b) comprises the scheduled usage. A method for processing a two-way voice answer call on a VoIP network, (a) providing a service request to an application server 120, the service request being received from a border element 215 associated with a VoIP phone 210; (b) providing a request for media server resources to the media server resource broker 140; (c) determining an IP address of the first media server 160 on the VoIP network; (d) querying the first media server with the media server resource broker to determine an IP address and a port number; (e) connecting the first media server to the border element through the media server resource broker; And (f) establishing a call between the VoIP phone and the first media server. The method of claim 45, The determining step of (c), (i) comparing the availability of a set of media servers with the request for media server resources; And (ii) selecting the first media server from the set of media servers to provide the media server resources. 47. The method of claim 46 wherein In (ii) the selection step, (1) determining that the first media server has a lower allocation level than other media servers in the set of media servers. The method of claim 45, and the establishing of the call in (f) uses a real-time transport protocol.

Images