Managing calls over a data network

<u>Background</u>

0001The invention relates to managing calls over a data network, such as an Internet Protocol (IP) network.

0002Packet-based data networks are widely used to link various nodes, such as personal computers, servers, gateways, and so forth. Packet-based data networks include private networks, such as local area networks (LANs) and wide area networks (WANs), and public networks, such as the Internet. The increased availability of such data networks has increased accessibility among nodes, whether the nodes are located in close proximity to each other (such as within an organization) or at far distances from each other. Popular forms of communications across such data networks include electronic mail, file transfer, web browsing, and other exchanges of digital data.

0003With the increased capacity and reliability of data networks, voice communications over data networks, including private and public networks, have become possible. Voice communications over packet-based data networks are unlike voice communications in a conventional public switched telephone network (PSTN), which provides users with dedicated, end-to-end circuit connections for the duration of each call. Communications over data networks, such as IP (Internet Protocol) networks, are performed using packets that are sent in bursts from a source to one or more destination nodes. Voice data sent over a data network has to share the network bandwidth with conventional non-voice data (e.g., electronic mail, file transfer, web access, and other traffic). One standard that has been implemented for communications of voice as well as other data is the H.323 recommendation from the Telecommunication Sector of the International Telecommunication Union (ITU-T), which describes terminals, equipment and services for multimedia communications over packet-based networks.

0004In an IP data network, each data packet is routed to a node having destination IP address contained within the header of each packet. Data packets may be routed over separate network paths before arriving at the final destination for reassembly. Transmission speeds of the various packets may vary widely depending on the usage of data networks over which the data packets are transferred. During peak usage of data networks, delays added to the transfer of voice data packets may cause poor performance of voice communications. Voice data packets that are lost or delayed due to inadequate or unavailable capacity of data networks or resources of data networks may result in gaps, silence, and clipping of audio at the receiving end.

0005A need thus exists for an improved method and system to manage the quality of voice calls or other audio communications over data networks.

<u>Summary</u>

0006In general, according to one embodiment, a method of managing calls over a data network includes determining usage information of the data network. A call request is received for establishing a call between at least two network terminals. One or more of a plurality of resource elements are selected as candidates for use in the requested call in response to the call request based on usage information of the data network.

0007In general, according to another embodiment, a method of managing calls in a telephony system includes defining a plurality of communities each including one or more communication endpoints and assigning one or more usage threshold values to a link between communities. Further, a call request is processed based on the one or more usage threshold values. The processing includes determining whether to admit the call request over the link.

0008Some embodiments of the invention may provide one or more of the following advantages. Resource elements can be selected to optimize quality of service while at the same time taking into account the usage of the data network as well as usage of other transmission or communications resources. Proper selection of resource elements as well as call admission control reduces the likelihood of overburdening links between terminals. As a result, the likelihood of delays in the communication of audio data that may lead to various audio distortions is also reduced. By efficiently using packet-based data networks for telephony and other forms of audio communications, sharing of such data networks for carrying audio data (which are relatively time sensitive) and traditional forms of digital data (such as electronic mail traffic, file transfer traffic, and other traffic) can be made more effective.

0009Other features and advantages will become apparent from the following description and from the claims.

<u>Brief Description Of The Drawings</u>

0010Figs. 1A-1B are block diagrams of an embodiment of a telephony communications system in which voice or other audio data may be communicated over packet-based data networks.

0011Fig. 2 illustrates the flow for processing a call request between an origination terminal and a destination terminal in accordance with one embodiment.

0012Fig. 3 is a flow diagram of tasks performed by a call server in response to a call request in accordance with one embodiment.

0013Fig. 4 illustrates the flow for processing a call request between an origination terminal and a destination terminal in accordance with an alternative embodiment.

0014Fig. 5 is a flow diagram of tasks performed by a call server in response to a call request in accordance with the alternative embodiment.

0015Fig. 6 illustrates components in a terminal and call server of Figs. 1 A-1 B.

0016Figs. 7A-7B illustrate E-model charts that map conditions of a network link to a desired quality of service in accordance with an embodiment.

0017Fig. 8 illustrates a flow for processing a call request in accordance with an embodiment that utilizes the E-model charts of Figs. 7A-7B.

0018Fig. 9 illustrates a telephony communications system that includes a plurality of communities and links between the communities over which call admission control is performed in accordance with an embodiment.

0019Figs. 10A-10B illustrate the flow for managing a call request between terminals in different communities of Fig. 9.

<u>Detailed Description</u>

0020In the following description, numerous details are set forth to provide an understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these details and that numerous variations or modifications from the described embodiments may be possible. For example, although the description refers to telephony communications over data networks, certain aspects of the methods and apparatus described may be advantageously used with other types of communications systems, such as those communicating video or multimedia data (for video conferencing, for example).

0021Referring to Figs. 1A and 1B, one embodiment of a telephony communications system 10 includes a number of endpoints or terminals (terminals 14, 16, and 30 illustrated) that are capable of performing voice or other audio communications over a packet-based or message-based data network 20. As used here, "telephony communications" refers to the transmission and receipt of sounds (e.g., voice or other audio signals) between different points in a system using either wireline or wireless links. Example terminals 14, 16, and 30 may include computer systems with speech capability, telephone units that include interfaces to the data network 20, gateways coupled to standard telephones 34 though a public switched telephone network (PSTN) 32, and other types of communication devices. Telephony communications can occur between any two or more terminals over the data network 20.

0022The data network 20 may include, as examples, private networks such as intranets (e.g., local area networks and wide area networks), and public networks such as the Internet. More generally, as used here, a data network is any communications network that utilizes message-based or packet-based communications. In one embodiment, the data network 20 communicates according to the Internet Protocol (IP), as described in Request for Comment (RFC) 791, entitled "Internet Protocol," dated September 1981. The data network 20 may include a single network or link or multiple networks or links that are coupled through gateways, routers, and the like.

