Method and apparatus for codec selection

TECHNICAL FIELD OF THE INVENTION

0001The present invention relates to the control of communications in a telecommunication system; and, more precisely, to the codec selection process in a communication between two or more terminals across said telecommunication system.

DESCRIPTION OF RELATED ART

0002A telecommunication system usually comprises, among others one or a plurality of interconnected physical networks of the same or different nature (such as a Local Area Network -LAN-, a Wide Area Network -WAN-, a Switched Telephone Network -PSTN-, an Integrated Services Digital Network -ISDN-, etc.) for providing communication, various server entities entitled to perform specific functions for serving telecommunication services to the users of said system (such as call control functions, user registration functions, gateway functions for translating between different protocols and media format, etc.) and a plurality of terminals which are (or are suitable to be) connected to said physical networks, which obtain communication services from the telecommunication system and which act as endpoints of a communication.

0003One kind of communication service that can be offered by a telecommunication system is the one known as a “multimedia communication”. In a multimedia communication (also known as “multimedia call”) the nature of the information that can be exchanged between the endpoints (e.g.: multimedia terminals) involved in it is not limited to traditional “voice” media (audio). Instead, it can convey multiple media types, such as audio, video, binary data (e.g. a binary file), etc., wherein it is possible to establish a multimedia communication for exchanging only one of these media types, or any combination thereof. Hence, the concept multimedia communication embodies various communication types, such as a voice calls, video conferences, data exchange, etc.

0004Given that the bandwidth that can be demanded (requested and/or used) in multimedia communications (i.e. the quantity and speed of the media information that can be exchanged) can vary substantially depending on the communication type (e.g. only audio, audio and video, etc), native packet networks (i.e. networks using packet-switching oriented technology for transmission of information), such as LANs of the same or different technology (e.g. ethernet, token ring, Asynchronous Transfer Mode -ATM-), are considered as the most suitable for transporting them. I.e. as opposite to a circuit-switched oriented network, in which the bandwidth available for a given communication is limited to the one offered by the individual circuit assigned to it, in a native packet network, such as a LAN, the total bandwidth can (theoretically) be used in a given communication.

