Multiplex communications – Communication techniques for information carried in plural... – Adaptive
Reexamination Certificate
1999-05-20
2003-10-14
Olms, Douglas (Department: 2661)
Multiplex communications
Communication techniques for information carried in plural...
Adaptive
C370S252000, C370S352000, C370S466000, C370S254000, C379S093280, C709S209000, C709S220000, C709S228000, C375S220000, C375S222000, C375S354000
Reexamination Certificate
active
06633582
ABSTRACT:
FIELD OF THE INVENTION
This invention pertains generally to packet-switched multimedia communications, and more particularly to media bearer channel setup for endpoints requiring symmetrical codecs.
BACKGROUND OF THE INVENTION
H.323 is a standard promulgated by the International Telecommunications Union (ITU) for multimedia communications over local-area networks (LANs) utilizing Internet Protocol (IP) or another packet-switched medium. The H.323 standard is attractive, for one, because it is a flexible standard appearing in a field dominated by proprietary designs that offer little hope for interoperability between different vendor's equipment. Thus, H.323 offers the hope of a world where different vendor's equipment and different carrier's networks can and will communicate seamlessly. The H.323 standard is also attractive because it allows an administrator some measure of control over the amount of voice, video, and other multimedia traffic traversing a packet-switched network that has no other quality-of-service guarantees.
An H.323 call requires that several connections be set up between the calling endpoints. The first of these is a TCP/IP connection for the communication of basic call functionality. ITU-T recommendation H.225 describes the call signaling functionality that is provided on this channel (a variation on Q.931 signaling).
The second connection is a control channel that orchestrates multimedia data communications between the endpoints. This second connection set up between endpoints is also a TCP/IP connection (note that with H.323 version 2, a single TCP/IP connection can in some cases be used for both the first and second connections). ITU-T recommendation H.245 describes the control protocol to be used on this channel. A number of different services may be provided over an H.245 call control channel, including master/slave endpoint determination, audio/visual and data capabilities exchange, and the management of logical channels used to transport audio/visual and data information.
In particular, the audio/visual and data capabilities exchange is intended to ensure that the only multimedia signals that are transmitted are those that can be received and understood by a receiving endpoint. To implement this, each endpoint transmits a capability set to the other, indicating what types and combinations of information streams it can accept. For example, H.323 allows endpoints to implement one or more audio codecs, including ITU audio codec specifications G.711 (required), G.722, G.723.1, G.728, and G.729, some of these having multiple possibilities for bit rate and other settings. An endpoint can, e.g., identify G.711, G.722, and G.729 in its capability set, signaling its peer endpoint that it may choose to open a logical channel for any one of these three identified audio codecs, but not for any other.
Because each H.323 transmitting endpoint can open a logical channel corresponding to any one of its peer's advertised capabilities, it is possible that the endpoints will select different transmit capabilities. This results in the creation of asymmetrical logical channels, e.g., a G.711 audio channel in one direction and a G.729 audio channel in another.
Many systems can simultaneously operate one codec for transmitting, and another for receiving, thus allowing them to function with asymmetrical logical channels. But in some terminal configurations, it may be advantageous or necessary to constrain an endpoint to only symmetrical codec selection. If asymmetrical logical channels are set up with such an endpoint, its user may hear incoherent audio or nothing at all.
SUMMARY OF THE INVENTION
The H.245 recommendation fails to provide a reliable solution to the asymmetrical channels/symmetrical endpoint problem. H.245's general conflict resolution scheme, if applied to this problem, may result in long setup delays, or in the worst case, no resolution of the problem at all.
Although an endpoint desiring to establish symmetry with its peer could wait and see what codec its peer selects before making its selection, this may also result in unacceptable media setup delays. This approach would also potentially hang a connection when both ends choose to wait for the other to go first in opening a logical channel.
The present invention offers a reliable, low-delay solution for multimedia endpoints that desire or require symmetrical codec selection. This solution guarantees that an endpoint desiring symmetrical codecs can achieve this desire, whether it is master or slave, whether it's peer can recognize conflicts or not, whether it's peer also desires symmetrical codecs, and without regard to the vendor implementing the peer equipment. The solution is also low-delay, as it reacts proactively to conflicts, and without imposing fixed system delays.
In one aspect of the present invention, a method of establishing media connections with a remote endpoint is disclosed. An endpoint that desires a symmetrical connection opens a first logical channel of a type selected from its peer's capability set—a type that also matches a codec that it desires to receive. It does this without waiting to see which type of codec its peer actually requests for the incoming channel. If the peer requests a symmetrical channel, the two-way connection has been established with minimum delay. If the peer requests an asymmetrical channel, the endpoint closes its first logical channel and opens a second, using a codec that matches the peer's.
The present invention also includes a procedure for detecting and recovering from a situation where both endpoints close and open logical channels in an effort to match their peer's codec selection. One endpoint detects the condition and delays further channel open/close efforts, preferably for one measured round trip time, to allow the other end to establish the symmetrical channel.
In another aspect of the invention, a codec selector is disclosed. The codec selector comprises a codec conflict detector that detects conflicts between locally-requested and remotely-requested codecs. The codec selector also comprises a codec synchronizer that responds to a conflict detected by the codec conflict detector by closing a locally-requested codec and requesting a different codec that does not conflict with the remotely-requested codec.
This codec selector may be embodied, e.g., in a media gateway or in a media gateway controller. For example, it may be used to resolve conflicts in a media gateway that has a plurality of receive codecs and a plurality of transmit codecs, the gateway constrained such that some combinations of a receive codec and a transmit codec cannot be used on the same call.
REFERENCES:
patent: 5796808 (1998-08-01), Scott et al.
patent: 6246754 (2001-06-01), Cole et al.
patent: 6313879 (2001-11-01), Kubo et al.
patent: RE37569 (2002-03-01), Ayanoglu et al.
patent: 6373839 (2002-04-01), Clark et al.
patent: 6429902 (2002-08-01), Har-Chen et al.
Floryanzia Tyrone D.
Miles Michael Gregg
Panburana Pandit
Cisco Technology Inc.
Marger Johnson & McCollom
Nguyen Van
Olms Douglas
LandOfFree
Symmetrical codec selection in an asymmetrical codec... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Symmetrical codec selection in an asymmetrical codec..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Symmetrical codec selection in an asymmetrical codec... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3143372