0023In one embodiment, a call server 12 is coupled to the data network 20 to manage telephony communications (e.g., call setup, processing, and termination) between or among the terminals 14, 16, and 30 (and other terminals). A policy server 18 may be accessible by the call server 12 to determine usage policy for telephony communications over the data network 20 to control the quality of service on the data network 20. For example, the policy server 18 may set the telephony usage of the data network 20 for different time periods. During periods of expected high traffic (e.g., business hours), policy server 18 may set a low usage target for telephony communications. On the other hand, during periods of low expected traffic, the target usage of the data network 20 for telephony communications may be set higher.

0024Additionally, a network monitor system 19 may be coupled to the data network 20 to monitor certain characteristics and conditions of one or more portions of the data network 20. The characteristics and conditions monitored may include packet delays, jitter, and packet losses. Packet delay refers to a delay experienced in transmission due to high traffic or other conditions. Packet loss refers to the percentage loss of packets. Jitter refers to variations in the delay of different packets in the same transmission. Jitter may contribute to delay on a network link since receiving platforms need to buffer the received data packets to take into account the different delays of packets.

0025Although only one call server and policy server are illustrated, multiple call servers and policy servers may be coupled to the data network. In this arrangement, each of the multiple call servers may be responsible for managing call requests from a predetermined group of terminals, and each policy server may be responsible for maintaining usage policy for different portions of the data network 20. Further, more than one network monitor 19 may be included in the telephony communications system 10. For example, multiple network monitors may be located to enable monitoring of characteristics and conditions of different portions of the data network 20. A call server, policy server, and network monitor may be implemented on separate platforms or in the same platform.

0026To establish a call between two or more terminals for performing telephony communications, a call request is sent from an origination terminal to the call server 12 for processing. The call request includes the IP address of the origination terminal, the directory number of the destination terminal, and a list of one or more resource elements supported by the origination terminal to be used during an established call. A terminal may be relatively busy at the time a call is desired. As a result, processing capability and storage capability in the origination terminal may be limited so that resource elements that require high bandwidth are not indicated as being supported. Examples of resource elements include codecs (coders/decoders), the size of packets carrying audio data, and other resource elements, as explained further below.

0027By querying the policy server 18, the call server 12 determines the usage policy for the data network portions over which the call will be established and discards any resource elements that may be inconsistent with that policy. Additionally, the call server 12 can further restrict use of resource elements based on actual usage of transmission resources. Thus, for example, if a relatively large number of calls have been placed through the call server 12, the types of resource elements that may be employed for further calls may be those that have relatively low bandwidth requirements. Thus, the call server 12 is able to manage call requests based on usage information, including usage policy and/or actual usage of the data network 20.

0028Optionally, according to some embodiments, the call server 12 may also query the network monitor 19 to determine the current characteristics and conditions of the network. Selection of resource elements may thus further be based on the current characteristics and conditions of the network (e.g., delays being experienced by packets and percentage of packet loss). Next, the call server 12 ranks the remaining supportable resource elements based on predetermined merit attributes, which may include quality of service, the available bandwidth, expected usage of transmission resources, and other attributes. Selection of the resource elements to use for a particular call is based on the ranking performed by the call server 12.

0029One type of resource element is the audio coder/decoder (codec) used by each of the terminals involved in a call session. An audio codec encodes audio signals originating from an audio input device (e.g., microphone) for transmission and decodes received audio data for output to an output device (e.g., a speaker). The codec can be implemented in software. Several types of codecs are available that have varying levels of data compression and data transfer rate requirements. For example, the G.711 codec provides uncompressed communications of voice data, but has a data transfer rate requirement of 64 kbps (kilobits per second) in each direction. Other codecs, such as the G.728, G.729A, G.729, G.723.1, and G.722 have varying compression algorithms and data transfer rate requirements (which are lower than that of the G.711 codec). The listed G series of audio codecs are recommendations from the International Telecommunication Union (ITU). Other types of codecs may be supported by terminals in further embodiments.

0030Generally, higher compression leads to a reduced amount of data so that data transfer rate requirements over a link may be reduced. However, because compression of data may cause loss of information, audio quality may be adversely affected. Thus, the two objectives of higher quality audio and lower data transfer rate requirements may conflict.

0031Conventionally, an origination terminal that desires to establish a voice communication with a destination terminal sends a list of supported codecs to the destination terminal. In response, the destination terminal chooses an acceptable codec from the list. Such a process is provided by the H.323 protocol, which is a recommendation for packet-based multimedia communications systems from the ITU-T. Although such a process allows voice communications employing a commonly supported codec between the origination and destination terminals, it does not take into account the capacity and usage of the link and other transmission resources between the terminals, in this case the data network 20, as well as other transmission or communications resources.

0032Another resource element is the network packet size supported by the codec to communicate voice or other audio. As used here, network packet size refers to the size of the network packet used to carry audio data. In one embodiment, the packet includes an IP packet, which includes an IP header and IP payload. In further embodiments, other types of network packets may be employed, depending on the type of the data network 20. Inside the IP payload may be a TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) packet. A TCP or UDP packet includes a header and payload. For telephony communications, the payload of a UDP packet may include an RTP (Real-Time Transmission Protocol) packet. RTP is a protocol for the transport of real-time data, including audio and video. An RTP packet includes an RTP header and an RTP payload, which can carry one or more frames of audio data. TCP is described in RFC 793, entitled "Transmission Control Protocol," dated September 1981. UDP is described in RFC 768, entitled "User Datagram Protocol," dated August 1980. RTP is described in RFC 1889, entitled "RTP: A Transport Protocol for Real-Time Applications," dated January 1996; and RFC 1890, entitled "RTP Profile for Audio and Video Conference with Minimal Control," dated January 1996.

