FW: H.323 questions

[Roy, Radhika R, ALARC]

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 at vcon.co.il
http://www.vcon.com


> -----Original Message-----
> From: Paul Long [SMTP:plong at SMITHMICRO.COM]
> Sent: Tuesday, December 07, 1999 3:35 PM
> To:   h323implementors at 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 at MAILBAG.INTEL.COM
> reflector?)
>
> Paul Long
> Smith Micro Software, Inc.
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paul.jones at ties.itu.int]
> Sent: Monday, December 06, 1999 11:33 PM
> To: Karl.Klaghofer at icn.siemens.de; h323implementors at 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 at imtc.org with text "info"