How "mandatory" is the presence of G.711 in the Terminal Capability set

Paul Long plong at IPDIALOG.COM
Fri Jun 29 11:03:03 EDT 2001


I see your point. I suppose what it comes down to is that if an EP doesn't
know whether it will be communicating over a low-bit-rate segment and it
does not advertise support for G.711 and indeed does not support G.711, it
is not compliant. Period. However, if it is in communication with a remote
EP that supports at least one of the codecs for each session that it
supports, it will be interoperable, and, at least for this call, the fact
that it is not compliant is academic. Support for G.711 is put in their as
the ubiquitous codec to assure at least base-level interoperability. Break
that and you risk non-interoperability.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Mailing list for parties associated with ITU-T Study Group 16
[mailto:ITU-SG16 at mailbag.cps.INTEL.COM]On Behalf Of Frank Derks
Sent: Friday, June 29, 2001 8:56 AM
To: ITU-SG16 at mailbag.cps.INTEL.COM
Subject: How "mandatory" is the presence of G.711 in the Terminal
Capability set

6.2.5/H.323 states that all terminals must be _capable_ to encode and decode
G.711 A-law and u-law. states that an endpoint need not indicate
support if it knows that it will be communicating on a low bit-rate segment.

This seems somewhat contradictory. However, the fact that G.711 must be
supported does not really mean that support should also be indicated in the
capability set. This would be in line with the statement in

The question therefore remains, must G.711 support always be indicated in
capability set if the endpoint has no knowledge about the properties of the
network that it will be communicating on?



For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at

More information about the sg16-avd mailing list