0033A frame refers to the duration of a speech sample. For example, a frame may be 10 milliseconds (ms), which indicates that a 10-ms sample of speech is contained in the frame. Other frames include 20 ms, 40 ms, and so forth, samples of speech. Each type of codec can support certain frame sizes. The number of frames that is placed into an RTP payload determines the size of the network packet (e.g., IP packet or other type of packet) used to carry the audio data. During a given call session, the number of frames to be carried in a network packet can be selected. The network packet size has implications on the burden placed on the data network in a given call session. Smaller network packets generally are associated with higher overhead, since more audio data packets are communicated over the data network 20 between terminals. Larger network packets are associated with reduced overhead, but come at the cost of longer delays since a longer speech sample is created between successive transmissions of audio over the data network 20. Thus, selection of network packet size (as determined by the selection of the number of frames to be carried in the packet) may also lead to a conflict between the objectives of higher quality audio and reduced load on the data network 20 and other transmission resources.

0034In accordance with some embodiments, a call control mechanism implemented in the terminals, call server(s), policy server(s), and/or network monitor(s) of the telephony communications system 10 balances the need for high audio quality as well as the need to reduce burden on the data network 20 and other transmission resources. The call control mechanism selects a supported codec, network packet size, and/or other resource element that takes into account support for the resource element by all communicating terminals, the available capacity of the data network 20 and other transmission resources, and the objective to achieve the highest possible quality of service. Additional or different criteria may be used in other embodiments.

0035An origination terminal communicates with the call server 12 over the data network 20 for call control signaling (to set up and terminate a call). After a connection is established between terminals over the data network, the terminals communicate media traffic (voice or other audio) and media traffic signaling with each other through the data network 20. The call server 12 performs call setup processing, which includes translation of dialed digits (such as 10-digit telephone number) to an IP address of a destination terminal. The call server 12 also keeps tracks of the status (e.g., busy, idle, down, and so forth) of the terminals that it is responsible for. In addition, the call server 12 keeps track of the usage of the transmission facility (the data network 20 and other transmission resources) by the telephony application. As used here, "telephony application" refers to one or more sessions of voice or other audio communications between or among the various terminals.

0036Referring to the examples of Figs. 2-5, processes for establishing a call between an origination terminal (e.g., the terminal 14, also referred to as terminal P1) and a destination terminal (e.g., the terminal 16, also referred to as terminal P2) are illustrated. In the embodiments of Figs. 2-5, the call server 12 does not access the network monitor to select resource elements. An embodiment which does is described in connection with Figs. 7A-7B and 8.

0037Fig. 2 illustrates the messages communicated between the various entities involved in call establishment, and Fig. 3 illustrates the tasks performed by the call server 12 in the call establishment process according to one embodiment. To start a call, the origination terminal 14, which has an IP address P1, sends a call request, such as a Call_Setup message, which is received (at 102) by the call server 12. The Call_Setup message includes a number identifying the destination terminal, a codec list including the codecs that are supported by the terminal 14, a list of supported packet sizes, and/or a list of other supported resource elements. Supported packet sizes are determined by the number of frames and the size of each frame (e.g., 10-ms frame 20-ms frame, and so forth). Example codecs that are supported include G.711, G.728, G.729, G.729A, G.723.1, and G.722 codecs. The G.711 codec communicates uncompressed audio data and requires a 64-kbps data transfer rate, whereas the other codecs provide varying levels of data compression with lower data transfer rate requirements. For example, the G.728 codec requires a 16-kbps transfer rate, the G.729 codec requires an 8-kbps transfer rate, and the G.723.1 codec requires a transfer rate of 6.3 kbps, 5.3 kbps, or less.

0038In the call server 12, the list of available codecs and list of supported packet sizes in the Call_Setup message are received (at 104) and combined into a candidate list. Alternatively, the different lists of resource elements may be maintained as separate candidate lists.

0039Based on the Call_Setup message, the call server 12 translates (at 106) the number (e.g., the dialed number) of the called party into an IP address (e.g., address P2 of the destination terminal 16). Next, the call server 12 sends (at 107) a query message to the policy server 18. The query message includes the IP addresses of the origination and destination terminals (P1, P2) and a request for the usage policy for a telephony application between the pair of terminals at the present time.

0040The policy server 18 responds to the query by sending a reply message back to the call server 12 to indicate the usage policy for the terminals P1 and P2 for the present call session. The usage policy information may be in the form of predetermined values representing different levels of target usage for telephony communications. Alternatively, the usage policy information may be in the form of information identifying resource elements that are supported or not supported at the present time. Based on the received usage policy information, the call server 12 updates (at 108) the candidate list by deleting unacceptable codecs. The policy server 18 may set a low usage level for the telephony application because of high traffic carrying traditional data packets (e.g., e-mail traffic, web browsing traffic, file transfer traffic, and so forth). Thus, codecs that have high bandwidth requirements may be deleted (at 108) from the candidate list. Examples of such high bandwidth codecs include the G.711 codec. In addition, unacceptable packet sizes are also deleted from the candidate list (at 108), depending on the usage policy. If low usage level is indicated, then shorter packet sizes may be deleted from the list. Thus, the call server 12 selects one or more resource elements (e.g., codecs and packet sizes) that are supported based on the usage policy of the data network 20.

0041Optionally, the call server 12 can also perform an additional bandwidth restriction based on the usage of transmission resources. Each connection between a pair of terminals shares a pool of transmission resources (links coupling the terminals that the call server 12 is responsible for, routers and gateways coupling the links, and other resources) with other applications. The call server 12 keeps track of the usage of the pool of transmission resources by tracking the number of voice calls and bandwidth usage. When the usage reaches a predetermined threshold, the call server 12 may further limit the bandwidth usage. The call server 12 may use this limitation to further delete (at 110) unacceptable codecs, packet sizes, and other resource elements from the candidate list so that a further reduced number of resource elements may be selected.

