Paul, Regarding your two questions: 1. Do we need a way to express symmetric codecs. - Yes of course! 2. Will using receiveAndTransmit caps for this cause problems - Considering that vendors are already using receiveAndTransmit caps for this and considering that assuming that the endpoint is signaling symmetric codecs in a case where it is not will not break anything in terms of interoperability I would think that the safest way to act when receiving receiveAndTransmit caps is to assume that the capability is symmetrical. As this seems the most convenient way to address the issue of symmetrical codecs and as vendors have already interpreted it and are using it this way I would suggest the document be updated to have the receiveAndTransmit caps be the way to express symmetric codecs. Regards Tzvi Kasten Networking Infrastructures Group Manager Research & Development VCON Ltd. Tel: 09-9590020 ( 972-9-959-0020) Email: zvik@vcon.co.il http://www.vcon.com

-----Original Message----- From: Paul Long [SMTP:plong@SMITHMICRO.COM] Sent: Tuesday, December 07, 1999 3:35 PM To: h323implementors@imtc.org Subject: RE: H.245 "receiveAndTransmitAudioCapability" and symmetric codecs

Paul,

The capability table is a sort of artist's pallet, containing all the colors that he or she may use. The descriptors, on the other hand, are the brushes that mix the colors and apply them to the canvas. Without descriptors, no modes are expressed--the canvas is blank. (Hey, I think I could write a haiku about this. :-) ) It is H.245 and not H.323 that stipulates this (B.2.2.2/H.245v5: "CapabilityDescriptors are used to indicate a terminal's capability to transmit and receive"), so a referencing Recommendation would have to override H.245 to avoid using descriptors, none of which do, as far as I know.

IMO, the purpose of a receiveAndTransmit cap is at minimum to provide a shorthand replacement for separate receive and transmit caps. From what I've seen, that's what vendors by and large use them for. I don't think the H.245 authors ever intended receiveAndTransmit caps to stand alone, unreferenced in the capability table. Moreover, I believe that the authors intended receiveAndTransmit caps to express symmetric codecs, although this is clearly not stated in H.245 (or H.323). Finally, I believe we could add normative text to H.245 that says that, without the slightest possibility of breaking existing implementations, receiveAndTransmit caps shall express symmetric codecs. I've worked through different scenarios and have convinced myself of this.

The two questions I pose to this reflector are, 1) do you agree that we need some way to express symmetric codecs and 2) can you see any way that requiring receiveAndTransmit caps to express this could cause existing implementations to break or make things any worse than they already are, i.e., one-way audio? Here's an important point: I am saying that this _cannot_ break an existing implementation not that it _probably_ won't.

(Should we move this discussion to the ITU-SG16@MAILBAG.INTEL.COM reflector?)

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Paul E. Jones [mailto:paul.jones@ties.itu.int] Sent: Monday, December 06, 1999 11:33 PM To: Karl.Klaghofer@icn.siemens.de; h323implementors@imtc.org Subject: Re: H.245 "receiveAndTransmitAudioCapability" and symmetric codecs

Karl,

Here's my interpretation on this topic:

To indicate simultaneous capabilities, an endpoint will normally send a capability descriptor table with the transmit and receive capabilities. Each table entry will list the codecs that may be used simultaneously. The remote endpoint may select a single descriptor table entry to use when selecting channels to open, but may not select one codec from one table entry and another from another table entry.

Here's a section from 6.2.8.1/H.323 on this topic:

--- BEGIN The terminal's total capabilities are described by a set of capabilityDescriptor structures, each of which is a single simultaneousCapabilities structure and a capabilityDescriptorNumber. By sending more than one capabilityDescriptor, the terminal may signal dependencies between operating modes by describing different sets of modes which it can simultaneously use. For example, a terminal issuing two capabilityDescriptor structures, one { {H.261, H.263}, {G.711, G.723.1, G.728} } as in the previous example, and the other { {H.262}, {G.711} }, means the terminal can also operate the H.262 video codec, but only with the low-complexity G.711 audio codec. --- END

Inside a given table entry, the endpoint will indicate it's capability to transmit G.711, for example, and receive G.711. Rather than insert two capabilities-- one for transmit capability and one for receive capability-- the endpoint will provide a single "receiveAndTransmitAudioCapability". If this "combined" capability did not exist, the endpoint could just examine the capability descriptor tables looking for descriptor table entries that had an acceptable transmit and receive capability and work within that context.

Perhaps the main use for the "receiveAndTransmitAudioCapability" is the case when there is no capability descriptor tables is transmitted at all. Suppose you have an audio device that can do G.723 and G.711, but only one at a time. Rather than build a capability descriptor table that looks like this:

{G.711 Receive, G.711 Transmit} {G.723 Receive, G.723 Receive}

one could simply send over two capabilities, one for G.723 and one for G.711, that are both "receiveAndTransmitAudioCapabilities". That may have been the intention of the sentence you quote below. However, I would not that this not legal in H.323. Specifically, H.323 says that ``all H.323 terminals shall transmit at least one capabilityDescriptor structure.'' Perhaps this text was inserted to allow other device types other than H.323 to avoid using descriptors in simple cases.

I hope this helps... and is consistent with others' views.

Paul

------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request@imtc.org with text "info"