JP4823306B2 - Management of media server resources in VoIP networks - Google Patents

Description

  The present invention relates to the field of management of media server resources in networks configured for use with VoIP.

  This international application claims the benefit of provisional application 60 / 674,244 filed April 22, 2005, and priority of US patent application 11 / 321,760 filed December 29, 2005. And further claims the priority of US patent application Ser. No. 11 / 321,734, filed Dec. 29, 2005.

  The use of VoIP is known. Basically, VoIP encodes a person's audible conversation (analog) into data packets (digital) that can be transmitted over an IP (Internet Protocol) network. G. using μ-law to make it possible. It involves using a codec, such as but not limited to 711. As is well known, in addition to voice, IP networks can carry other types of traffic, such as video or fax, in addition to data services (file transfer, e-mail, instant messaging, etc.). Such a converged or integrated network has economic benefits and operational benefits for network providers and users.

VoIP services can involve media-based caller interaction, usually with media servers, with devices in the network. Such an interaction may be, for example, but without limitation, a dual tone multi-frequency (DTMF) routine or a voice prompt-collect routine (eg, for a toll-free service or to retrieve voice mail) Can be used to listen to announcements or to participate in conference calls. This concept is generalized to services other than VoIP, more commonly known as SoIP (Services over IP), which can include, for example, without limitation, fax store and forward or video conferencing.
“Common VoIP Architecture” (AT & T Point Of View / VoIP, December 22, 2003)

  Logic that steers how the media server provides a particular service can be provided by the application server. The basic architecture for using application servers against media servers is well known. However, there can be many application servers that handle a larger number of media servers. Therefore, something is needed to manage media server usage for various application servers.

  Aspects of the invention relate to a method for managing media server resources assigned to a VoIP call, and more generally to a SoIP call. In some embodiments, the application server receives a service request originating from an IP node, such as a VoIP phone or other customer device. In response, the application server requests a media server resource that provides the requested service. Media server resource requests can be sent to the media server resource broker. The media server resource broker determines the appropriate media server that provides the requested service and provides that information to the application server. The application server can then cause the media server and the IP node to be connected, and the application server provides logic that allows the media server to interact with the IP node as needed.

  In another embodiment, the application server receives a service request originating from an IP node such as a VoIP phone or other customer device. In response, the application server requests a media server resource that provides the requested service. Media server resource requests can be sent to the media server resource broker. The media server resource broker determines the appropriate media server that provides the requested service and queries the media server to determine the IP address. The media server resource broker can then cause 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.

  The present invention is illustrated by way of example in the accompanying figures, in which like numerals indicate like elements, but is not limited thereto.

  As mentioned above, the architecture for providing VoIP is well known and an example is disclosed in a white paper entitled “Common VoIP Architecture”, AT & T Point Of View / VoIP, December 22, 2003, The white paper is hereby incorporated by reference in its entirety. However, there can be multiple ASs (application servers) supporting various services that handle the shared pool of MSs (media servers), motivated by the benefits of sharing.

  The use of the MS's shared pool allows for more efficient use of resources used to provide VoIP. For example, higher efficiency is possible when MS resources are managed at the regional level. As the number of managed MSs increases and the MS locations become more distributed, the efficiency that can be obtained becomes even more pronounced.

  Referring to FIG. 1, a high level schematic diagram of the system is disclosed. Note that each of the elements shown in the system can be a module that includes one or more physical or logical elements linked together. The AS 120 is shown connected to a CCE (Call Control Element) 130. In general, an AS can provide telephone system users with services such as voice mail, which can include network resources such as LDAP (Lightweight Directory Access Protocol) lookups. The AS can also handle the logic of connecting multiple parties to a multicast conference in the background, providing a script to interact with the user through providing audible prompts and collecting responses to those prompts. can do. Thus, the AS can provide the logic necessary to provide the desired service to the caller and is not limited to the use of a specific protocol when communicating with other devices. Typically, AS is programmed for a specific function. Thus, in one embodiment, the AS provides the logic needed to handle calls to the call center by providing instructions to generate one or more recorded messages, and the user It can be programmed to provide a structured response to the input and process received digits as is common in IVR (Interactive Voice Response) interfaces.

  Typically, the AS 120 does not perform media interaction with the end user itself, but can instead give instructions to the MS 160. In some embodiments, the MS 160 may include a speech recognition engine, a conference bridge, and a TTS (text to speech) engine, or play a recorded message and input by the caller Numbers can be collected to allow an individual to interact with the logic provided by AS 120.

  The AS 120 can also potentially interact directly with signals received from incoming calls, which can potentially be provided using SIP (Session Initiation Protocol). However, AS 120 can preferably use CCE (Call Control Element) to act as a proxy for AS 120. Thus, incoming calls can be routed by the CCE, and call legs can be added, modified, or deleted by the CCE under the guidance of service logic in the AS as desired. It is possible. Thus, as shown in FIG. 1, the CCE 130 allows the AS 120 to ignore details about how a call accesses or leaves the network, so the AS 120 Instead, we can concentrate on the logic about how calls are handled.

  The AS 120 can be configured not to handle incoming calls directly, but a certain amount of information from an incoming call can help provide the desired service. Thus, the AS 120 can be configured to communicate with the CCE 130. One way to communicate between AS and CCE 130 is the use of SIP. Further, the AS 120 can be configured to communicate with the MS 160 and instruct the MS 160 on how to do with media interaction with the caller. Such communications can involve, for example, without limitation, MSML (Media Session Markup Language) and MOML (Media Object Markup Language), or VXML (Voice Extensible Markup Language).

  AS 120, CCE 130, and MS 160 handle instructions and details of processing calls. However, as shown in FIG. 8, the AS 120a can interact with the MS modules 161-166, and each MS module is located in a different region. As used herein, each MS module can consist of one or more physical servers, and a region can consist of a physical location, city, county, state, or country. . For this reason, the management at the regional level manages two or more regions. It should be noted that providing MSs in different regions has the advantage of being able to serve individuals located near or within those regions without having to straddle large distances. . However, the efficient use of various MS's is simply recognizing what is happening in a particular region, so that the overall available MS resources in all regions are efficiently utilized. It becomes more complicated because it is not certain.

  It is also possible for additional ASs such as AS 120b to use MS 161-166 (for clarity, the connection between AS 120b and MS in FIG. 8 is not shown). However, AS 102a and AS 120b can operate independently, can support different services, and can be provided by different service providers, so both AS 120a and AS 120b The MS 161 cannot be expected to recognize the load applied to the MS 161 compared to other MSs.

  Thus, an MSRB (Media Server Resource Broker) 140 can be utilized to help improve resource utilization. The MSRB 140 receives a request for MS service and determines an appropriate MS to provide the requested service depending on the request and the current usage of the MS. The MSRB 140 determines the geographical origin of the call, the proximity of the call origin to the various MSs, the MS capabilities, the number of call legs that need to be supported, the type of resources required (eg, voice recognition engine Or whether digit collection is required), the length of time that the call leg is active, future reservations (eg, a given service, or the minimum capacity for a scheduled conference call to come), and Of available bandwidth, such as, but not limited to, any other parameter that may affect the use of the MS and hence the delivery of the desired service Additional parameters related to usage other than just a percentage of usage can also be considered. Some of the information used by the MSRB 140 to select the MS resource includes the type of codec required for the port, the expected time of port usage, the geographical preference, the number of ports required, the control protocol (VXML Or preference for MSCML (Media Server Control Markup Language), or MRCP (Media Resource Control Protocol), conference identification number (for scheduled conference calls), customer service being requested, or DTMF collection Can be obtained as an attribute of the request from the AS 120, such as, but not limited to, whether or not a certain 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 voice recognition capability. The request can include a demand for 100 ports over a period of 2 hours. Note that the term port as used herein is not limited to a physical port, but instead refers to a logical port. Thus, a port can be considered a unit of bandwidth, processing power, and capabilities sufficient to provide the desired service for each incoming call. Thus, the need for 100 logical ports can be met using a portion of a single physical port that has sufficient capacity to handle 100 or more calls simultaneously. In addition, MSRB does not identify and track individual port assignments, but only identifies MS addresses that can access ports of the desired type and tracks resource assignments at that level. It is enough.

  The MSRB SIP controller 145, which can be a server, can query the MSRB database 150 to identify the current usage, planned usage, and capacity of all available MSs in the network. Continuing the above example, after the MS 160 has determined that it has sufficient capacity to provide 100 ports for 2 hours, the address of the MS 160 can be provided to the AS 120 via the CCE 130. In some embodiments, the AS and CCE then set up a call leg to MS 160 directly with MS 160 via connections 122 and 164 without further involvement of MSRB 140. In an alternative embodiment, the signal flows through CCE 130 to MSRB 140 and then to MS 160. The above two methods will be described in more detail below.

  When the MSRB 140 provides the AS with the ID of the MS that can provide the requested service, the MSRB 140 stores the use of that MS in the MSRB database 150. Thus, continuing the above example, future requests for MS service take into account the fact that MS 160 has 100 ports allocated over a two hour period. MSRB 140 receives requests for all ASs that use a set of MSs on the network, and MSRB 140 keeps track of current requests and assignments of all MSs on the network based on reservations, so MSRB 140 , Which can result in higher utilization of various MSs while ensuring that the services required by each AS are provided.

  In the above example, 100 ports were requested over a period of 2 hours, but after 1 hour almost all ports can be free. For example, if the MS 160 provided an IVR to a customer who made a call in response to an advertisement such as infomercials, the number of incoming calls can be significantly reduced due to the termination of the infomercial. . AS 120 is in the call signaling path, so it knows how many call legs are connected to MS 160 at any given time. After one hour, the AS 120 handling the call related to infomercials can determine that the incoming call volume is such that only 40 ports are needed over the last hour, so the AS 120 Thus, that number of ports can be released by notifying the MSRB 140 that 60 of the ports can be returned to the MS idle pool. This approach can allow MSRB to manage network resources more efficiently and can also provide other potential benefits. As shown in the drawing, as a countermeasure against the fact that the MSRB 140 and the AS set are not synchronized due to a signal notification error or an AS failure, the MSRB 140 has one so that the actual MS usage is grasped. Alternatively, a communication path 175 is provided between a plurality of OSS (Operation Support System) 170 and the MSRB 140. OSS can provide usage updates that include factors such as per service reservation, per meeting reservation, MS planned downtime, MS unplanned downtime, MS device addition, and MS device deletion It is. In some embodiments, MS usage information may come from MS 160 to MSRB 140 via OSS 170 using path 180. In an alternative embodiment, usage information may be provided directly using path 162.

  In some embodiments, instead of reducing the number of assigned ports, AS 120 may instead request an additional port from MSRB 140, for example, if the observed call volume is higher than expected. it can.

  However, it should be noted that not all requirements may be fully met. For example, a request for X ports for a first AS is received along with a request for Y ports from a second AS and a request for Z ports from a third AS. And the sum of X, Y, and Z may exceed the capacity of N ports available on the MS. As can be appreciated, different numbers of ports are available for different MSs, and therefore can have different usage levels. If a request for X ports from the first AS is associated with a conference call and other requests are associated with an IVR, one possible response is to request a request for X ports. Allowing AS to grant a request for Y ports and a portion of the request for Z ports to the second AS and the third AS. The second AS and the third AS can then decide whether to accept the partial offer. Assuming that both the second AS and the third AS accept the partial offer, the MSRB keeps track of the number of ports assigned for each AS request.

  In addition, a request for X ports to support a conference call may overestimate (or underestimate) the number of callers connected, and the time that the call is connected is overestimated (or Underestimation). In addition, the AS can change the AS's requirements for the MSRB regarding how many ports the AS wants or the type of port that the AS wants. The MSRB also recognizes the use of the provided port by other ASs. Thus, as ports become available, they can be moved to support other ASes as appropriate.

  As shown in FIG. 1, an OSS (Operation Support System) 170 is connected to the MSRB 140. In some embodiments, the OSS 170 may request the MSRB to schedule future use of the resource in response to a request for future services. For example, an individual who plans to make a large conference call with 2000 call legs schedules the conference call in advance and all 2000 who plan to participate in the conference call. There may be a desire to ensure that people can actually join the conference call. The MSRB can also determine the preferred MS to handle the conference call based on any previously scheduled usage. It should also be noted that the MSRB can also coordinate the scheduled usage of the MS to provide a more consistent usage level for each MS. Thus, in one embodiment with a first MS and a second MS, the MSRB moves the scheduled usage before the first MS to the second MS and handles the new request. The first MS can be scheduled. Changes can also be made according to various priorities (eg, the assignment of a port to a conference call can have a higher priority than the assignment of a port to an IVR). It is. Further changes may be made in response to technical issues such as the loss of the MS. Thus, MSRB provides a robust and efficient means of utilizing MS over the network.

  As is well known in the use of VoIP technology, the underlying signaling between the BE, CCE, MS, and AS network elements, and between the BE and SIP telephones, can be a multi-protocol, eg, without limitation, SIP. H., et al. 323, or some combination of MGCP (Media Gateway Control Protocol). In some embodiments using SIP that can be used between any two of the foregoing elements, a series of request messages (eg, INVITE, BYE, ACK) and response messages (eg, 180 Alerting, 200 OK) can be used to establish and clear a media session. The SIP message carries address information that identifies the SIP signal notifying entity, for example, in the form of a SIP URI. SIP messages can also carry various types of payload information, including media information, using SDP (Session Description Protocol), in which case the SDP content includes the media receiving IP address, and the media end. Indicates things like the port number of the point and the characteristics of the media (eg, G.726 encoded audio). Media connection is established by exchanging media addresses. The media itself is transferred using a protocol such as RTP (Real Time Transport Protocol).

  Further, FIG. 1 is a diagram of a VoIP network. Elements such as BE, CCE, AS, and MS embody some typical groupings of functions found in VoIP networks. Thus, the elements should not be limited to the disclosed embodiments, but rather are directed to elements that perform the functions described. For example, in one embodiment, the BE can be a session boundary controller and can include various security functions for network external entities that can include translation between network internal addresses and network external addresses. It is possible to perform policy functions as well as protocol interworking-transcoding functions. In some embodiments, the CCE can be a call agent or a soft switch and can perform basic call processing functions, such as routing or AS calls and AS interactions. As can be appreciated, the above elements are not so limited, and other known variations of the various elements may be used as appropriate.

  Referring to FIGS. 2 and 3, an embodiment of a method for handling incoming calls is shown. First, in step 305, the telephone 210, which is an example of an IP node, transmits an INVITE message, which is a format used in SIP, to the BE 215. This message can also be provided in any other known protocol, and this message is an example of a service request. The INVITE message may include a destination address and / or some indication of the type of service desired. Next, BE 215 determines whether the incoming signaling is from an allowed IP address, or whether the requested call bandwidth is within the allowed parameters, Decide whether to accept the call. A SIP phone (such as, but not limited to, a Linksys RT41P2) is an example of a call originating device, which may be connected directly to the network or via an intermediate network. .

  Next, after accepting the call, the BE 215 sends an INVITE message to the CCE 130 at step 310. Upon receipt of the message, the CCE 130 queries the SB (Service Broker) to determine if there is a service feature associated with the TN (phone number) or other information in the INVITE. The SB can respond with the appropriate AS address. Next, at step 315, the CCE 130 sends an INVITE message to the AS 120, which is an AS associated with the TN or other information contained in the INVITE.

  In step 320, the AS 120 requests further information from the NS (network server) 220. This request, which can be a directory request, can be provided by SOAP, LDAP, SMTP, or some other protocol, and can be directed to a server in the network supported by the MSRB. It can be external to the network (eg somewhere on the Internet).

  At step 325, the AS 120 sends an INVITE message to the CCE 130 requesting MS resources and desired MS attributes. At step 340, CCE 130 forwards the request to MSRB 140. The MSRB 140 can consist of multiple servers, and the CCE 120 can send messages to different servers in a round robin manner, but the MSRB 140 keeps track of the activity of all MS resources. Note that a single logical database of activities for all MSs associated with MSRB 140 is required, as can be noted. That is, different MSRBs must not be able to use the same MS resource.

  At step 345, MSRB 140 determines the appropriate MS in view of the request and the current / planned usage level. For conference calls, it may be preferable to use a single MS to handle all call legs for a given conference. However, for IVR-type calls, multiple MSs can be used efficiently, so the MSRB 140 can be used only by different MSs depending on the existing use of those different MSs. It is possible to determine that some of the requested ports can be provided with a simple partition or with a weighted assignment.

  At step 350, the MSRB 140 provides the MS address and any other suitable information to the AS 120 via the CCE 130. If the AS request cannot be granted as asserted, the MSRB can respond in the alternative (eg, the request was asking for 100 ports in the eastern US) , 50 ports can be provided at the MS in the western United States). At step 355, AS 120 instructs CCE 130 to set up a call leg for MS 160. In step 360, the CCE 130 sends an INVITE message to the MS 160 requesting the MS 160 to join the call. At step 365, the MS 160 sends a response to the CCE 130 that 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 establish a media link. At step 380, the AS 120 provides instructions to the MS 160 to handle the phone call from 210. If the AS 120 determines that some or all of the MS resources are no longer needed, eg, the call or conference is terminated or fewer ports are needed, the AS 120 communicates with the MSRB 140 All or some number of ports can be returned to the MS idle resource pool. In some embodiments, the AS may determine that the current need for the port does not match the initial request for the number, type, or type combination of ports. In addition, the current assigned port may be needed for an additional period of time. For example, AS first begins with G. Request some ports using 711 coding, and at some point after that, 3/4 G. 711 port and 1/4 G.P. It can be determined that an assortment of 726 ports is required. The AS can send a new request to the MSRB requesting the new arrangement. What MS resources are available and the MS resources currently assigned to the conference are Depending on whether 726 can also be supported, the MSRB may request the requested G.D. from the same MS resource or from a different MS resource. Can respond to AS on 726 ports.

  The actual media stream is transmitted between the phone 210 and the MS 160 via the link 280 (via BE 215), so that the previous description can be provided in RTP (Real Time Transport Protocol) Note that this is not about the actual media stream routing, but about the request for service and the routing of the signals involved in providing the service.

  As can be appreciated, the method described above allows the MSRB to make an initial determination of the appropriate MS for a conference call for up to X legs and provide that information to the AS. From that point on, further call legs attempting to join the conference call can simply be sent by the AS to the known MS address of the MS resource handling the conference. The AS may not make a request to the MSRB for each individual call. In a separate step from the step where the AS requests MS resources from the MSRB and sets up the call leg to the MS, or clears the call leg from the MS, the MSRB This “indirect” method of using MSRB to notify has several advantages over other methods. Some of the possible benefits are: (1) If the allocated MS resource is no longer needed, it is determined by the AS rather than the MSRB that infers it from the call clear message. This may be useful, for example, in a conference situation, (2) seeking more or less resources or different resources for a call or set of calls Allowing the AS to modify the request, (3) enabling resource negotiation between the AS and the MSRB, (4) a conference call spans multiple MS physical units, and the AS Included, allowing them to link and become network elements to manage the entire conference Bets are possible. This indirect method can also be used in IVR solutions. One possible drawback of this indirect method in the case where IVR service is provided (in such a scenario, generally the MS port can be released once the call is cleared) Can be guessed), and there may be a greater delay in determining that the MS port can be released. However, this indirect method allows AS to have greater control over how resources are allocated, reduces the burden on MSRB, and the above advantages can outweigh any disadvantages. .

  The interaction between AS and MSRB can basically be viewed as a database request and a database response, where MSRB is a database. Although the above description provided details regarding communication between AS and MSRB via CCE using SIP, in an alternative embodiment, AS and MSRB can communicate directly. In some embodiments, AS and MSRB may communicate using HTTP instead of SIP. For example, the AS may request MS resources using an HTTP GET message and cause the MSRB to return those resources back to the idle pool using an HTTP POST message. As can be appreciated, any other suitable protocol can be used for direct communication between the AS and the MSRB.

  Referring to FIGS. 4 and 5, an alternate embodiment of a method for handling incoming calls is shown. Steps 504 to 520 are basically the same as steps 305 to 320 in FIG. At step 524, the AS 140 sends an INVITE to the CCE 130 that is a request for MS resources for the call and is also a request to the MS to establish the call. At step 530, CCE 130 forwards the request for MS resources and call establishment to MSRB 140, which determines that MS 160 is an appropriate MS in view of the request and known / planned usage. . At step 534, MSRB 140 sends an INVITE message to MS 160 to set up the call leg. In step 540, MS 160 accepts the incoming call request in response to MSRB 140. At step 544, the MSRB sends a response message to the AS 120 via path 460 to allow the information to pass through the CCE 130. In step 560, the AS 120 sends a call setup response message to the BE 415 via the CCE 130. At step 564, BE 415 provides a call setup response message to telephone 210. In step 570, the MS 160 obtains a script from the AS 120. At step 574, the MS 160 sends audio to the telephone 210 via the link 280 to initiate the interactive service. At step 580, the call is terminated and the MSRB 140 infers from the SIP clear signaling that the MS resource can be returned to the idle pool.

  As can be appreciated, the MSRB 140 relays the call establishment request from the AS 120 to the MS 160. Thus, for services such as IVR, this “relay” method embodiment shown in FIGS. 4-5 differs from the indirect method embodiment shown in FIGS. 2-3 in interaction with the MSRB. Bring. This relay method allows the MSRB to determine that more quickly if it can be inferred from observing the clearing of the call that the MS resource can be returned to idle. And fewer steps are involved between AS and MSRB compared to the indirect method. However, as described above, this relay method can be more restrictive than the indirect method with respect to the amount of control that the AS can exercise.

  6 and 7 provide further diagrams of the indirect method and the relay method, respectively. As can be appreciated, both methods have several advantages.

  Turning first to FIG. 6, at step 610, the AS requests MS resources. In some embodiments, the request can be to initiate a conference call that includes X ports. At step 615, the CCE forwards the request to the MSRB (which can be one or more physical servers sharing a single logical database as described above). At step 620, the MSRB determines the MS location. This determination can include a geographic component so as to minimize transmission delays. At step 625, the MSRB sends a 200 OK signal along with the address of the MS to the AS via the CCE.

  At step 630, the CCE sets up a call leg between the MS and various telephones at the request of the AS. At step 635, a control leg is set up between the AS and the MS. The control leg can either mute everything except the speaker's leg audio input, play an announcement to all conference legs, create an auxiliary conference, or N maximum volume Allows the MS to be given instructions such as mixing input from the leg. In addition, if all reserved ports are in use, the AS can request additional ports. This is usually not a problem. This is because requests can often include several additional ports to provide a safety factor. To further prevent running out of ports, a percentage of the requested number of ports can be provisionally allocated over the call period and the AS determines that those ports are not needed. Those ports can then be freed for other uses. Note that if extra ports are provided that act as a buffer for higher than expected levels of participation in a call, those ports can be shared by multiple calls.

  At step 640, the call ends. This can be determined by the end of the last call leg. When the call ends at step 640, the AS signals to the MSRB that the resource can be deallocated at step 645. In some embodiments, the signal can be a BYE message. At step 650, the previously allocated MS resource is returned to the idle pool.

  Referring now to FIG. 7, there is shown a high level diagram of the relay method, again assuming a conference call scenario. In step 705, when the first call leg for the conference enters the network, the AS sends the MS in the same message that the AS requires the MS to establish the call leg. Request resources. The request must include the type of MS resource required and the number of ports required. The request may also include information about the caller's geographic area and, if known, the expected time of the call. In the illustrated embodiment, the request is in the form of an INVITE message sent to the CCE. At step 710, the CCE sends an INVITE message with the same request information to the MSRB. At step 715, the MSRB identifies the appropriate MS location and tracks the assignment in the MSRB database so that the MS assignment is kept up to date.

  Next, at step 720, the MSRB sends an INVITE message to the MS to create a call leg. As can be appreciated, the MS can be given less information. This is because the MS does not need to determine the availability of the MS compared to other MSs. In step 725, the MS responds to the MSRB by sending a response message (eg, 200 OK) to the call setup request indicating acceptance of the call. At step 730, the MSRB provides the information to the CCE so that the caller can be connected to the MS. The signal notification path passes through the AS on the way to the CCE. Therefore, the signal notification path from the telephone to the MS passes from the BE to the CCE, passes through the AS, passes through the CCE, passes through the MSRB, and reaches the MS. Please keep in mind.

  At step 740, the MS obtains the script and required files from the AS. The script can be in VXML format, and retrieval can be accomplished via HTTP, or some other suitable protocol. At step 745, the caller and the MS interact. The media interaction that takes place on the link 280 (FIG. 4) between the MS and the phone can use any suitable protocol, such as RTP, for transmitting the audio stream in a known manner.

  When the interaction is complete, at step 750, the AS clears the call to the MS and the caller. At step 755, the MSRB observes clearing of the call and returns the MS resource to the idle pool. As can be appreciated, since the MSRB is in the signaling path to clear the call, it can be inferred from clearing the call leg that the port is no longer in use Receive a quick notification of that. However, for large conference calls, the fact that the MSRB is in the signaling path of each call leg may be likely to increase the MSRB workload.

  Thus, the indirect method may allow AS to have greater control over how the port is used, and may be preferable, for example, to handle large conference calls. However, the relay method can provide a quicker update on the status of each call leg and may be preferable to handle IVR type calls. However, it should be noted that neither method is limited to a particular type of call.

  The invention has been described with reference to preferred and exemplary embodiments of the invention. Numerous other embodiments, variations, and modifications within the scope and spirit of the appended claims will occur to those skilled in the art upon reading this disclosure.

