December 1999 - sg16-avd - lists.packetizer.com

Re: H.245 "receiveAndTransmitAudioCapability" and symmetric codec s
by Tzvi Kasten 09 Dec '99

09 Dec '99

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(a)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(a)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(a)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(a)icn.siemens.de; h323implementors(a)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(a)imtc.org with text "info"

1 0

FW: Contribution for Conf Call on December 14
by Roy, Radhika R, ALARC 08 Dec '99

08 Dec '99

The SG16 mail server might be working now. > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Wednesday, December 08, 1999 3:35 PM > To: Roy, Radhika R, ALARC; 'paul.k.reddy(a)intel.com'; > 'vineet.kumar(a)intel.com'; 'jaakko.sundquist(a)nokia.com'; > 'peeter.pruuden(a)nokia.com'; 'senthil.sengodan(a)nokia.com'; > 'marc.roelands(a)siemens.atea.be'; 'martinze(a)cig.mot.com'; > 'lpg019(a)email.mot.com'; 'orsic(a)lucent.com'; > 'stephen.terrill(a)ericsson.com'; 'gosta.linder(a)lme.ericsson.se'; > 'Anders.Svennevik(a)era.ericsson.se'; 'mike(a)synacom.com'; 'stu(a)synacom.com'; > 'paul.jones(a)ties.itu.int'; 'baronson(a)acm.org'; > 'laurent.thiebaut(a)alcatel.fr'; 'Ameneh.Zahir-Emami(a)alcatel.fr' > Cc: 'Dale.Skran(a)ascend.com'; 'ggf(a)lucent.com'; 'okubo(a)GITI.OR.JP' > Subject: Contribution for Conf Call on December 14 > > Hi, Everyone: > > I am enclosing a contribution for the upcoming conference call on December > 14. > > This is a follow-up discussion of today's conference call. As I explained, > there are three distinct areas where we need to focus to develop the H.323 > mobility protocol. This contribution describes three distinct areas. For > each area contributions are needed. However, some contributions have > provided a complete solution in one of the areas. There contributions need > to be discussed in great detail immediately. For example, AT&T's > contributions - APCs-1651/1652. Similar is the case for other > contributions. > > I am also providing this contribution to all members so that all members > provide their comments immediately. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > <<MTD-y_ATT.doc>> > > PS: SG16 email reflector is still down. >

1 0

ITU-SG16 Mail List Active Again
by Meyer, Greg W 08 Dec '99

08 Dec '99

Hi: I've discovered that mail lists are like children - they seem to know when you're not looking and will do something you don't want them to. In this case, I was away from my email for several days and that's when this mail reflector decided to have problems. An endless loop caused LISTSERV to stop. I've deleted the offending subscriber and the list should be back online now. My apologies for any inconvenience. Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506

1 0

IGNORE THIS EMAIL: testing to see if this reflector is working
by Kumar, Vineet 08 Dec '99

08 Dec '99

testing to see if this reflector is working

1 0