0042The call server 12 then sends (at 112) a query message, e.g., a Query_Resource_Availability message, to the destination terminal P2 to identify the supported codecs, packet sizes, and other resource elements in the destination terminal P2. The results are returned in a Reply_Resource_Availability message, from which the call server 12 can determine the codecs, packet sizes, and other resource elements supported by the destination terminal P2. The candidate list of codecs, packet sizes, and other resource elements is updated based on the available codecs in the destination terminal P2, with unsupported codecs, packet sizes, and other resource elements deleted from the candidate list.

0043Potentially, all codecs or packet sizes may have been deleted from the candidate list. If either the list of codecs or the list of packet sizes is empty (as determined at 114), then no supported codec or packet size exists to allow a call to proceed between the terminals P1 and P2, at which point the call server 12 sends (at 116) a message to terminate the call setup. The call server 12 also informs the origination terminal P1 of the setup failure.

0044If at least one codec and at least one packet size is available in the candidate list, then the call can proceed. If two or more codecs are present in the candidate list, then the codecs are reordered (at 118) by applying a merit-based codec ranking algorithm to rank the codecs in the candidate list in the descending merit order (described further below). Packet sizes may also be ordered according to a merit ranking algorithm, as may other resource elements. The codec, packet size, and other resource element having the highest relative rank is selected. Alternatively, selection may be performed by the terminals, which may be adapted to select the highest ranking resource elements from a list.

0045Next, the call server 12 sends a Call_Setup message to the destination terminal P2, with the Call_Setup message including an identifier of the calling party (either the calling terminal's telephone number or its IP address), the selected codec, packet size, and other resource element. The call server 12 then proceeds (at 122) to the remaining tasks to be performed in the call setup, including sending a Selected_Resource message identifying the selected codec, packet size, and other resource element back to the origination terminal P1. Alternatively, the codec, packet size, and other resource element may be communicated as parameters in a Setup_Connection message sent by the call server 12 to connect the call between terminals P1 and P2. A media path is then set up between the terminals P1 and P2.

0046Although reference is made to selection of several resource elements, it is contemplated that further embodiments may select fewer than all the possible types of resource elements in the call management process. For example, call server 12 may perform selection of only codecs to manage bandwidth usage and quality of service on the data network 20. In addition, if multiple call servers are present in the data network 20, then communications may occur between call servers to enable selection of resource elements for establishing a call between terminals controlled by the call servers.

0047Referring further to Figs. 4 and 5, another embodiment of performing call establishment in which a codec, packet size, and/or other resource element are selected is illustrated. Fig. 4 illustrates messages exchanged among the entities involved in the call establishment, and Fig. 5 illustrates the tasks performed by the call server 12 in accordance with this embodiment. The tasks performed in the embodiment of Fig. 5 that are common to the tasks performed in the embodiment of Fig. 3 have the same reference numbers. As with the Figs. 2-3 embodiment, the origination terminal P1 sends a Call_Setup message to the call server 12 that includes a list of available codecs, a list of packet sizes, and a list of other resource elements, which are received in a candidate list (at 104) and updated (at 108) based on the usage policy in the data network 20 for the telephony application as determined from the policy server 18. This candidate list may further optionally be updated based on an internal table in the call server 12 on the usage of transmission resources (at 110). However, instead of querying the destination terminal P2 for its available codecs and supported packet sizes, the call server 12 in this alternative embodiment determines (at 202) if the candidate list is empty at this point. If so, then a capable codec and packet size have not been found and the call setup is terminated (at 204). However, if the candidate list includes at least one codec and at least one packet size, the call server 12 reorders (at 206) the codecs and packet sizes (if more than one of each) in the candidate list according to a descending merit score. The candidate list is sent (at 208) by the caller server 12 to the destination terminal P2 in a Call_Setup message to notify the destination terminal P2 of an incoming call. At this point, the destination terminal P2 may compare the list of its supported codecs to the ones in the candidate list. The destination terminal P2 selects the codec (and other resource elements) having highest relative ranking from the candidate list that is also currently supported by the terminal P2 for the current call. If no capable codec or packet size exists, the destination terminal P2 informs the call server 12 of the rejection. The call server 12 determines (at 210) if a capable codec and packet size has been identified. If not (as determined from receipt of the rejection message from the destination terminal P2), the call setup is terminated (at 212).

0048However, if a capable codec and packet size are identified, the destination terminal P2 informs the call server 12 of the selected codec through a Call_Progress message or some other message. If the call server 12 determines that a capable codec and packet size have been selected, then the call server 12 transmits the selected codec and packet size (at 214) to the origination terminal P1 in a Setup_Connection message or some other message, such as a Select_Resource message. The call server 12 then proceeds to the remaining tasks to perform for the call setup (at 216), after which a media path is established between the origination terminal P1 and the termination terminal P2 for voice (or other audio) communications.

0049Variations of the processes described in connection with Figs. 2-5 may be performed periodically during a call session between two or more terminals. This allows modification of the selected resource element in response to increases or decreases in the available bandwidth of the data network 20 and other transmission resources, including usage of resources in the terminals themselves.

0050Referring to Fig. 6, components of an example terminal and call server are illustrated. In Fig. 6, the components of the terminal 14, 16, or 30 and call server 12 are illustrated. As noted above, the terminal 14, 16, or 30 can be one of many types of devices capable of communicating voice over the data network 20. These terminals may include computer systems, telephones that are configured to communicate over a data network, a gateway system to the public switched telephone network (PSTN), and other communications devices.

0051The layers of the terminal 14, 16, or 30 include a network interface controller 302 that is coupled to the data network 20. Above the network interface controller 302 is a network device driver 304 and a network stack 306, such as a TCP/IP or UDP/IP stack. Above the network stack 306 is an RTP layer 308 that performs various tasks associated with real time communications such as telephony communications. Incoming data from the data network 20 is received through the layers 302, 304, 306 and 308 and routed to an audio codec 310, which has been selected from a number of available codecs as discussed above. The incoming data is decoded by the codec 310 and routed to a digital-to-analog (D/A) converter 312 to produce the output at a speaker 314. Outbound data to the network 20 originates at a microphone 316 or from an application routine 318. A user can speak into the microphone 316 to communicate voice data over the data network 20. Alternatively, the application routine 318 (or some other routine) may generate voice or other audio data to be transmitted to the data network 20. Examples of this may include an automated answering application, such as a voice mail application or a voice prompt application from which users can select to access to various services.

0052From the microphone, audio signals are passed through an analog-to-digital (A/D) converter 320, which digitizes the audio signals and passes the digital audio data to the codec 310. The codec 310 encodes the data and transmits the coded data down layers 308, 306, 304, and 302 to the data network 20. The audio traffic is communicated through the data network 20 to another terminal to which the terminal 14, 16, or 30 has established a call connection.

0053In addition to the audio traffic path, a control path exists between the terminal 14, 16, or 30 and the call server 12 to set up, maintain, and terminate voice calls over the data network 20. In the terminal 14, 16, or 30 one or more application routines 318 may generate control messages that are transmitted to the call server 12 through the network stack 306, network device driver 304, network interface controller 302, and the data network 20. Control signaling from the call server 12 is similarly received through the same layers from the data network 20 back to the one or more application routines 318.

0054In the call server 12, similar layers may exist. A network interface controller 330 in the call server 12 is coupled to the data network 20. Above the network interface controller 330 is a network device driver 332 and a network stack 334, such as a TCP/IP or UDP/IP stack. One or more call processing routines 336 in the call server 12 control the management of calls between terminals that are assigned to the call server 12. The call processing routines 336 perform the establishment of calls, maintenance of calls, and termination of calls. The call processing routines 336 may also periodically determine the available usage of the data network 20, which may cause it to update the codec and packet size used by the terminals in the voice communication session over the data network 20. For example, the call server 12 may maintain a usage table 351 to keep track of the number of active telephony calls and the usage (based on selected resource elements).

0055In each terminal and call server, various software routines or modules may exist, such as the one or more application routines 318, network stack 306, and device driver 304 in the terminal 14, 16, or 30 and the one or more call processing routines 336, network stack 334, and device driver 332 in the call server 12. Instructions of such software routines or modules, and others, may be stored in storage units 344 and 349 in the terminal and call server, respectively. The storage units 344 and 349 may include machine-readable storage media including memory devices such as dynamic or static random access memories, erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs), and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; and optical media such as compact discs (CDs) or digital video discs (DVDs).