FIG. 2 is a schematic diagram illustrating an embodiment of a system for use in delivering VoIP according to certain aspects of the present invention. FIG. 2 is a schematic diagram illustrating an embodiment of a system for use in delivering VoIP using indirect methods according to certain aspects of the present invention. FIG. 3 illustrates an embodiment of a method of using the system shown in FIG. 2 according to certain aspects of the present invention. FIG. 6 is a schematic diagram illustrating an embodiment of a system for use in delivering VoIP using a relay method according to certain aspects of the present invention. FIG. 5 illustrates an embodiment of a method of using the system shown in FIG. 4 in accordance with certain aspects of the present invention. FIG. 4 illustrates an embodiment of an indirect method according to certain aspects of the present invention. FIG. 6 illustrates an embodiment of a relay method according to an aspect of the present invention. FIG. 6 illustrates a schematic embodiment of a distributed media server set according to an aspect of the present invention.

Claims (48)

A method for providing a service to an IP node (210), comprising:
(A) receiving a service request from the IP node at the application server (120);
(B) in response to the service request, a request for a media server resources, the application server (120) the request received call control elements to determine the media server resources from (130) from the media server resource broker (140 The media server resource broker (140) is external to the application server (120) , and
(C) providing a selection of a first media server (160) to the application server using the media server resource broker, wherein the media server resource broker selects the first media server from a media server set; In response to one or more parameters relating to the request for media server resources, and the use of each of the media servers in the media server set determined by the media server resource broker (140) To do,
(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. Including methods.   The method of claim 1, wherein the media server set includes media servers in different geographic areas.   The service request in (a) includes a session initiation protocol, H.264. The method of claim 1 provided in a protocol selected from the list consisting of 323, Media Gateway Control Protocol, Skinny Client Control Protocol, MiNet, CorNet-IP, Inter-Asteriske Exchange Protocol, Skype, and Jajah.   The method of claim 1, wherein the requesting in (b) is made directly from the application server to the media server resource broker using a hypertext transport protocol. The request in (b) is:
The method of claim 1, comprising: (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 requesting in (b) includes the nature of media server usage, the number of required ports, the type of service contracted by the customer, the required port characteristics, the time of port usage, the conference call identification, the media The method of claim 1, comprising one or more attributes selected from a list consisting of a server location geographic preference and a control protocol preference to be used.   One of the one or more parameters in (c) is: the capabilities of each media server in the set, the number of ports available on each media server in the set, and each media in the set The method of claim 1, wherein the method is selected from a list comprising a server's geographical location, a current usage of each media server in the set, and a scheduled usage of each media server in the set.   The method of claim 1, wherein the establishing the call in (e) uses a real-time transport protocol.   The method of claim 1, wherein the first media server comprises a plurality of media servers. Providing the instructions in (e),
(I) use a language selected from the list consisting of media session markup language, media object markup language, media server control markup language, voice extended markup language, call control extended markup language, and media resource control protocol The method of claim 1 including sending a command. Said selecting in (c) is:
(I) providing the requested media server resource at each of the media servers in the media server set that the first media server is to provide the requested media server resource; The method of claim 1, comprising determining based on a suitable number of available ports. A method of controlling the use of a media server set,
(A) a request for media server resources comprises receiving at the application server (120) the request received call control element (130) from the media server resource broker from (140), the media server resource broker (140 ) Is external to the application server (120) , and
(B) determining the availability of the requested media server resource for each media server in the media server set;
(C) providing the address of the selected first media server (160), and the media server resource broker selects the first media server from the media server set based on the determined availability; And (d) tracking a change in the allocation level of the first media server based on the request for the media server resource.   The request in (a) includes the nature of the media server usage, the number of ports required, the type of service contracted by the customer, the characteristics of the required ports, the time of port usage, the conference call identification, the media server 13. The method of claim 12, comprising one or more attributes selected from a list comprising a geographical preference for location and a preference for a control protocol to be used. The media server resource broker includes at least one server coupled to a database module, and the tracking in (d)
13. The method of claim 12, comprising: (i) updating the allocation level record of the first media server stored in the database module.   The method of claim 12, wherein the media server set comprises a plurality of media servers located in different regions. Said 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 media server set; and (ii) satisfying the requested amount and type With respect to a media server that can provide sufficient ports, after providing the requested number of ports, selecting the first media server as the media server for which the maximum level of spare ports is available The method of claim 12 comprising:   13. The method of claim 12, further comprising: (e) receiving an update regarding the usage level of the media server, the update coming from a module selected from a list consisting of a media server (16) and an operations support system (170). the method of.   The update of the usage level is at least one selected from a list consisting of planned downtime, unplanned downtime, device addition, device deletion, reservation per service, reservation per conference, and media server usage status. The method of claim 17 comprising one factor. (E) receiving a request for a future media server resource from the media server resource broker; and (f) a planned allocation associated with the request for a future media server resource in the database module (150). The method of claim 12, further comprising: storing, wherein determining the availability of media servers in the media server set in (b) includes the planned allocation. A method of handling video conference call legs over a network,
(A) Based on the incoming call request received from the boundary element (215) associated with the first call originating device (210), the application server (120) should be connected to the conference controlled by the application server Providing a first request;
(B) in response to the first request, a first resource request for a media server resource; a call control element that has received the first resource request for a media server resource from the application server (120); the method comprising transferring from 130) to the media server resource broker (140), the media server resource broker (140) is external to the application server (120), further,
(C) receiving an address of a first media server (160) on the network from the media server resource broker; and (d) between the first call origination device and the first media server. Establishing a first call leg. The receiving in (c) is:
(I) using the media server resource broker to determine that the first media server is available to handle the request; and (ii) an address of the first media server. 21. The method of claim 20, comprising providing. Said providing in (b),
(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 requested ports, and a geographic 21. The method of claim 20, comprising location preferences.   21. The method of claim 20, further comprising: (e) providing the media server resource broker with a second resource request to change a parameter of a resource required to support the conference call. (E) receiving at the application server a second request to be connected to the conference call from a second call originating device (212); and (f) the first media server and the first 21. The method of claim 20, further comprising establishing a second call leg established between two call originating devices without querying the media server resource broker. A method for providing a service to an IP node (210), comprising:
(A) receiving a service request from the IP node at the application server (120);
(B) in response to the service request, a request for a media server resources, the application server (120) the request received call control elements to determine the media server resources from (130) from the media server resource broker (140 The media server resource broker (140) is external to the application server (120) , and
(C) using the media service resource broker to determine that a first media server (160) is available to satisfy the service request, the first media server from a media server set; Selected in response to the request for media server resources and one or more parameters related to utilization of media servers in the media server set;
(D) connecting the first media server to the IP node via the media server resource broker, and the connection is used to establish a call between the first media server and the IP node; Providing an IP address and port number to
(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. Including methods.   26. The method of claim 25, wherein the media server set includes media servers located in separate geographic areas.   The service request in (a) includes a session initiation protocol, H.264. 26. The method of claim 25, provided in a protocol selected from the list consisting of H.323, Media Gateway Control Protocol, Skinny Client Control Protocol, MiNet, CorNet-IP, Inter-Asteriske eXchange Protocol, Skype, and Jajah.   26. The method of claim 25, wherein the requesting in (b) is made directly from the application server to the media server resource broker using a hypertext transport protocol. The request in (b) is:
26. The method of claim 25, comprising: (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 requesting in (b) includes the nature of media server usage, the number of required ports, the type of service contracted by the customer, the required port characteristics, the time of port usage, the conference call identification, the media 26. The method of claim 25, comprising one or more attributes selected from a list comprising a server location geographical preference and a control protocol preference to be used.   One of the one or more parameters in (c) is: the capabilities of each media server in the set, the number of ports available on each media server in the set, and each media in the set 26. The method of claim 25, selected from a list comprising a server's geographic location, the current usage of each media server in the set, and the scheduled usage of each media server in the set.   26. The method of claim 25, wherein the establishing the call in (e) uses a real-time transport protocol.   26. The method of claim 25, wherein the first media server includes a plurality of media servers. Providing the instructions in (f),
(I) use a language selected from the list consisting of media session markup language, media object markup language, media server control markup language, voice extended markup language, call control extended markup language, and media resource control protocol 26. The method of claim 25, comprising sending a command.   26. The determination in (c) is based on the number of available ports suitable for providing the requested media server resource at each of the media servers in the media server set. the method of. A method of controlling the use of a media server set,
(A) a request for media server resources comprises receiving at the application server (120) the request received call control element (130) from the media server resource broker from (140), the media server resource broker (140 ) Is external to the application server (120) , and
(B) determining the availability of the requested media server resource for each media server (160) in the media server set;
(C) providing an IP address and port number of the first media server to an IP node (210); and (d) an allocation level of the first media server based on the request for the media server resource. A method that includes tracking changes.   37. The method of claim 36, wherein the request in (a) is provided with a session initiation protocol.   The request in (a) includes the nature of the media server usage, the number of ports required, the type of service contracted by the customer, the characteristics of the required ports, the time of port usage, the conference call identification, the media server 37. The method of claim 36, comprising one or more attributes selected from a list comprising a geographical preference for location and a preference for a control protocol to be used. The media server resource broker includes at least one server coupled to a database module, and the tracking in (d)
37. The method of claim 36, comprising: (i) updating the allocation level record of the first media server stored in the database module.   The method of claim 36, wherein the media server set includes a plurality of media servers located in different regions. Said 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 media server set; and (ii) satisfying the requested amount and type With respect to a media server that can provide sufficient ports, after providing the requested number of ports, selecting the first media server as the media server for which the maximum level of spare ports is available 38. The method of claim 36, comprising:   37. The method of claim 36, further comprising: (e) receiving an update relating to a usage level of the media server, the update coming from a module selected from a list consisting of a media server (160) and an operations support system (170). the method of.   The update of the usage level is at least one selected from a list consisting of planned downtime, unplanned downtime, device addition, device deletion, reservation per service, reservation per conference, and media server usage status. 43. The method of claim 42, comprising one factor. (E) receiving a request for future media server resources from the media server resource broker; and (f) storing the planned use of the request in a database module (150); 37. The method of claim 36, wherein the determining the availability in b) includes the planned usage. A method for handling an interactive voice response call over a VoIP network, comprising:
(A) providing a service request received from the boundary element (215) associated with the VoIP phone (210) to the application server (120);
Request for obtaining the (b) the media server resources, the method comprising forwarding the application server media server resource broker from the call upon receiving the request for media server resources from (120) the control element (130) (140), the A media server resource broker (140) is external to the application server (120) , and
(C) identifying the IP address of the first media server (160) on the VoIP network;
(D) querying the first media server using the media server resource broker to identify an IP address and port number;
(E) connecting the first media server to the boundary element via the media server resource broker; and (f) establishing a call between the VoIP phone and the first media server. Method. Said determining in (c); and (i) comparing said request for media server resources with availability of a media server set; and (ii) said first media server from said media server set 46. The method of claim 45, comprising selecting to provide the media server resource. Said selecting in (ii) is:
47. The method of claim 46, comprising: (1) determining that the first media server has a lower allocation level than other media servers in the media server set.   46. The method of claim 45, wherein the establishing the call in (f) uses a real-time transport protocol.

Images