0005Accordingly, modern standards related to multimedia communication over packet networks, such as H.323 (ITU-T Recommendation H. 323, November '00) or SIP (“Session Initiation Protocol”, IETF-RFC3261), define the use of data packets to exchange both the signaling and the media, related to a communication.

0006However, this does not compel to use only physical networks which are native packet data networks for establishing a communication according to H.323 or SIP multimedia standards. Instead, any physical network which offer bearer means able to convey data packets can be utilized. Thus, for example the data transmission capabilities offered by the bearer means of circuit-switched oriented networks, such as PSTN or ISDN, can also be used for this purpose. Therefore the cited term “packet network” (and, sometimes, “communication network” or, merely, “network”) refers in this document to one or a plurality of physical networks that are able to convey, and exchange among them, data in form of packets by using well-known network protocols (such as Internet Protocol, IP) and transport protocols (such as Transmission Control Protocol, TCP, or User Datagram Protocol, UDP), also encompassing not only those physical networks which are pure packet-switched oriented (such as a LAN), but also those physical networks, which are circuit-switched oriented (such as PSTN or ISDN), and which are also able to transparently convey data packets through the bearer service they provide.

0007In a scenario wherein a plurality of physical networks are interconnected and co-operate (e.g. by using common protocol(s)), and network elements providing interconnection (such as routers, bridges, etc., as well as routing and/or gateway functions when needed), each of said physical networks are also referred to as “sub-networks”. I.e. they are sub-networks of a (virtual) “communication network” that, for example (as will be later mentioned with reference to <figref idref="DRAWINGS">FIG. 1</figref>) allows a plurality of applications to co-operate, regardless their physical location, that is to say regardless the physical network (sub-network) where the machine (endpoint, server, gateway, etc.) hosting them is connected.

0008In a multimedia communication established between endpoints over a packet network, some of the information exchanged, such as the signaling information or media information having an original digital format (e.g. a document exchanged during the communication), can be readily embedded within data packets.

0009However, when sending media information having originally an analog format (such as voice or video), the original media signal must be first digitized (i.e. transformed into a binary coded representation of the original analog signal) in the origination endpoint, and then transmitted towards a destination endpoint in a stream of subsequent data packets, each packet carrying a given quantity of bits representing a part of the original signal.

0010At the destination endpoint, these bits are extracted from the stream of data packets and assembled together in order to further reconstruct a copy of the original signal that was captured at the source endpoint.

0011It is desirable that the copy of the original media signal, that is reconstructed at the destination endpoint of the data packet stream, is as similar as possible (in both timing and waveform) to the original media signal that was captured and coded at the originating endpoint. At the same time it is also desirable to diminish the quantity of bits transmitted in order to avoid over-loading of the transmission resources.

0012In order to convert an analog signal into a stream of bits (coding), and vice versa (decoding), several algorithms have been developed along the years known as codec algorithms or, simply, codecs, which are implemented by devices (codec devices) which are located wherever said kind of conversion is needed (e.g. they can be located in a user terminal, or in a server machine performing functions of media gateway in a telecommunication system, etc.).

0013On its coding operation, a codec device receives a signal, and applies a given coding algorithm to it obtaining a stream of bits that represents the same signal as the original one. On its decoding operation, it performs the reverse function.

0014Some information from the original signal (e.g. audio signal, image signal) can get lost when it is coded due to, for example, the fact that the information is lost by the compression rate introduced by the coding algorithm. The amount of information that is lost determines the quality that a given codec can provide: higher compression rates will use less bandwidth when transmitting the media information over a network. However, in general, a worse quality can be perceived on the reconstructed original signal, since more information can get lost due to the compression. In addition to the loss of information, the codecs can also introduce delays on its coding and decoding operations.

0015The following table summarizes the bandwidth demanded and the average quality perceived for some well-known codecs used for audio signals: <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="84PT" align="center" /><colspec colname="3" colwidth="63PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Codec algorithm</entry><entry>Bandwidth usage</entry><entry>Perceived quality</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="42PT" align="right" /><colspec colname="3" colwidth="42PT" align="left" /><colspec colname="4" colwidth="63PT" align="left" /><tbody valign="top"><row><entry /><entry>G.711</entry><entry>64</entry><entry>Kbps</entry><entry>Good</entry></row><row><entry /><entry>G.728</entry><entry>16</entry><entry>Kbps</entry><entry>Good</entry></row><row><entry /><entry>G.729</entry><entry>8</entry><entry>Kbps</entry><entry>Average</entry></row><row><entry /><entry>G.723.1</entry><entry>6.3</entry><entry>Kbps</entry><entry>Average</entry></row><row><entry /><entry>G.723</entry><entry>5.3</entry><entry>Kbps</entry><entry>Bad</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0016It shall be noticed that the bandwidth values cited above relates merely to the quantity of bits per second needed to convey media information in real time for media coded according to a given codec. However, in multimedia communications over packet networks, wherein the media travels in form of bits embedded within data packets, the binary rate demanded by a given codec (bandwidth in bits/sec.) is increased by the overhead data introduced by the various protocols that, at different communication layers, are involved in the conveyance of said media. Thus, the bandwidth needed to convey media using, for example, a G.728 codec from the source endpoint to the destination endpoint, shall be higher than 16 Kbps.

0017Both the recommendations SIP and H.323, provide the signaling framework for negotiating between the endpoints the characteristics of the media they will exchange during its communication, and, more precisely, the codecs they desire to use among the ones they support. In short, it can be summarized that, without the mediation of any other server entity, the codec(s) used in the media exchanged shall be selected between the one(s) that are advertised (indicated) as desired by each endpoint, and which is (are) common to both endpoints.

0018The codecs advertised by an endpoint can be the ones supported by said endpoint, or a subset of them which are indicated as allowed or desired by its user. In fact, some available multimedia terminal applications which can be loaded in a personal computer for converting it in a multimedia endpoint (such as the NetMeeting© of Microsoft©) allows the user to state his/her preferences regarding quality by selecting the codecs that can be used by the endpoint when establishing a communication.

0019These standards for multimedia communications also define functional server entities (e.g. the so called “SIP Servers” in the recommendation SIP, and “Gatekeepers” in the recommendation H323) that can perform a variety of functions related to the control of multimedia communications between endpoints. The term multimedia controller will hereinafter be used to refer indistinctly to any of said kind of entities.

0020In short, the functions that can be provided by a multimedia controller are, among others: admission/registration control (e.g. store registration data of a given user from a given endpoint, to be served hereinafter for further communications to/from said endpoint), call authorization and call control signaling (e.g. admitting communications to/from a given endpoint, and mediate in the associated signaling) and bandwidth management (accept or deny new communications or bandwidth change requests for already established ones depending on available bandwidth in the network) etc.

0021The functionalities provided by a multimedia controller can be performed within the same physical entity (i.e. a computer machine), or be distributed across various physical entities. The term MCS (Multimedia Controller Server) will be used in this document to refer to a multimedia controller in terms of its functional elements, regardless if they are implemented within the same machine, or distributed across various machines.

0022Additionally, an MCS can further control and modify the content of the signaling exchanged by the endpoints and, more precisely, to control and modify the content of the signaling which is related to the characteristics of the media they intend to exchange (e.g. by neglecting the usage of some codecs to the endpoints). The modifications are usually done based on information that might be not available for the users of the endpoints, for example information related to the network, such as the actual bandwidth usage, the rate of packet loss or packet delay, the class of service assigned to the involved endpoints which can be related to a minimum and/or maximum QoS (Quality Of Service) etc.

0023Several solutions are known that address the implementation of codec selection policies in an MCS.

0024For example, patent application EP1024637 discloses an MCS that comprises two functional entities: a standard H.323 Gatekeeper (108) and a novel “Bandwidth Allocation Server” (BWAS 109), wherein said BWAS can be either connected or co-located with the Gatekeeper (col. 3, lines 4 to 15).

0025According to said patent, the BWAS receives two threshold values (named “X” and “Y”) that, respectively, determine a high-level and a low-level of bandwidth usage on the monitored network. So, if the bandwidth usage in a given moment surpasses the predefined high-level (“X”), it orders to the endpoints to use codecs that requires less bandwidth; then, when the bandwidth usage decreases below the predefined low-level (“Y”), it notifies to the endpoints to restore their preferred codecs.

0026Another kind of solution is disclosed in patent application EP1079573. Here the MCS comprises: a Call Server (12) (which can be assumed to be similar to a standard H.323 Gatekeeper or a SIP server, having further additional functions disclosed in said patent application), a Policy Server (18) in charge of usage policy of multimedia communications over the data network (20) and a Network Monitor (19), to monitor characteristics and conditions of the data network (20).

0027According to said patent application, the Call Server (12) manages the “resource elements” (among them: codecs) that will finally be used in a communication between endpoints according to: information related to the packet network usage, and packet network usage policy (paragraph 27). Optionally, said Call Server (12) can further act according to the current characteristics and conditions that are provided to it by the Network Monitor (19), wherein said characteristics and conditions concerns to data packet loss percentage and/or packet delays of data packet traversing the different network elements (e.g.: routers) that links the different network portions of said data network (20), as well as to QoS provided by well known methods (such as Diffserv, e.g.: IETF-RFC2475) for prioritization queues of data packets in the various routers of a data network (col. 4 lines 21 to 27; col. 14 line 32 to col. 15 line 16; col. 16 lines 25 to 30; and claims 9 to 12).

0028The codec limiting criteria disclosed in EP1024637 and EP1079573 comprising the actual bandwidth usage, and/or the rate of packet loss, and/or packet delay, may be used in an MCS to limit the usage of certain codecs due to dynamic network conditions.

0029In addition, according to a further embodiment of the aforementioned patent application EP1079573 that will be later discussed, the Call Server (12) can maintain a list of one or more “communities” it serves, as well as of the terminals (endpoints) that belong to said “communities” (col. 18, lines 3 to 5), wherein, according to said patent, the concept of “community” refers to a set of endpoints coupled by data links within the data network that have relatively high bandwidth, and which can communicate with each other without being subject to call admission controlled by the Call Server (paragraph 71). So, said Call Server processes a call request (for codec selection purposes) based on if the originating endpoint and the terminating endpoint belongs to the same community (paragraphs 82 and 83).

SUMMARY OF THE INVENTION

0030The present invention is concerned with a problem of controlling the codec selection in an MCS (Multimedia Controller Server), controlling multimedia communications in a telecommunication system that comprises a plurality of interconnected physical networks offering different bandwidth capacity for a communication established through them.

0031The invention is also concerned with a problem that there can be uncertainties in a state-of-the-art MCS to determine details of the underlying physical networks and, more precisely, to determine for a given communication the MCS has to control between two (or more) endpoints, if there is any network element in the underlying physical network said communication will traverse, that can impose some bandwidth limitation concerning the codecs that can be used for it.

0032Said uncertainties stem from the fact that the control elements of an MCS, which is in charge on high-layer aspects of multimedia communications (call control functions, codec selection functions, etc.), work on top of transport and network layer protocols (that are in charge of low-layer aspects of communications) that hide the details of the underlying physical networks. The control elements are in other words applications that reside in the application layer (ISO “layer 7”) and thus can use the services provided by lower layers (e.g. transport layer—ISO layer 3, Network Layer—ISO layer 3-, Link Layer—ISO layer 2 or Physical Layer—ISO layer 1-), while ignoring their specific details.

0033The problem is solved in the following manner. When a multimedia communication between endpoints is received in the MCS, the method and apparatus according to the invention allow to detect whether there are bandwidth limitations due to the bandwidth capacity of the various physical networks said communication will traverse, and then, to control what codec(s) are selected that can be used for said communication based on information concerning said bandwidth capacity.

0034The method and apparatus according to the invention takes into account a network element that links physical networks of different bandwidth capacity together. The network element acts as a “funnel” network element as it limits the bandwidth of a communication established through it to the highest theoretical bandwidth available per communication in the physical network having the lowest bandwidth capacity among the ones it connects.

0035Somewhat more in detail the solution comprises the following steps: storing address information related to, at least, one funnel network element which is linking a first physical network and a second physical network of said plurality of physical networks; receiving in the MCS a communication request between endpoints that contains the identifiers of the codecs advertised as desired for said communication; tracing the communication path towards said endpoints; and selecting one (or more) codecs among said advertised codecs for being used in said communication, depending on if said communication path traverses said funnel network element.

0036The communication request can include various protocol messages exchanged between said endpoints through the MCS; wherein, at least one of them conveys information related to one or more codecs advertised as desired by an endpoint. For tracing the communication path towards an endpoint, the MCS sends an address detection message towards said endpoint. The address information conveyed in the answer received to said address detection message is compared with the addresses that correspond to the funnel network elements known by the MCS; and, if there is a match, the advertised codecs can be limited accordingly.

0037According to an embodiment, the address detection message is a path-discovery message suitable to provide the network addresses (such as IP addresses) of the network elements it traverses.

0038According to a further embodiment, the address detection message is an address-resolution message suitable to resolve a network address (such as an IP address) into a corresponding physical address (such as an ethernet address of a network element in a LAN) in a physical network.

0039According to still an embodiment, and related to at least one funnel network element, it is further stored information related to, the bandwidth provided for communications established through the funnel network element.

0040According to still a further embodiment, and related to at least one funnel network element, it is further stored information related to the codecs that are suitable to be used for communications established through the funnel network element.

0041A purpose with the invention is to properly select codecs at different ends of a communication, established over the physical networks.

0042Another purpose is to investigate the bandwidths in the different physical networks and their linking network elements and select the codecs with respect to that.

0043The invention has the advantage that it can operate independently of, or in combination with, other well-known methods and apparatuses used in MCS:s for limiting bandwidth usage by limiting the codecs advertised by the endpoints.

0044Another advantage is that the benefits provided by this invention can be achieved without requiring modifications in endpoints or in network elements of the underlying physical networks (such as routers, bridges, remote access servers, etc.).

0045The invention will now be more closely described with the aid of preferred embodiments and with reference to the following drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0046<figref idref="DRAWINGS">FIG. 1</figref> shows a block schematic over a layered communication structure in a telecommunication system that provides various communication services.

0047<figref idref="DRAWINGS">FIG. 2</figref> shows a block schematic over a logical architecture of a state-of-the-art multimedia controller server, MCS.

0048<figref idref="DRAWINGS">FIG. 3</figref> shows a block schematic over a more detailed content of some stored data shown in <figref idref="DRAWINGS">FIG. 2</figref>.

0049<figref idref="DRAWINGS">FIG. 4</figref> shows a block schematic over a possible network topology in a telecommunication system providing multimedia communication services, together with its corresponding layered structure.

0050<figref idref="DRAWINGS">FIG. 5</figref> shows a block schematic over a logical architecture of a multimedia controller server, MCS, according to the invention.

0051<figref idref="DRAWINGS">FIG. 6</figref> shows a block schematic over the content of new data stored according to the invention.

0052<figref idref="DRAWINGS">FIG. 7</figref> shows a summarized flowchart of a codec selection according to the invention.

0053<figref idref="DRAWINGS">FIG. 8</figref> contains a more detailed flowchart of a codec selection according to the invention.

0054<figref idref="DRAWINGS">FIGS. 9 and 10</figref> diagrams over a simplified signaling flow of a communication request between endpoints, according to the H.323 protocol, showing the novel features of the invention.

0055<figref idref="DRAWINGS">FIG. 11</figref> is a diagram over a simplified signaling flow of a communication request between endpoints, according to the SIP protocol, showing the novel features of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

0056<figref idref="DRAWINGS">FIG. 1</figref> shows a layered communication structure of a telecommunication system that provides various communication services. In the figure are shown file transfer applications <b>101</b>, WWW applications <b>102</b>, electronic mail applications <b>103</b> and also applications related to multimedia communications, such as multimedia controller applications <b>104</b>, and a multimedia terminal applications <b>105</b>. It can be seen that these well-known applications, providing communication services, work on top of a transport layer <b>106</b> and network layer <b>107</b> protocol stack <b>100</b>, which is common all the way across the various physical networks. Those networks are a physical network <b>1</b>, a physical network <b>2</b> and a physical network <b>3</b>, and the protocol stack links them so as to form a communication network.

0057An example of a transport-layer/network-layer stack for providing a communication network across various physical networks is the one formed by TCP or UDP (as transport protocols) and IP (as network protocol), usually named as TCP/IP or UDP/IP. Although not shown in <figref idref="DRAWINGS">FIG. 1</figref>, the common network layer <b>107</b>, using a network protocol such as IP, can work on top of another communication layer that implement, for example, another network protocol more specific of the underlying physical network.

0058The physical networks depicted in <figref idref="DRAWINGS">FIG. 1</figref> can have similar or different nature. For example, physical network <b>3</b> can be a 1 Gbps ethernet LAN and physical network <b>2</b> can be a 10 Mbps network. The physical network <b>1</b> can be, for example, a public circuit-switched oriented network, such as a PSTN. For providing connectivity among them, a network element, such as a router <b>4</b>, can be connecting physical network <b>3</b> with physical network <b>2</b>, while another network element, such as a RAS (remote access server) can be connecting physical network <b>2</b> with physical network <b>1</b>, PSTN.

0059A communication network based on a transport-layer/network-layer stack, such as TCP/IP or UDP/IP, in the one hand, provides communication services to the applications regardless details of the lower communication layers (<b>108</b>, <b>109</b>) of the various physical networks, and, in the other hand, is able to interface with the corresponding lower layers (<b>108</b>-<b>1</b>, <b>108</b>-<b>2</b>, <b>108</b>-<b>3</b>) of these physical networks. Accordingly, a given application such as MM terminal <b>105</b> that is located in a machine, e.g. the computer machine M-A <b>6</b> connected to the physical network <b>1</b>, can communicate with other applications e.g. the MM controler <b>104</b>, residing in the other machine M-B <b>7</b> and connected to the other physical network <b>3</b>. This communication is performed by using a network address of the counterpart machine, such as an IP address 193.180.251.32, while the underlying characteristics of said communication is unknown. More precisely, the physical address in the physical network where said counterpart machine is connected is unknown, such as an ethernet address 8:0:20:9c:53:90 of said machine in LAN where it is connected. So, for example, an application implementing the multimedia controller functions <b>104</b> in an MCS, can communicate with an application implementing the multimedia terminal <b>105</b> in an endpoint of the communication, using their respective IP addresses.

0060As can be seen from the protocol layered structure depicted in <figref idref="DRAWINGS">FIG. 1</figref>, the transport and network protocol layers <b>106</b> and <b>107</b>, e.g. TCP/IP or UDP/IP, which are “continuous” all the way through the different physical networks physical network <b>1</b>, physical network <b>2</b> and physical network <b>3</b>, hide to the applications the specific details of the network topology used in the communication, since they hide the details of the underlying physical networks.

0061In the specific case of multimedia communications, this has the advantage of hiding these topology details to the application(s) of a MCS, which implement basic functions for admission, call authorization, call control, etc. But it has the drawback of hiding said topology details also to applications which performs codec selection functions, even to those mentioned earlier which are based on gathered information related to network status.

0062This drawback is addressed by the aforementioned aspect of patent application EP1079573.

0063According to said aspect, it is also possible to process a call request depending on if the identifiers of the calling and called endpoints belong to the same “community” or not. Although it is not explicitly stated in said application what kind of identifier of a given terminal (endpoint) can be used to determine in the “Call Server” (12) if the communication is “inter community” or “intra community”, the skilled person would be driven to assume said identifier to be either an address associated to said terminal (such as an IP address), or an identifier of the user registered in said endpoint. Since these kind of identifiers are the ones used in well known multimedia protocols (such as H.323 or SIP) when requesting a communication, e.g. when making a call, wherein the terminal (endpoint) is identified by an IP address and by the alias or aliases of the user registered on it.

0064Should said identifier be a network address of the terminal such as an IP address, the feature taught in EP1079573 could be suitable for cases wherein two conditions are always fulfilled: first, the terminal (endpoint) uses a static network address and, second, said terminal is not supposed to be movable, i.e. it is instead connected to another connection point of the network. Otherwise there would be no basis to infer a physical location from a network address.

0065There could be basis only if the terminal gets a static network address, and it is always connected in the same physical connection point. However, in packet networks, where the network address space is scarce and expensive, a dynamic network address assignment scheme is commonly used for user terminals, such as PCs, IP based telephony terminals (multimedia endpoints), etc. Thus the same terminal can receive a different network address every time it connects to the network, even if it does always from the same connection point, i.e. even if it is not movable.

0066Should, instead, the identifier mentioned in EP1079573 be an identifier (alias) of the user using said terminal, such as an E.164 number e.g. +34 5555555, a Uniform Resource Identifier URI e.g. “John_doe@companyX.com” or the like, the feature taught in EP1079573 could not be used to infer a physical location from said identifier if said user is supposed to be able to use (i.e. register into) another terminal, or even to use the same terminal, but connected in a different location.

0067Codec limiting criteria, such as the actual bandwidth usage, or the rate of packet loss and/or packet delay, may suffice to limit in an MCS the usage of certain codecs due to dynamic network conditions.

0068However, the usage of the identifier of the calling or called endpoint, being this either an address of the endpoint or an identifier of its user, does not provide per se a reliable basis to determine the location of the endpoint. Thus, it may not suffice as a codec limiting criteria to determine if there can be bandwidth limitations in a communication between endpoints due to the underlying physical networks said communication can traverse.

0069A possible logical architecture of a state-of-the-art MCS shall now be described with reference to <figref idref="DRAWINGS">FIG. 2</figref> in terms of its functional elements and the data managed/stored.

0070However, it should be understood that the generic architecture depicted in <figref idref="DRAWINGS">FIG. 2</figref> is given just as an example to illustrate well-known functions performed and data managed/stored by a MCS, that will be used later as a basis to detail and highlight novel features of the present invention, and it does not intend to relate to any specific physical architecture (e.g. if these functions/data are performed/stored within one physical machine or distributed across several interconnected machines), nor intends to compel any other alternative logical MCS architecture having a different number of functional elements of the ones described (or a sub-set of them), or managing/storing other data (or a sub-set of the ones described).

0071The functional elements in an MCS <b>48</b> depicted in <figref idref="DRAWINGS">FIG. 2</figref> shall now be briefly described. As other functional elements operating from the application layer of a functional server entity of a modern telecommunication system (or in a terminal/endpoint), said functional elements are accomplished by means of processing means, implementing the service logic, and communication means, that provide communication with further functional elements (and/or access to databases) located, either within the same physical machine or in a different machine; and can be implemented by means of software, hardware, or combination thereof.

0072In particular, communication means for allowing communication between functional elements (or access to data bases) located either within the same machine, or located in another machine (including communications with endpoints), can be accomplished, respectively, by means of well-known internal communication means allowing, for example, communication between processes and/or accesses to internal storage means, and by means of well-known external communication means performing, among others, transport layer functions, network layer functions, data link layer functions and physical layer communication functions. These communication means not detailed in <figref idref="DRAWINGS">FIG. 1</figref>, are known by those skilled in the art, and, thus, does not need to be further explained. <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0073"> Call Control block <b>302</b>: this functional block controls the establishment and releasing of communications, and communicates with its counterpart functional blocks in multimedia endpoints. It can also carry out various additional functions related, for example, to the provision of supplementary services such as call forwarding, multiparty conference, etc. </li><li id="ul0002-0002" num="0074"> Codec Selection block <b>301</b>: this functional block decides, based on codec(s) advertised by endpoints, and, optionally, based on information gathered from the other blocks, what can be the acceptable codec(s) for a communication. </li><li id="ul0002-0003" num="0075"> Codec block <b>308</b>: this block includes the codecs that can be selected by the block <b>301</b>. </li><li id="ul0002-0004" num="0076"> System Configuration block <b>303</b>: this functional block can initialize and/or modify the content of the MCS databases <b>305</b>, <b>306</b> and <b>307</b>. </li><li id="ul0002-0005" num="0077"> Network Status block <b>304</b>: this functional block can gather, classify and store data about bandwidth usage, delay and packet loss rate of the packet network, etc., in order to support further codec selection based on the known state of the network. </li></ul></li></ul>

0078<figref idref="DRAWINGS">FIG. 2</figref> also shows a logical scheme of the various data that can be stored by the storage means of a state-of-the-art MCS, and managed by it. This logical scheme shows separate storage elements, i.e. data bases DB <b>305</b>, <b>306</b> and <b>307</b>. However, this is displayed in that way only for explanatory purposes, wherein, for example, other storage alternatives (e.g. within only one data base) are also possible. <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0079"> User profiles DB <b>305</b>: here information about the users known to the MCS is stored. For a given user, it is usually stored an identifier (such as an E.164 number, a user name, etc.) of said user. Further data, such as class of service associated to said user (category) or user passwords, can also be stored. </li><li id="ul0004-0002" num="0080"> Endpoints DB <b>306</b>: here, information regarding every known endpoint on the MCS domain is stored, i.e. a terminal from which a user has registered his/her presence into the MCS, or all terminals it is assumed to serve. It usually comprises network address of the endpoint (such as an IP address), and identity information of the user currently logged-on (registered) at the endpoint. </li><li id="ul0004-0003" num="0081"> Categories DB <b>307</b>: here information regarding user categories and privileges is stored. For example, it can store the type of calls that can be made/received by a user having said category, e.g. if calls to/from certain destinations are allowed or not, the QoS to apply to said category, the codecs supported for said QoS etc. The information stored here can support the codec selection process, based on user privileges regarding QoS. </li></ul></li></ul>

0082Some further relationship between data based cited above, which are not shown in <figref idref="DRAWINGS">FIG. 2</figref>, as well as an outlined possible content type for each is shown in <figref idref="DRAWINGS">FIG. 3</figref>.

0083For example, data stored in the User Profiles DB <b>305</b> for a given user, can point out an entry in the Categories DB <b>307</b> that correspond to said user, as well as to an endpoint where said user is registered. For example, data stored in the Endpoints DB <b>306</b> for a given endpoint, can point out an entry in the User Profiles DB of the user who has registered on it.

0084Also, for users who have registered his/her presence into the MCS, as well as for calls (communications) it is handling (either already established or being established), some further data not shown in FIGS. <b>2</b> or <b>3</b> can be stored within a state-of-the-art MCS with the purpose of finding out data related to a given call. Said data can, for example, establish a relationship between a user, i.e. one of his/her identifiers, with the endpoint's network address in which said user has registered, as well as with the call(s) said user is involved in wherein, according to the known-art, a call is usually identified by a unique identifier assigned according to the used protocol, such as a callIdentifier according to the recommendation H.323, a Call-ID according to the recommendation SIP, etc. Since an MCS usually stores data related to registered users, as well as related to ongoing calls, into dynamic registers (as opposed to registers having more static nature, as the ones depicted in <figref idref="DRAWINGS">FIG. 3</figref>), these relationships are usually accomplished by storing in said dynamic register a link, e.g. a pointer, towards the corresponding entry in the User Profile DB <b>305</b> and towards the corresponding entry in the Endpoints DB <b>306</b>. This, as shown in <figref idref="DRAWINGS">FIG. 3</figref>, helps to easily find out any data related to a user and his/her endpoint at any moment during the call processing.

0085As cited previously, linking the various physical networks (or sub-networks) of a telecommunication system, wherein a MCS provides control functions for multimedia communications, there can be network elements, such as routers, bridges, remote access servers (RAS:s), that provide interconnection between said physical networks as well as, when needed, the appropriate gateway functions to convert format of either the signaling exchanged at some communication of the communication, and/or the media exchanged. In a communication established between terminals (not only between multimedia endpoints, but between any other kind of terminal) connected to two different physical networks which offer a different maximum bandwidth per communication, a network element which links said two physical networks, acts as a “funnel” for said communication, a funnel network element.

0086<figref idref="DRAWINGS">FIG. 4</figref> illustrates a telecommunication system providing multimedia communications comprising an MCS <b>48</b>, a plurality of physical networks (<b>43</b>, <b>45</b>), and a plurality of endpoints <b>41</b>, <b>46</b> and <b>47</b> connected to said physical networks.

0087The physical scenario showing the topology of the communication is depicted in <figref idref="DRAWINGS">FIG. 4</figref>, bottom. It shows a multimedia endpoint device <b>41</b> connected to the PSTN <b>43</b> (as an example of a first physical network) via a data adapter unit <b>42</b>, e.g. a modem, which has access to a company's private data network <b>45</b> (as an example of a second physical network) via a remote access server RAS <b>44</b>. Within the company's private data network, an MCS <b>48</b> controls multimedia communications for multimedia endpoints <b>46</b> and <b>47</b> directly connected to the company's data network <b>45</b>, as well as for the multimedia endpoint <b>41</b> connected to the other physical network <b>43</b>.

0088For simplicity, the company's private data network <b>45</b> appears to be depicted as a single local area network (LAN); however, it could be further comprised, for example, of a plurality of interconnected physical networks (e.g. a plurality of LANs) interconnected by a plurality of network elements.

0089Similarly, the MCS <b>48</b> appears to be depicted as implemented within a single machine. However, as stated in connection with <figref idref="DRAWINGS">FIG. 2</figref>, this can be an alternative realization, wherein for example the functionality of the MCS could be distributed across various physical machines.

0090A network element such as the RAS <b>44</b> is an example of a funnel network element, since a terminal accessing through it to a native packet data network via, for example, a modem connected to PSTN or ISDN, does not gain access to the same bandwidth capacity as if the terminal was directly (physically) connected to the same network.

0091The RAS is a well-known network element utilized presently for providing to a terminal (such as a personal computer) connected to a public circuit-switched network (like, for example, the PSTN or the ISDN) data connectivity with a private data network (like, for example, a LAN). The RAS allows among others tele-work, since it provides to a user working at home a “virtual” connectivity to the company's private data network, thus gaining access to the same resources the user would gain if “physically” connected to the data network.

0092The data connectivity provided by the RAS <b>44</b> allows a remote machine to communicate with other machines (terminals, servers, etc.) connected to the private data network. The RAS thus allows the remote machine, among other functions, to behave like a multimedia endpoint and to establish a multimedia communication with another multimedia endpoint connected to the private data network. The RAS can perform authorization and authentication functions, as well as the necessary gateway functions, including modem terminating functions, for allowing the interworking between different physical networks, thus providing a transparency to the upper layers of a communication. Therefore, the RAS allows different applications running on the remote terminal (e.g. connected to PSTN) and other applications running on machines directly connected to the company's data network to communicate seamlessly as if they were all connected to the same physical network.

0093<figref idref="DRAWINGS">FIG. 4</figref>, top, depicts a layered structure for the particular case of a communication established between a multimedia endpoint <b>41</b>/<b>42</b> with the MCS <b>48</b> and/or with another endpoint, <b>46</b>,<b>47</b>, via the RAS <b>44</b>. As depicted, the RAS provides up to the TCP/IP and UDP/IP layer, as well as the terminating gateway functions at physical and link layer of the sub-networks it connects <b>43</b>, <b>45</b>.

0094At the application layer, the applications in the remote endpoint <b>41</b> (i.e. multimedia applications entitled to perform high layer functions for call control and audio/video applications for controlling media exchange) communicate with their counter part applications, either or both in the MMC and in the “local” endpoints, by using the communication network provided by the TCP-UDP/IP common infrastructure which hides the particularities of the physical networks below. The numeral “<b>41</b>/<b>42</b>” refers to the layered communication stack in the remote endpoint device <b>41</b> in combination with the data adapter <b>42</b> used.

0095In particular, according to the recommendations SIP or H.323, applications implementing control and exchange of call signaling messages (located in both MCS:s and endpoints), usually use the services of TCP, since this transport protocol has its own internal mechanisms to allow a reliable transfer of data. Other applications implementing control and exchange of media according to these standards (usually located only in endpoints and media gateways), such as RTP/RTCP (Real Time Protocol, RTP Control Protocol; IETF-RFC1889), usually use the less reliable transfer capabilities of UDP.

0096Thus, a (partial) protocol stack involved in call signaling according to the recommendations SIP or H.323 would be: “Multimedia-controller or Multimedia-terminal application” over “TCP” over “IP” (MM-application/TCP/IP). The corresponding (partial) stack involved in the media exchange would be: “Audio-Video-application” over “RTP” over “UDP” over “IP” (A-V/RTP/UDP/IP), wherein as mentioned earlier, RTP, UDP and IP (as well as underlying “link layer” protocols) add each their own overhead of bits, thus causing that the final bandwidth needed to convey media coded according to a given codec, extends beyond of the theoretical bandwidth demanded by a given codec.

0097In a scenario as the one described in connection with <figref idref="DRAWINGS">FIG. 4</figref>, when the MCS (<b>48</b>) receives a communication request between endpoints, it can verify if any of the codecs they advertise imply an admissible bandwidth through the network path towards any of them. To perform this verification, the MCS will check if the network path towards any of said endpoints passes through a funnel network element such as RAS <b>44</b>.

0098To accomplish with this, some modifications in the MCS are introduced according to the invention

0099The modified logical architecture of functional elements in a MCS shall now be described with reference to <figref idref="DRAWINGS">FIG. 5</figref>, which is based on the logical architecture given as example in <figref idref="DRAWINGS">FIG. 2</figref>.

0100There is a new database, named “RAS addresses DB” <b>502</b>. Data in this new database are used by a new functional block named Funnel Detection block <b>501</b>.

0101The name given to the new database, “RAS address DB” <b>502</b>, is just given as an example. Therefore, the scope of the information it can store should not be understood as limited to “remote access servers” (RAS).

0102According to the invention, the RAS addresses DB <b>502</b> will store information related to network elements that can impose bandwidth limitations in a communication, such as remote access servers, router, bridges, etc. This new data base <b>502</b> can be implemented by using any of the storage means available for the MCS. Also, although in <figref idref="DRAWINGS">FIG. 5</figref>, it is shown as a separate database, its data can be, for example, stored in any other database which contains also other kind of data.

0103The Funnel Detection block <b>501</b> is entitled to trace the network path towards an endpoint involved in a multimedia communication, and to act upon the advertised codecs according to it based on information gathered from the RAS address DB <b>502</b>. Although in <figref idref="DRAWINGS">FIG. 5</figref> this functional block <b>501</b> is depicted as a stand-alone functional block, it should be understood that its functionality could equally be embedded within another (existing) functional block modified accordingly (e.g. within the Code Selection block <b>301</b>).

0104In summary, the Funnel Detection block <b>501</b> can discover a bandwidth limitation by sending an address detection message M<b>1</b> towards an endpoint, and then compare address(es) contained in the corresponding answer with the addresses stored in the RAS addresses DB <b>502</b>.

0105As in <figref idref="DRAWINGS">FIG. 2</figref> the <figref idref="DRAWINGS">FIG. 5</figref> also shows the Call Control block <b>302</b>, the Network Status block <b>304</b>, the User profiles DB <b>305</b>, the Endpoints DB <b>306</b>, the Categories DB <b>307</b> and the Codec block <b>308</b>.

0106Assuming, as an example, that the Funnel Detection block <b>501</b> is a stand-alone functional block. Then the Codec Selection block <b>301</b> is modified so as, for example, it interworks with the Funnel Detection block <b>501</b> to obtain a refined codec list which is suitable for the call being processed.

0107The System Configuration block <b>303</b> is also modified to configure data stored in the RAS addresses DB <b>502</b>.

0108Further details of these new/modified elements, as well as their interactions, shall hereinafter be explained.

0109Before the various functional elements in an MCS starts processing communication requests according to the invention, the data stored in the RAS addresses DB can be configured from the System Configuration block <b>303</b>. These data, whose content will be later detailed, will be related to one or more funnel network elements that exist across the various physical networks, through which multimedia communications can take place and which funnel elements are controlled by this MCS. Thus, various means in a state-of-the-art functional block <b>303</b> in charge of configure operational data in an MCS, such as for example OA&amp;M (operation, administration and maintenance) commands, and arranged to write, read, or modify data into a database. Configuration files, which are distributed during start-up or restart phases of the a functional block in the MCS, or of the entire MCS, can be used for this purpose.

0110In <figref idref="DRAWINGS">FIG. 6</figref> an exemplifying structure and content of the RAS addresses DB <b>502</b> is shown in detail. One entry in the RAS addresses DB stores, at least, address information of one funnel network element. According to different embodiments, the address information stored in this database <b>502</b> can contain: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0111"> network addresses <b>61</b>, such as IP addresses; </li><li id="ul0006-0002" num="0112"> physical addresses <b>62</b>, such as ethernet LAN addresses; or </li><li id="ul0006-0003" num="0113"> both. </li></ul></li></ul>

0114So, for example, for the RAS <b>44</b> of <figref idref="DRAWINGS">FIG. 4</figref>, it can be stored its IP address (e.g.: 193.180.251.32), its physical address in the ethernet LAN (e.g.: 8:0:20:9c:53:90), or both.

0115According to an alternative embodiment, an entry in the RAS DB can also contain the identifiers <b>63</b> of the codecs that can be supported by a given funnel network element, or, alternatively, the identifiers of those codecs not supported. For example, starting from a known value of a maximum bandwidth per communication in a funnel network element, such as 64 Kbps in a RAS, and considering an average overhead introduced by intervening protocols (e.g. RTP, UDP, IP, etc.), it can be stated a list of codec identifiers that prevents to use codec “G.711”.

0116According to a further alternative embodiment, an entry <b>64</b> in the RAS addresses DB further stores bandwidth information.

0117The “bandwidth” field <b>64</b> can, for example, contain an identifier that represents the maximum bandwidth that can be through-connected per communication (e.g. multimedia call, data connection, etc.) established through a funnel network element whose address <b>62</b> is in the same row as said field. Such an identifier can be, for example, an integer number which represents a bandwidth expressed in Kpbs.

0118Alternatively, the “bandwidth” field could be empty (or not existing), wherein, for example, for a RAS which connects a private LAN with a public circuit switched network (e.g. PSTN or ISDN), it can be assumed a given maximum bandwidth value per communication (e.g. 64 Kbps.).

0119Alternatively, the “bandwidth” field can contain the total bandwidth available through a funnel network element. So, keeping track in the MCS of the ongoing communications established through said network element (by means of address-resolution messages, or path-discovery messages sent for each communication request, as will be further detailed), it can be determined the remaining bandwidth on it in a given moment. For example, for a RAS server connected to the PSTN by means of a number of “n” modems of “p” Kbps each, the bandwidth limitation to be stored should then be “n” times “p”. For another kind of network element that could act as a funnel (e.g. a router or a bridge), its total bandwidth capacity, or just a part of it which can be configured for multimedia communications, can be stored.

0120The flow chart depicted in <figref idref="DRAWINGS">FIG. 7</figref> summarizes, in an embodiment, a codec selection process <b>70</b>. This process, according to the general architecture depicted in <figref idref="DRAWINGS">FIG. 5</figref> for explanatory purposes, can be assumed to be executed in the Codec Selection block <b>301</b> at reception of a set of codecs advertised by an endpoint, which codecs are received from the Call Control block <b>302</b>. The general description of the operations depicted in <figref idref="DRAWINGS">FIG. 7</figref> is as follows: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0121"> The process starts at a step <b>71</b>. </li><li id="ul0008-0002" num="0122"> In step <b>72</b>, according to the state-of-the-art, those codecs advertised by an endpoint that are not appropriate according to known network conditions can be dropped. Such conditions are rate of packet loss, packet delay, actual bandwidth usage etc. </li><li id="ul0008-0003" num="0123"> The remaining codecs identifiers (or the values of their respective demanded bandwidth) are passed in step <b>73</b> to the Funnel Detection block, that performs a further filtering of codecs according to the invention. The details of the actions performed by said block will be later related with reference to <figref idref="DRAWINGS">FIG. 8</figref>. </li><li id="ul0008-0004" num="0124"> The remaining codecs from the funnel detection block <b>501</b> are received in step <b>74</b>. </li><li id="ul0008-0005" num="0125"> From these remaining codecs a state-of-the-art further filtering criteria can be applied in step <b>75</b> for those that do not fit to user's QoS. </li></ul></li></ul>

0126As a result of this process (and following the explanatory architecture of <figref idref="DRAWINGS">FIG. 5</figref>), the list of remaining codecs (e.g. one, none, or a sub-set, of the identifiers of codecs advertised) are then delivered in step <b>76</b> to the Call Control block <b>302</b> as the ones suitable for the communication. The process stops in a block <b>77</b>. The Call Control block shall then take the appropriate actions according to the specific multimedia protocol it uses to communicate with the endpoints, as will be later detailed with reference to some specific multimedia protocols.

0127It shall be noticed that the order of the steps cited with reference to <figref idref="DRAWINGS">FIG. 7</figref>, shows just an alternative example of precedence. However, this order can vary according to alternative embodiments. Furthermore, steps <b>72</b> and <b>75</b> are previously known and only the actions involving the Funnel Detection block, steps <b>73</b> and <b>74</b>, are the new ones in the embodiment.

0128As mentioned earlier, the Funnel Detection block can limit the usage of some (one, more, or all) codecs advertised by an endpoint in a communication request, depending on if there can be a funnel network element in the network path towards any of said endpoints. To perform this function, the Funnel Detection block will check the network path towards said endpoint by sending an address detection message towards its network address, i.e. an address which is unique across a communication network having a common network-protocol based infrastructure across different physical networks (such as an IP based infrastructure), and taking actions over the advertised codecs depending on if the answer to said message conveys information or not concerning one or more funnel network elements.

0129The address detection message can be, for example: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0130"> a path-discovery message, which is sent towards a network address, and whose answer conveys address information related to the network path it traverses, i.e. the network addresses of the network elements traversed until it gets to the entity having the network address specified; or, </li><li id="ul0010-0002" num="0131"> an address-resolution message, which is sent towards a network address, and which gives back the corresponding physical address (if available). </li></ul></li></ul>

0132In a communication network having an IP based common network infrastructure, an example of a path-discovery message is a “TRACEROUTE” message. This message is supported by ICMP (“Internet Control Message Protocol”, IETF-RFC792) which is implemented in the Internet Protocol, IP (IETF-RFC791). By sending a “TRACEROUTE” message towards a given IP address, it can be obtained as an answer a list of IP addresses corresponding to the network elements it traverses on its path towards the network element having the specified IP address, including also said specified IP address, together with further information, such as the names of said elements.

0133In a communication network having an IP based common network infrastructure, an example of an address-resolution message is an “ARP” message (“ethernet Address Resolution Protocol”, IETF-RFC826). By sending an “ARP” message towards a given IP address it can be obtained as an answer the physical network address that correspond to the specified IP address. As opposed to “TRACEROUTE”, an “ARP” message does not get propagated through certain network elements, such as a RAS, since ARP is designed to be used in a physical network supporting broadcast of information. So, an answer to an “ARP” message can contain empty address information.

0134Both, “TRACEROUTE” and “ARP” are available services that can be requested (i.e. utilized) from an application working on top of an IP based network infrastructure by using a direct service interface provided by IP. Therefore, the same internal communication means which are used by an application process to access to a communication service provided by a lower communication layer in order to communicate with a counterpart application process, can be used for accessing to the address detection functions provided by “TRACEROUTE” or “ARP”.

0135The flow chart in <figref idref="DRAWINGS">FIG. 8</figref> summarizes the actions performed by the Funnel Detection block (<b>501</b>) between steps <b>73</b> and <b>74</b> of the aforementioned <figref idref="DRAWINGS">FIG. 7</figref>, and illustrates novel actions in the codec selection process <b>70</b>. The Funnel Detection block <b>501</b> can use, as an input (e.g. provided from the Call Control block <b>302</b> via the Codec Selection block <b>301</b>) data related to one or more endpoints involved in a communication request, said data comprising for example the IP address of one of the endpoints, or the IP addresses of several endpoints, as well the identifiers of the codecs that have been advertised (or a sub-set of them), or an identifier for each which represents its equivalent bandwidth (e.g. an integer number that express in Kbps said bandwidth). Alternatively, for example, it can receive as an input an identifier for the corresponding communication request (e.g. a callIdentifier, a Call-ID, etc.), and use it to fetch these data from the corresponding functional block (e.g. obtain them from the Call Control block, Codec Selection block), dynamic register, etc., which stores them.

0136The flow starts in a step <b>80</b>. In a step <b>81</b>, the Funnel Detection block <b>501</b> selects one of the received (or obtained) IP addresses and sends an address detection message to it. Since the time to receive a response to it in a step <b>82</b> can vary, a timer of a pre-determined value can be started in step <b>81</b>. So, at time-out of said timer, it can give back an answer stating this event to the functional block which triggered its operation (e.g. the Codec Selection block), which, in turn, can make a further final decision regarding the codecs that can be used in said situation. Said decision can comprise actions such as leaving only those codecs using a low bandwidth, or even, determining if the communication requested can proceed. If, for example, a “TRACEROUTE” message has been used it can take some time to obtain all the IP addresses up to (and including) the specified IP address, those IP address available at the time-out can be utilized.

0137In step <b>82</b> it is received the answer to the address detection message or, as cited above, a time-out has occurred. The address information conveyed in the response received in step <b>82</b> will according to the address detection message be sent in step <b>81</b>. Thus, if an “ARP” message was utilized, the address information in the answer can contain one physical address. Otherwise, if the “TRACEROUTE” message was utilized, one or more IP addresses can be conveyed in the answer. It could happen that the answer comprises no address information. In this situation, a similar procedure as the one cited above in case of time-out cited above can be followed.

0138The address obtained in step <b>82</b> is used to query the RAS addresses DB <b>502</b> in a step <b>83</b>, and to obtain information stored on it for the matching address, in case there is matching. According to different embodiments mentioned earlier, the obtained information can comprise the matching address itself (or a list of them), a figure related to the bandwidth supported, a list of containing one or more codecs supported, or any combination thereof.

0139One or more than one matches can be found ,a step <b>84</b>, alternative “yes”. Otherwise, if no match is found step <b>84</b>, alternative “no”, the flow continues in a step <b>87</b>, as will be later explained.

0140In a step <b>85</b>, if one match has been found in the previous step, then further detailed actions would depend on various alternative embodiments.

0141According to an alternative embodiment not shown in <figref idref="DRAWINGS">FIG. 8</figref>, a further action can be taken to drop some of the advertised codecs based, merely, on the fact that a funnel network element has been found (e.g. drop those codecs whose bandwidth surpasses a given pre-defined value).

0142According to a further alternative embodiment, wherein the Funnel Detection block <b>501</b> receives (or obtain) the identifiers of the advertised codecs, those which does not fit with the codec or bandwidth information obtained from the RAS addresses DB in step <b>3</b>, shall be dropped.

0143According to a further alternative embodiment, wherein the Funnel Detection block receives (or obtain) bandwidth identifiers representing each the equivalent bandwidth of an advertised codec, those which does not fit with the codec or bandwidth information obtained from the RAS addresses DB in step <b>83</b>, shall be dropped.

0144If more than one match was found in previous step <b>82</b>, then the filtering actions described above for step <b>85</b> can take place, considering only the most restrictive funnel network element found.

0145In step <b>87</b>, an alternative “yes”, the process described in steps <b>81</b> to <b>86</b> is repeated for all the endpoints whose information has been received (or obtained) when triggering the operation of the Funnel Detection block. Thus, for example, it can be triggered for only one endpoint and the set of codecs it has advertised (of a sub-set of them), for only one endpoint and the common set of codecs with a counterpart endpoint in said communication (of a sub-set of them) or for various endpoints involved in a communication request and their common set of codecs (or a sub-set of them). In an alternative “no” the process is stopped in a step <b>88</b>.

0146As a result, and following the example case, wherein the Codec Selection block <b>301</b> of <figref idref="DRAWINGS">FIG. 5</figref> triggers the operation of the Funnel Detection block <b>501</b>, the remaining codecs identifiers, or the remaining identifiers which represents their respective equivalent bandwidth, are delivered back to the Codec Selection block, which in turn can give the information back to the Call Control block <b>302</b>.

0147The Call Control block can also take some further actions in the case that all the advertised codecs are dropped by the Funnel Detection Block. Thus, for example it can order to the endpoints to drop the communication (e.g. by sending a message according to the multimedia protocol used) or leave the communication to proceed, thus leaving the users (or the endpoints) to tear it down if they perceive (or detect) they can not communicate.

0148Some examples shall now be given with reference to <figref idref="DRAWINGS">FIGS. 9, 10</figref> and <b>11</b>, that show signaling flows according to the recommendations H.323 and SIP, to exemplify codec selection in a communication request. All these figures show a communication requested between two endpoints, EP-A <b>91</b>, EP-B <b>92</b> respective, which communication is controlled by a multimedia controller MCS <b>93</b>. In the case of the recommendation H.323, the MCS <b>93</b> performs among others the functions defined for a “H.323 Gatekeeper”, as specified by ITU-T Recommendation H.323; while in the case of the recommendation SIP, the MCS performs among others the functions of a “SIP proxy server” as specified by IETF-RFC3261.

0149<figref idref="DRAWINGS">FIGS. 9 and 10</figref> illustrate two modes of advertising codecs in a communication request between the endpoints <b>91</b> and <b>92</b> according to the recommendation H.323. In particular <figref idref="DRAWINGS">FIG. 9</figref> shows a first mode in which the codecs are advertised by means of H.245 messages (messages according to ITU-T Recommendation H.245, July '01, which is defined in H.323 Recommendation to be used as a control protocol of multimedia communications). <figref idref="DRAWINGS">FIG. 10</figref> shows a second mode, wherein the codecs are advertised in H.225 call signaling messages (messages according to ITU-T Recommendation H.225, November '00; which is defined in H.323 Recommendation to be used as a call signaling protocol of multimedia communications) that conveys “tunnelled” protocol elements defined in H.245, such as the set of advertised codec identifiers.

0150In <figref idref="DRAWINGS">FIG. 9</figref>, once some H.225 call signaling messages have been exchanged between the endpoints <b>91</b> and <b>92</b> and the MCS <b>93</b>, the media capability negotiation related to the communication which is requested takes place by exchanging H.245 messages TerminalCapabilitySet <b>901</b> respective <b>903</b>. These messages, which contain the advertised codecs, arrive to the MCS, and are stored, decoded and analysed in blocks <b>902</b> and <b>904</b> to find out what codecs the endpoints are willing to use for the call.

0151The codec selection process <b>70</b> is then executed as described previously with reference to <figref idref="DRAWINGS">FIGS. 7 and 8</figref>. Among the advertised codecs, as an option, only those which are common to both endpoints can be considered for the process <b>70</b>, i.e. those indicated in the message <b>901</b> which are also indicated in the message <b>903</b>. The resulting set of codecs is sent to both endpoints in

0152TerminalCapabilitySet messages <b>906</b> respective <b>907</b>. The resulting set of codecs sent in a TerminalCapabilitySet message, e.g. the message <b>906</b>, can be the ones advertised in the corresponding counterpart's message, e.g. the message <b>903</b>, once filtered by the MCS, or alternatively those which are advertised which are common to both endpoints once filtered.

0153On reception of these messages, further signaling flows take place which are not shown in <figref idref="DRAWINGS">FIG. 9</figref>. At reception of the respective TerminalCapabilitySet message <b>906</b> and <b>907</b>, both endpoints answer with TerminalCapabilitySetAck messages. The MCS <b>93</b>, on reception of these messages, just forwards them to the counterpart endpoint. Once an endpoint has received a TerminalCapabilitySetAck, a further signaling takes place to establish what is called in H.323 terminology “logical channels” that will convey media packets between the involved endpoints.

0154It shall be notice that, if after the codec selection process <b>70</b> there were no codecs remaining suitable for the call, the endpoints can probably drop the communication, since said endpoints will receive empty TerminalCapabilitySet messages that, according to the H.323 protocol, indicates that the endpoints can neither send nor receive any media. So, in this case, the MCS <b>93</b> can drop the communication in advance, e.g. by sending an H.225 message “release complete”.

0155The communication request mode shown in <figref idref="DRAWINGS">FIG. 10</figref> is known as “Fast Connect” in H.323, and it makes possible to establish data needed for media exchange (including media capability information comprising supported codecs) within the first call signaling message. In this mode, an endpoint advertises the codecs it wish to use for a communication in the first call signalling message it sends. The detailed operation is described next.

0156The calling endpoint EP-A <b>91</b> sends an H.225 “setup” message <b>1001</b> to the MCS including (“tunnelled”) a set of media channel definitions for both outgoing channels, i.e. “logical channels” that will convey media packets from calling to called endpoint, and incoming channels, i.e. “logical channels” from called to calling endpoint. For each media (logical) channel definition, the codec desired for said media channel is included by the endpoint. There may be multiple channel definitions for the same channel, each definition specifying a different codec. These multiple definitions are used by the endpoint sending them to indicate the different codecs that said endpoint can use for a channel.

0157The MCS <b>93</b> receives, decodes and analyses the received “setup” message <b>1001</b> from the calling endpoint EP-A <b>91</b> and obtain the set of codecs that are advertised. These codecs can be used by the codec selection process <b>70</b> to filter those not suitable for this communication. A “setup” message <b>1003</b> is then sent towards the called endpoint EP-B <b>92</b>, wherein the media channel definitions whose associated codec has been dropped are removed.

0158The called endpoint EP-B receives the “setup” message and selects from the media channel definitions only those which belong to the channels that it is willing to establish. For example, the calling endpoint may have proposed two video and audio channels e.g. one for each direction. However if the called endpoint wants to establish audio communication only, then it will drop from the setup message received from calling endpoint the media channel definitions corresponding to the video channels. Then it sends a H.225 message “alerting” <b>1004</b>, or other H.225 message such as “connect”, to the MCS <b>93</b> including the remaining media channel definitions. The MCS, in turn, forwards an alerting message <b>1005</b> towards the calling endpoint <b>91</b>.

0159If after the codec selection process <b>70</b> there were no codecs remaining suitable for the communication, the MCS <b>93</b> can tear down the communication request, e.g. by sending a H.225 message “release complete” towards the calling endpoint EP-A <b>91</b>, instead of forwarding the “setup” message <b>1003</b> towards the called endpoint EP-B <b>92</b>, since the communication cannot be satisfactorily established.

0160In <figref idref="DRAWINGS">FIG. 11</figref> the endpoint EP-A <b>91</b> requests a communication according to the SIP recommendation towards the other endpoint EP-B <b>92</b>. The signaling is mediated, “proxied”, by the MCS <b>93</b> having functions of a SIP proxy server, although according to the complete functional architecture described previously it can also have co-located or remotely accessed functions of SIP registrar server. According to the SIP recommendation, the set of codecs to be used in a multimedia communication are advertised in SDP messages (“Session Description Protocol”, IETF-RFC2327) which are embedded within the SIP messages “INVITE”, “200 OK” responses which are positive response to request messages such as “INVITE”, and “ACK” messages, exchanged during the communication request.

0161The calling endpoint sends an INVITE message <b>1101</b> containing, among other data, the codecs acceptable for the session within an SDP message embedded in the INVITE message. The MCS <b>93</b> then forwards the received INVITE message <b>1102</b> towards the called endpoint EP-B <b>92</b> as described in the recommendation SIP RFC3261.

0162If the called endpoint wishes to accept the call, it responds with an “200 OK” response message <b>1103</b>, that holds an embedded SDP message with its own proposal for codecs to be used during the call. Said proposal has been built by the called endpoint EP-B <b>92</b> by dropping from the SDP message received with the INVITE message <b>1102</b> those codecs which are unacceptable for it.

0163According to an alternative implementation, the MCS <b>93</b> can then perform the codec selection process <b>70</b> on this SDP message and obtain a filtered SDP message, and forward a response “200 OK” message <b>1106</b> containing the filtered SDP message, wherein some codecs might have been dropped, to the calling endpoint EPA <b>91</b>. According to a further alternative implementation, the MCS can store the list of codecs proposed by the called endpoint and use it later. In this latest case, the MCS then sends a response “200 OK” message <b>1106</b> including the embedded SDP message <b>1103</b> as received from the called endpoint.

0164An ACK message <b>1107</b> is received in the MCS from the calling endpoint EP-A <b>91</b>. The ACK message <b>1107</b> might hold another embedded SDP message that contains the codecs from within those proposed by the called endpoint EP-B <b>92</b>, that are accepted by the calling endpoint EP-A <b>91</b>.

0165If the ACK message <b>1107</b> does not hold an embedded SDP message, the MCS <b>93</b> can use the previously stored codecs that were extracted from SDP message embedded in the response message <b>1103</b> from the called endpoint for running at this step the codec selection process <b>70</b>. Then, an ACK message <b>1108</b> is sent towards the called endpoint EP-B <b>92</b>, which contains an embedded SDP message comprising the final codec, or set of codecs, to be used in this communication.

0166Although not depicted in any figure, it is known that, in a given multimedia communication established according to the recommendation H.323 or SIP, any of the endpoints involved in it can either add a new endpoint as a participant, or change the characteristics of a communication already established, e.g. from audio and video to only audio, from audio or video using a given codec, to audio or video using another codec, etc. In these situations, a communication request signalled by using some of the protocol messages depicted in the signaling flows of FIGS. <b>9</b> to <b>11</b> (or a similar one) can take place, wherein an endpoint sends a message that conveys information related to one or more codecs it desires for the new or modified communication, and wherein the novel codec selection process according to the invention can take place accordingly.