0056The instructions may be loaded and executed by control units 340 and 348 in the terminal and call server, respectively, to perform programmed acts. The control units 340 and 348 may include microprocessors, microcontrollers, application-specific integrated circuits (ASICs), programmable gate arrays (PGAs), or other control devices. The terminal 14, 16, or 30 may also include a digital signal processor 346 for performing arithmetic intensive operations such as compression and decompression operations performed by the audio codec 310.

0057The instructions of the software routines or modules may be loaded or transported into a system or device in one of many different ways. For example, code segments or instructions stored on floppy disks, CD or DVD media, the hard disk, or transported through a network interface card, modem, or other interface mechanism may be loaded into the system or device and executed as corresponding software routines or modules. In the loading or transport process, data signals that are embodied as carrier waves (transmitted over telephone lines, network lines, wireless links, cables, and the like) may communicate the code segments or instructions to the system or device.

0058The following discusses the merit-based codec ranking in accordance with one embodiment. A modified ranking system may be provided for packet size and/or other resource element selection. The call server 12 maintains a table of characteristics of each codec including the following attributes: voice quality (Q), bandwidth usage (B), and terminal DSP (e.g., digital signal processor 346 in Fig. 6) resource usage (R). The Q, B, and R attributes may contain numeric values (ranging between 0 and 1). The attribute B in one embodiment may represent the inverse of the actual bandwidth usage, that is, a higher B value indicates low bandwidth usage and a low B value indicates high bandwidth usage. A higher value of R indicates lower consumption of DSP resources. The attribute R similarly represents the inverse of the actual DSP usage. A merit factor M can be computed for each codec in the candidate list as a linear combination of the attributes Q, B, and R according to the following equation:<maths id="math0001" num=""><math display="block"><mrow><msub><mrow><mtext>M = W</mtext></mrow><mrow><mtext>Q</mtext></mrow></msub><msub><mrow><mtext> * Q + W</mtext></mrow><mrow><mtext>B</mtext></mrow></msub><msub><mrow><mtext> * B + W</mtext></mrow><mrow><mtext>R</mtext></mrow></msub><mtext> * R,</mtext></mrow></math><img file="EP1079573A2_D0001.tif" /></maths> where W_Q, W_B, and W_R are weights that are assigned to the attributes Q, B, and R, respectively. The values of the weights W_Q, W_B, and W_R may be dynamic and can be based on usage of the pool of transmission resources used for the telephony application. Thus, in one example embodiment, the values of the weights W_Q, W_B, and W_R may be assigned as following:<maths id="math0002" num=""><math display="block"><mrow><msub><mrow><mtext>W</mtext></mrow><mrow><mtext>Q</mtext></mrow></msub><msub><mrow><mtext> = (1-t) * 0.8, W</mtext></mrow><mrow><mtext>B</mtext></mrow></msub><msub><mrow><mtext> = t, and W</mtext></mrow><mrow><mtext>R</mtext></mrow></msub><mtext> = (1-t) * 0.2,</mtext></mrow></math><img file="EP1079573A2_D0002.tif" /></maths> where t is the percentage usage of the pooled transmission resources for the telephony application. The codecs in the candidate list may be arranged in descending order of the merit factor M in one embodiment, from which a codec can be selected for use in the call to be established.

