- sg16-avd - lists.packetizer.com

Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt
by Tom-PT Taylor 10 Dec '99

10 Dec '99

I propose WG Last Call based on this document, with the expiry two weeks hence (24 December). Changes from the previous version are as follows: - removed reqt 5.6 c) Support general test capabilities, for example loopbacks through the MG to test DSP operation. It was agreed that inward loopbacks are outside the scope of the protocol - they are not part of call control, so would be handled by some other maintenance protocol. Thus the above requirement is deleted. - reqt 5.7 a) - changed word call to connection - table in section 11 - removed wiretap - reqt 11.1.3.1 a) rewording of 2nd bullet on addressing - didn't mean wildcarding, meant instead allowing the gateway to choose (part of) the identifier The references need to be completed still, and there may be an editor's note or two that should still come out. > -----Original Message----- > From: Internet-Drafts(a)IETF.ORG [SMTP:Internet-Drafts@IETF.ORG] > Sent: Friday, December 10, 1999 8:08 AM > To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM > Subject: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Media Gateway Control Working Group of > the IETF. > > Title : Media Gateway control protocol architecture and > requirements > Author(s) : N. Greene, M. Ramalho, B. Rosen > Filename : draft-ietf-megaco-reqs-09.txt > Pages : 45 > Date : 09-Dec-99 > > TThis document describes protocol requirements for the Media Gateway > control protocol between a Media Gateway Controller and a Media Gateway. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-megaco-reqs-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. << Message: >>

1 0

Question! MCU cascading
by Jun-young Heo 10 Dec '99

10 Dec '99

Hi everyone! I have a question about MCU cascading. I know MC cascading from reading H.323v2 recommendation. But, i'm not sure how to control media distribution. I think MasterMC knows only capset of local terminals connected directly. so, MasterMC can't make a SCM(selected communication mode) about all terminals. How MasterMC knows it? Eventually, I want to know about MP cascading excatly. One more question. Is SessionID in message related to logical channel and CommunicationModeCommand, distributed by MC? H.245 recommendation says, "Only the master can create the session identification." at p.81. But, Netmeeting and ViewStation which I tested create session ID itselft by convention(Audio:1, Video:2). Is it right? I wish experts advise to me. thanks for reading. bye.

1 0

[Robustness] RADVision's input for the conference call
by Orit Levin 09 Dec '99

09 Dec '99

Hello Maureen and all the others! Please count on two RADVision's legs for the conference: one for myself and the other for RADVision Ltd. in Israel. I am attaching our input to the conference call. The paper discusses problems and possible solutions for GK failure in the middle of managing routed calls. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com

1 0

[Robustness] Conference Call
by Steve.Edgar＠NOKIA.COM 09 Dec '99

09 Dec '99

The conference call for robustness, arranged by Maureen Stillman, is scheduled for Tuesday, December 14th at 11:00 AM EST USA. Conf call number: 613-688-2795 Access code 9234# Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Failure scenarios will be discussed. Please send failure scenarios to the Study Group 16 mailing list.

1 0

H.323 Annex L Conference Call Announcement
by Dave Walker 09 Dec '99

09 Dec '99

There will be a conference call next week to discuss the evolution of the H.323 stimulus protocol (Annex L), the most recent draft being APC-1660. The call will be on Wednesday, December 15 at 11:00 AM EST. I will be publishing call coordinates and an agenda on Monday. I would appreciate if everyone interested in participating would send me mail so that I can reserve a sufficient number of ports. Regards, Dave Walker Mitel Corporation Ontario, CANADA

2 1

FW: H.323 questions
by Roy, Radhika R, ALARC 09 Dec '99

09 Dec '99

Hi, Everyone: I am enclosing Ben's questions to the SG16 members for their answer because I believe that there are many members who might better insights for taking part in H.323 development. Best regards, Radhika R. Roy AT&T +1 732 420 1580 > -----Original Message----- > From: ben-w(a)jlonline.com [SMTP:ben-w@jlonline.com] > Sent: Thursday, December 09, 1999 4:09 AM > To: Roy, Radhika R, ALARC > Subject: H.323 questiones > > Hi Mr.Radhika , > I have some questiones about Ad Hoc Conference defined in ITU-T > Recommendation H.323. > > H.323 Section 8.4.3.1 states: > > Endpoint 1 creates a conference with Endpoint 2 as follows: > A1) Endpoint 1 sends a Setup message to Endpoint 2 containing a > globally unique CID ? N and conferenceGoal = > create according to the procedure in 8.1. > A2) Endpoint 2 has the following options: > .... > A2d) If Endpoint 2 is an MC(U) that hosts multiple conferences and > wishes to provide Endpoint 1 with a choice > of conferences to join, it can send a Facility message > indicating conferenceListChoice and a list of > conferences that Endpoint 1 may choose from. The list of > conferences is sent as part of the Facility- UUIE. > For backward compatibility, with version 1 endpoints, > conference lists are only provided if the > protocolIdentifier in Endpoint 1's Setup message indicates > that it is version 2 or above. > > Upon receipt of this conferenceListChoice Facility message, > Endpoint 1 may join a conference from the list > of conferences by sending a new Setup message to the MC(U) on > the Call Signalling Channel which contains > the selected CID and which has conferenceGoal = join. If > Endpoint 1 chooses not to join any of the listed > conferences, it shall send a Release Complete message to the > MC(U). > > 1. When EndPoint 1 calling EndPoint 2(MCU),MCU "wishes to provide > Endpoint 1 ...",what > does it mean?Can't any endpoint get a list of conferences?What > decides it's wish? > CUSeeMe Pro and NetMeeting get diferent list of conferences from > MeetingPoint(MCU), I > called MeetingPoint too,but I can't get a list of conferences,I > connected with it just like an > endpoint.Why?Does it mean I have created a new conference in a > MCU?! > 2. If an EndPoint is a standard H.323 client,and MCU provide it with > a list conferences,then it > has only two choices: join or release.It means the EndPoint can't > create a conference!How to > create a conference in a MCU?Who is the initiator? > 3. If I want to learn details about MCU calling procedures,what other > protocols should I study? > > The questiones puzzle me,can you help me ? > > Thanks, > Ben. > email: ben-w(a)jlonline.com <mailto:ben-w@jlonline.com>

2 1

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