Frank,
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@mailbag.cps.INTEL.COM]On Behalf Of Frank Derks Sent: Friday, June 29, 2001 8:56 AM To: ITU-SG16@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. 6.2.5.3 states that an endpoint need not indicate this 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 6.2.5.3.
The question therefore remains, must G.711 support always be indicated in the capability set if the endpoint has no knowledge about the properties of the network that it will be communicating on?
Regards,
Frank
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com