0059Thus, according to one embodiment, the merit factor M is higher for codecs having relatively high audio quality (Q), low expected bandwidth (e.g., data transfer rate) usage (B), and low expected DSP usage (R). Codecs having relatively low audio quality, high expected bandwidth usage, and high DSP usage will have a lower M value. Thus, generally, the value of the merit factor M is increased with higher audio quality and decreased usage of transmission resources (e.g., links in the data network 20 and DSP 346).

0060As noted above, the telephony communication system 10 includes a network monitor 19 for monitoring various characteristics and conditions of one or more portions of the data network 20. Multiple network monitors may be present for monitoring different portions of the data network 20. The characteristics and conditions monitored include packet delay, jitter, and percentage of packet loss.

0061The network monitor 19 may perform monitoring of a network link in a number of different ways. One technique is to use a network monitor having two different nodes on a network link. One node of the network monitor can send test packets targeted to the other node in the network monitor 19. From the transmission and receipt (or lack of receipt) of test packets, the nodes of the network monitor 19 can determine the delays in transmissions of packets as well as the percentage of packet loss. The network monitor 19 can periodically communicate test packets to monitor the link on a periodic basis. Such a technique may be referred to as a static monitoring technique.

0062A dynamic technique to monitor a link is to access routers or gateways that communicate with the link. Routers and gateways maintain management information that keep track of delays being experienced with links that the routers and gateways are coupled to as well as amounts of packets that are being lost. Thus, each time a call server accesses a network monitor to request the current characteristics and conditions of a particular link, the network monitor can issue a query to a particular gateway or router to determine the current conditions.

0063In further embodiments, the network monitor 19 may also provide end-to-end delay and packet loss information based on the several classes of service that may be supported, such as those in a quality-of-service (QOS) enabled network. For example, if the data network 20 employs differential services (Diffserv) to provide QOS, different classes of packets may be defined based on assigned Diffserv code points (DSCPs). One class of packets may include packets delivering voice or other audio data. Other classes may be defined for other types of data that may be communicated through the data network 20. The different classes of packets may be routed through different queues through network nodes so that higher priority classes of packets are delivered more quickly. The network monitor 19 may track the delays and packet loss information by DSCP, with one DSCP assigned for the voice-over-IP class of service.

0064Once the packet delay and loss information is determined by the call server 12, the call server 12 can access a database of models (referred to as E-models) for each call server to determine if a codec can satisfy a desired level of quality based on the prevailing network link conditions. E-models (represented in the form of charts) may also be maintained for the other resource elements. Two E-model charts 350 and 352 are illustrated in Figs. 7A and 7B for the G.729A and G.723.1 codecs, respectively. Each E-model includes a chart mapping packet delays and percentage of packet loss to a desired quality level. In each E-model chart 350 or 352, an R value represents the desired quality of service. The call server 12 may maintain profiles and policies establishing the desired R-values of calls between different combinations of callers. For example, for internal calls within an organization, a lower quality of service (and therefore lower R value) may be established, whereas external calls are set at higher R values. Other embodiments may use different representations of the quality of audio service of codecs and other resource elements.

0065In the chart 350 for the G.729A codec, the horizontal axis represents packet delay and the vertical axis represents the R value. The curves 360A-3601 represent different percentages of packet losses. In one example, the curve 360A represents a 0% packet loss, the curve 360B represents a 0.5% packet loss, the curve 360C represents a 1% packet loss, the curve 360D represents a 1.5% packet loss, the curve 360E represents a 2% packet loss, the curve 360F represents a 3% packet loss, the curve 360G represents a 4% packet loss, the curve 360H represents an 8% packet loss, and the curve 3601 represents a 16% packet loss. Thus, as illustrated in Fig. 7A, the higher the delay and percentage packet loss, the lower the R value. In one embodiment, an R value of 90 generally indicates that users are very satisfied, an R value of 80 generally indicates that users are satisfied, an R value of 70 generally indicates that some users are dissatisfied, an R value of 60 generally indicates that many users are dissatisfied, and an R value of 50 and below generally indicate that nearly all users are dissatisfied with the level of service.

0066The chart 352 in Fig. 7B for the G.723.1 codec is similar to the chart 350 in Fig. 7A, with the curves 362A-362I representing corresponding percentages of packet loss to curves 360A-360I in Fig. 7A. Thus, given the current packet delay and percentage of packet loss, the charts of the E-models for the various codecs may be accessed to determine which codec can support the desired R value. In further embodiments, different models may be used for codec or other resource element selection.

0067Thus, referring to Fig. 8, in accordance with an alternative embodiment that uses E-model charts, such as 350 and 352, the call server 12 receives (at 370) a call request from an origination terminal. The call request may identify the resource elements, including codecs, supported by the origination terminal. The call server can perform (at 371) selection of the codecs and other resource elements based on the usage policy and usage of transmission resources, including the data network 20, as described above in connection with Figs. 2-5. This may reduce the number of codecs and other resource elements.

0068Further, based on the profiles and policies associated with the identified origination and destination terminals in the call request, the call server identifies (at 372) the target quality of service (R value). Next, the call server 12 can send (at 374) query messages to the network monitor 19 to determine the current characteristics and conditions of the network 20, including network delay and packet loss. Based on the identified delay and packet loss information, the call server 12 accesses (at 376) the E-model charts of the supported codecs. From the E-model charts, the call server 12 identifies (at 378) the codecs and other resource elements that satisfy the target R value. Next, the codecs and other resources may be ranked (at 380) as described above based on various merit attributes to enable selection of one of the codecs and other resource elements to use during the call, as described above.

0069Some embodiments of the invention may provide one or more of the following advantages. A flexible codec (and other resource element) selection strategy is provided to enforce a policy based on the codec data rate between a pair of terminals where the codec (and other resource element) selection takes into account the capacity and resource limitation of the terminals as well as network traffic load and actual transmission resource usage in each terminal. Selection of resource elements may also be based on the prevailing characteristics and conditions of the network, such as delay and packet loss. Fine policy control over telephony traffic over a data network is made available. Selection may be biased towards high voice quality when traffic is light; however, if other network traffic high, then voice quality may be reduced to reduce the load on the data network.

0070The codec and other resource element selection technique and apparatus may be used with other applications. For example, for video conferencing communications sessions over a packet-based data network, selection of video codecs may also be used to reduce load on the data network.

0071Another aspect of managing telephony communications over a data network is call admission control. A call admission procedure determines whether to accept a call request from an origination terminal. If a data network, or any portion of the data network, has become saturated with traffic (both audio and traditional data packet traffic), then further call requests may be denied to ensure some predetermined quality of service. According to one embodiment of the invention, call admissions is based on usage of links between different groups of terminals (with the groups referred to as communities). Each community includes multiple terminals that are capable of communicating with each other without being subjected to call admissions control. This is made possible by grouping terminals that are coupled to high capacity links, such as LANs. As used here, a community refers to a group of terminals that are coupled by links having relatively high bandwidth. Such terminals may be located geographically close to each other or they may be located over large distances.

0072Within each community, voice calls between terminals are allowed to proceed when requested. In one embodiment, to provide some limitation on bandwidth usage of the communication link within each community, resource element selection (such as the codec and packet size selection described above) may be used to limit the bandwidth of each call session when large numbers of call sessions are present in the community. In other embodiments, resource selection may be skipped for intra-community calls. The call admission control in some embodiments of the invention is provided for calls made between communities based on usage of the links among the communities.

0073Referring to Fig. 9, one arrangement of a voice communication system 400 that includes communities is illustrated. The illustrated multiple links between terminals are logical links, not physical links. The logical links are part of the overall data network, with each link corresponding to a path through the data network between any two terminals. In Fig. 9, each of the three communities 402, 404, and 406 includes its set of terminals. In the community 402, terminals 408 are coupled to a link 409 (e.g., a LAN, WAN, or other network). A call server 410 is also coupled to the link 409 to manage calls between or among the terminals 408 and between one or more of the terminals 408 and a terminal external to the community 402. The first community 402 is coupled to the second community 404 over a link. In the second community 404, terminals 414 are coupled to an internal link 415. The second community 404 is coupled over another external link 430 to a third community 406. An internal link 421 in the community 406 is connected to terminals 420. In the illustrated embodiment, the second and third communities 404 and 406 share a call server 416, which manages calls within each of, or between, the communities 404 and 406 as well as between a terminal in one of the communities 404 and 406 and another community, such as community 402. Each server maintains a list of its assigned communities and terminals in each of those communities.

0074Generally, the links 430 and 432 (and other external links connecting communities) have lower bandwidths than the internal links in each of the communities. However, it is contemplated that exceptions to this exist where an external link may have higher bandwidth than an internal link. For a given community I, the following parameters may be defined: L_I, which represents the limit on a total available bandwidth between the community and a device or system external to the community; M_I, which represents the threshold at which reselection of a codec, packet size, or other resource element is performed to reduce load on a link in a community; N_l, which represents a threshold to restrict outgoing calls; and T_I, which represents the usage of the transmission resources in the community.

0075Thus, according to one embodiment of a call admission control, outgoing new call requests from the community I may be denied if the value of T_I exceeds the threshold N_I. If the traffic T_I exceeds the threshold M_I, then the call server for the community I can start to perform codec and other resource selection to reduce traffic. Thus, as described above in connection with Figs. 2-5, a call server may discard codecs and/or other resource elements based on transmission resources that the call server monitors, including the several thresholds L_I, M_I, and N_I of the community I. In one embodiment, the value of M_I is about 60% to 80% of L_I. The value of N_I can be set at a value closer to or at L_I.

0076Further, a pair-wise limit can be added for call admission control between communities. In this embodiment, for a given community link between two communities I and J, the following parameters may be defined: L_IJ, which represents the limit on a total bandwidth to be used by the community link IJ for the telephony application; M_IJ, which represents the threshold at which resource element selection is performed; and T_IJ, which represents the usage of transmission resources of the community link IJ. A community link does not have an N parameter since a link has no direction and the concept of incoming or outgoing calls does not apply.

0077For a terminal in community I to establish a new call with a terminal in community J, the following must be satisfied:<maths id="math0003" num=""><math display="block"><mrow><msub><mrow><mtext>T</mtext></mrow><mrow><mtext>I</mtext></mrow></msub><msub><mrow><mtext> &lt; N</mtext></mrow><mrow><mtext>I</mtext></mrow></msub><msub><mrow><mtext> and T</mtext></mrow><mrow><mtext>IJ</mtext></mrow></msub><msub><mrow><mtext> &lt; L</mtext></mrow><mrow><mtext>IJ</mtext></mrow></msub><mtext>.</mtext></mrow></math><img file="EP1079573A2_D0003.tif" /></maths>

0078The first clause essentially states that the traffic between community I and all other communities must be less than the threshold limit N_I. The value of T_I is the sum of all traffic between community I and all other communities, that is<maths id="math0004" num=""><img file="EP1079573A2_D0004.tif" /></maths>

0079The second clause (T_IJ &lt; L_IJ) specifies that the traffic on the link IJ between communities I and J must be less than the threshold L_IJ. If either of the two clauses are not satisfied, then the call request from a terminal in community I is denied. A threshold M_IJ is also specified for the link IJ between communities I and J to specify a limit at which resource selection is performed.

0080The limits L_I, L_IJ, M_I, and M_I,J may be static (that is, they remain fixed) or adaptive (that is, they may change with changing conditions of the data network). For example, as the data network traffic increases, the threshold values may decrease. The call server can collect statistics regarding the network (such as by accessing a network monitor or other node such as a router or gateway) to determine the conditions of the network. Based on the conditions, e.g., large delays or packet losses, the threshold values may be decreased to maintain high quality of service.

0081As illustrated in Fig. 9, the first community 402 has the following parameters: T₁, L₁, M₁, N₁; the second community 404 has the following parameters: T₂, L₂, M₂, and N₂; and the third community 406 has the following parameters: T₃, L₃, M₃, and N₃. The community link 432 has the following parameters: T₁₂, L₁₂, M₁₂; and the community link 430 has the following parameters: T₂₃, L₂₃, and M₂₃.

0082Referring to Figs. 10A-10B, the call admissions control procedure is illustrated for a call between an origination terminal in one community (community I) and a destination terminal in a second community (community J). In the example of Figs. 10A-10B, a first call server 500 services community I and a second call server 501 services community J. The call server 500 receives a Call_Setup message from a terminal in community I that includes a list of supported audio codecs and a list of supported packet sizes. The call server 500 then determines (at 502) whether the call is an intra-community or an inter-community call. If the call is an intra-community call, then the call server 500 in community I performs intra-community call processing and exchanges messages between the terminals involved in the call session (at 504). Codec and other resource element selection may be performed as described above if the traffic T_I exceeds the threshold value M_I.

0083If the call is an inter-community call, then the call server 500 determines (at 506) the name of the origination community, in this case community I. The call server 500 then checks the attributes L_I, M_I, and N_I of the community I. At this point, the call server 500 checks the traffic T_I (between community I and all other communities) against the limit N_I. If T_I exceeds N_I, then the call is denied by the call server 500. However, if the call request is allowed to proceed, then a candidate list of codecs and packet sizes is then created. Such a list of codecs and packet sizes may be further restricted based on the values of the thresholds L_I, M_I, and N_I. The bandwidth for community I is reserved to reserve capacity for the requested call. This allows the call server 500 to monitor the available bandwidth for further inter-community call requests from terminals in the community I.

0084A call request message is sent (at 508) from the call server 500 to the call server 501 that is assigned to community J. The message includes the name of the origination community I as well as the candidate list of codecs and packet sizes. In response to the message from the call server 500, the call server 501 determines the destination community name J, the community link IJ, and checks the limits L_J, M_J, and N_J, L_IJ and M_IJ (at 510). Such a check includes checking if value of T_IJ exceeds L_IJ. Also, the value of T_J (total traffic of inter-community calls between community J and all other communities) is evaluated against L_J. If T_J exceeds L_J or T_IJ exceeds L_IJ, then the call is denied and the call server 501 informs the call server 500 of the call termination. The call server 501 may also check T_IJ against M_IJ, and T_J (total traffic from community J) against M_J, to determine if resource selection is needed.

0085From the limits, the call server 501 may further restrict the list of allowed codecs and packet sizes. Bandwidth is then reserved for the community J and link IJ for the requested call. The call server 501 then sends a Call_Setup message (at 512) to the destination terminal in community J. The Call_Setup message includes the codec and packet size candidate list. In response to the Call_Setup message, the destination terminal sends back a Call_Connect message (at 514) that identifies a selected codec and a packet size. The call server 501 and destination terminal may select a codec and packet size using techniques described in connection with Figs. 2-5, which uses a ranking algorithm. Based on the returned Call_Connect message identifying the selected codec and packet size, the call server 501 corrects (at 516) the expected bandwidth usage of community I and link IJ. The call server 501 then sends back (at 518) a Connect/Answer message to the call server 500 that includes an identification of the termination community link (J) and the selected codec and packet size. Based on the identification of the selected codec and packet size, the expected bandwidth usage in the community I for the call session is corrected, and the expected bandwidth usage of the community link IJ is updated (at 520).

0086At this point, a call has been connected between the origination terminal and the destination terminal in communities I and J, respectively. If the origination terminal desires to terminate the phone call, then it sends a release message (at 522) to the call server 500. In response, the call server 501 updates (at 530) its bandwidth usage of community I and link IJ and sends a release message (at 524) to the call server 501. In response to the release message, the call server 501 updates (at 526) the bandwidth usage for community J and link IJ to reflect termination of the call. The call server 501 sends a release complete message (at 528) to the destination call server to terminate the call.

0087In some cases, it is easy to determine whether or not a call is intra-community or inter-community. For example, the translation component in a call server can be equipped with information indicating whether or not the call request is for an intra-community call. However, in some other cases, the origination terminal's call server cannot accurately determine if a call request is for an intra- or inter-community call. For example, although a call request may identify a destination terminal in another community, the destination terminal may have forwarded the call back to a terminal in the origination community. In this case, the origination terminal's call server may assume that the call is an inter-community call and delete any codecs and other resource elements from the candidate list based on the origination terminal's community threshold values. However, the call may still be determined to be an intra-community call by a second call server associated with the assumed destination terminal. The second call server may determine that the call has been forwarded back to the community of the origination terminal. Thus, in an embodiment in which intra-community calls are not subject to resource element selection, the call request should not be denied even if the resulting candidate list is empty since the call may be forwarded back to the origination terminal's community for an intra-community call. However, if the call is indeed inter-community, and the candidate codec list is empty, then the call is denied by the second call server.

0088A call management method and apparatus has been described to offer call admissions control and selection of resource elements to more effectively manage usage of a data network for telephony communications while providing a higher quality of service.

0089While the invention has been disclosed with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of the invention.