- sg16-avd - lists.packetizer.com

Re: ITU-T Santiago Contributions
by Sakae OKUBO 23 Apr '99

23 Apr '99

Dear Mr. Moscovici, Interim Rapporteur meetings are autonomously organized by the interested experts, but the SG16 meeting in Santiago is official and managed by Mr. Fabio Bigi, ITU-TSB. In addition to White Contributions, input documents can only be submitted as follows: - Delayed Contributions from member organizations. They go through national procedures and shall reach ITU-TSB not later than 5 May 1999 as described in Collective-letter 5/16. You con find this and relevant TSB Circular 173 at the ITU Web site. - Temporary Documents from Rapporteurs. They can be accepted even just before the meeting. Please also note that only ITU-T memebers can attend the Santiago meeting. LM> I would like to submit two contributions to the Santiago meeting: LM> 1. "Modifications to H.225.0 Annex G" from Israel, VocalTec as source. LM> 2. "Editorial Corrections to H.225.0 Annex G" from Editor (myself). LM> Note these two are proposals that affect the white draft for decision at LM> this meeting. So, the first should go through Israel process as a Delayed Contribution. The source can either be Israel Administration or ITU-T Sector Member (company). Please do not forget about the deadline, 5 May, otherwise Mr. Bigi will not accept your contribution. The second should go through Dale. LM> Since I am not familiar with the procedures at the plennary meetings, LM> please advise: do I need APC allocations? Are there other things I LM> should do? There is no need for APC numbers, they are only for self organized Rapporteur meetings. LM> I will have these two contributions available on the AVC site by next LM> week. Your posting is appreciated. Whatever made available will be moved to 9905_San directory without APC numbers for the expert convenience. LM> As for ordinary rapporteur contributions - VocalTec intends to submit LM> two other contributions. Do they have to be on a national basis (i.e. LM> Israel), or on a company basis, as in a Rapporteur meeting. LM> Do we need APCs? Even if your contributions are for the Rapporteur meeting portion of the Santiago week, they are managed by Mr. Bigi. No need for APC numbers. You need to submit them as Delayed Contributions. Again, the source can be VocalTec if it is an ITU-T Sector member. Otherwise, they may be submitted as Israel contributions subject to your national process. Please allow me copy this response to all the memebers registered to the Q.12-14 group reflector for their information. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: FW: RRQ Registration in H.323 V2
by Rob B 23 Apr '99

23 Apr '99

Chris, H.323 V2 specifically says that each alias address should map to a unique transport address. So, as you pointed out my second RRQ would get rejected because alias is the same "voip-gw.hotmail.com" but a different transport address is registered :-( So, the only option left for me is to choose some dummy alias in my RRQs. Section 7.2.2 H.323V2 "A Gateway or MCU may register a single Transport address or multiple transport addresses. The use of multiple transport addresses may simplify the routing of calls to specific ports" How can a _single_ gateway achieve the above stated. (Because what I am doing by sending multiple RRQs with different aliases is essentially simulating multiple logical gateways in the network.) Btw, one another related question. What is the meaning of multiple callSignalAddresses of _same_ transport type in RRQ.callSignalAddress. Is this possible and if possible how will the gatekeeper use them? I have a private mail from one vendor that multiple callSignalAddresses of the same transport type are possible in RRQ but no one uses them. I think I have to agree with him. Thanks for your time. -Chris. >From this description it seems fairly clear that you (logically, from a >protocol point of view) have two gateways that happen to be collocated. The >only alias you're passing around is the phone number, and that wants to go >to different places according to how it starts. However in an earlier mail >you said you only had a single gateway because you only have a single >terminalAlias ("something like voip-gw.hotmail.com"). As this alias appears >not to be passed around at any point during call setup it appears >irrelevant, although registering the same alias to different (logical) >gateways to the same gatekeeper at the same time may cause problems to some >gatekeepers. > >Regards, >Chris > >> -----Original Message----- >> From: Rob B [mailto:robb112@HOTMAIL.COM] >> Sent: 21 April 1999 7:10 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: FW: RRQ Registration in H.323 V2 >> >> >> Chris, >> >> > >> >Just trying to understand the problem fully before jumping in with a >> >suggested solution: >> >How are you expecting people to call via this gateway? >> >Is the intention to place a call to multiple destionationInfos, >> specifying >> >first an alias that identifies the gateway, followed by a full phone >> number >> >starting 408 or 409? If not, what is the intended action from an >> endpoint >> >attempting to call through this gateway? >> > >> >> My customers would have something like Netmeeting. They would >> make calls with an area code, say like 1-408-555-6666. >> >> Let us say I have GW1 and GK. GW1 supports area codes 408 and >> 409. It registers these two voice call prefixes (1408 and 1409) >> with GK along with port numbers 2000 and 3000. Any incoming >> calls on port 2000 are automatically assumed to be outgoing >> calls to area code 408 (so that GW1 need not again parse the >> calledPartyNumber in the incoming message). Parsing of the >> remaining number would be done at much later point in time. >> >> Now, when a call originates from netmeeting, the ARQ would contain >> the destination telephone number (1408555666) in the >> "destinationInfo". GK receives this ARQ and figures out >> that it has GW1 which registered the prefix 1408. So, GK returns >> the <GW1 IP Address + 2000> to netmeeting. And netmeeting would >> directly send the Q.931 SETUP message GW1's port 2000. >> >> This is what I am looking for. >> >> Thanks, >> -Chris (R) >> >> >> >> >I have a question on RRQ registration in H.323V2. Let us say >> >> >I have a gateway that supports area codes 408, 409. I want >> >> >my gatekeeper to route calls to area codes 408 and 409 >> >> >to my local TCP ports 2000 and 3000 respectively. How should >> >> >I construct my RRQ message? >> >> > >> >> >Shall I send two RRQs with same endpoint identifier >> >> >(because I have only one gateway) with tuples >> >> ><408, 2000> and <409, 3000>. >> >> > >> >> ><x,y> means: x: carried in SupportedProtocols.prefix >> >> > y: carried in callSignallingAddress of RRQ message >> >> > >> >> >Is my understanding correct? >> >> > >> >> >-Chris Rob >> >> > >> >> > >> >> >> _______________________________________________________________ >> Get Free Email and Do More On The Web. Visit http://www.msn.com >> _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

2 1

Megaco reqs draft is 01, not 02...: I-D ACTION:draft-ietf-megaco- reqs-01.txt
by Nancy-M Greene 22 Apr '99

22 Apr '99

Everyone, Since the requirements draft we just issued was the first revision that the IESG saw, the number of it is -01 instead of -02 as I previously announced. So, if you are looking for the latest megaco requirements draft, the one to look for is draft-ietf-megaco-reqs-01.txt, dated April 18/99. (See below). It is identical to the -02 version at ftp://standards.nortelnetworks.com/megaco/docs/oslo99 (at some point I will rename the -02 to -01 on that site...) Sorry for the mixup. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Internet-Drafts@IETF.ORG[SMTP:Internet-Drafts@IETF.ORG] > Sent: Wednesday, April 21, 1999 1:10 PM > To: MEGACO(a)standards.nortelnetworks.com > Subject: I-D ACTION:draft-ietf-megaco-reqs-01.txt > > <<Message: Microsoft Exchange Message>> > 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-01.txt > Pages : 35 > Date : 20-Apr-99 > > This 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-01.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-01.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-01.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. >

1 0

Re: Media Gateway Control Requirements
by Gunnar Hellstrom 22 Apr '99

22 Apr '99

I checked the Megaco requirements mainly from the point of view of how well it covers gatewaying between different forms of real time text conversation facilities. The most apparent need is between the current analogue network based text telephones and IP text phones that are in the process of being defined in SG16. The current textphones are working with different types of modem-like signalling ( that all can be joined by the V.18 modem in the gateway) while in IP networks it is T.140 carried by a data protocol. With the current efforts in the US to arrange some kind of gateway between land based text telephony and mobile text telephony, work in this direction is already going on. I found very little influence. And that might pose a question: Is Megaco too vague, does it need to get more specific in its requirements to really imply something? But that might be the next step - the protocols and functions. I want to suggest the following modifications to specifically mention the important real time text gatewaying: ----------------------------------------------------------------------------- 5.2 d : insert "text" together with the other media, to read "e.g. audio, text, video, T.120 ) 5.3 d : insert "text telephony" before FAX 11. Table 1. I am not sure what this table indicates. All multimedia protocols are missing. Is it some kind of very basic mandatory media requirements? Without really knowing, I recommend: For ISDN, add Multi-media to the applications. For Analogue, and Restricted, add Text telephony after FAX. Insert a new section 11.2.4 ( pushing the existing down one step) 11.2.4 Trunking/Access Gateway with text telephone access ports 11.2.10 IVR Unit Insert a requirement: IVR should never be the only way to control the MG. Text based and web based control are important alternatives. Accepted? Gunnar Hellström At 10:41 1999-04-19 -0400, Tom-PT Taylor wrote: >If Megaco and SG 16 are to come up with a common Media Gateway control >protocol, we must agree on the requirements. I am attaching a zipped copy >of the latest draft of the Megaco requirements document, with the hope that >SG 16 experts will feel free to comment on it. You can pass comments either >to this list or to megaco(a)standards.nortelnetworks.com. > >A version of this document will be submitted as a Delayed Contribution to >the Santiago meeting. Depending on the number of comments we receive, that >version may be the attached one or a revision of it. > > <<draft-ietf-megaco-reqs-02.zip>> > >Tom Taylor >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) >Tel.: +1 613 736 0961 (ESN 396-1490) >FAX: same number by prior arrangement (manual answer). > > >Attachment Converted: "c:\_Omnitor\Attach\draft-ietf-megaco-reqs-02.zip" > ----------------------------------------------- Gunnar Hellstrom Representing Ericsson in ITU-T E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

Re: Any news on new megaco draft ?
by Brian Rosen 22 Apr '99

22 Apr '99

A new version was put out to the MEGACO list on Monday. The draft should appear on the I-D ftp site in a day or two. If you would like I can send it to the SG16 list. Brian > -----Original Message----- > From: Boaz Michaely [mailto:Boaz_Michaely@vocaltec.com] > Sent: Thursday, April 22, 1999 7:11 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Any news on new megaco draft ? > > > Is there an update for the megaco protocol ? I thought one > was expected on > April 16 ? > Thanks, > > Boaz Michaely > Senior Program Manager, Advanced Technologies > VocalTec Communications Ltd > e-mail boaz(a)vocaltec.com >

1 0

Re: FW: RRQ Registration in H.323 V2
by Chris Purvis 22 Apr '99

22 Apr '99

Chris (R) [Why do your mails come from RobB???], >From this description it seems fairly clear that you (logically, from a protocol point of view) have two gateways that happen to be collocated. The only alias you're passing around is the phone number, and that wants to go to different places according to how it starts. However in an earlier mail you said you only had a single gateway because you only have a single terminalAlias ("something like voip-gw.hotmail.com"). As this alias appears not to be passed around at any point during call setup it appears irrelevant, although registering the same alias to different (logical) gateways to the same gatekeeper at the same time may cause problems to some gatekeepers. Regards, Chris > -----Original Message----- > From: Rob B [mailto:robb112@HOTMAIL.COM] > Sent: 21 April 1999 7:10 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FW: RRQ Registration in H.323 V2 > > > Chris, > > > > >Just trying to understand the problem fully before jumping in with a > >suggested solution: > >How are you expecting people to call via this gateway? > >Is the intention to place a call to multiple destionationInfos, > specifying > >first an alias that identifies the gateway, followed by a full phone > number > >starting 408 or 409? If not, what is the intended action from an > endpoint > >attempting to call through this gateway? > > > > My customers would have something like Netmeeting. They would > make calls with an area code, say like 1-408-555-6666. > > Let us say I have GW1 and GK. GW1 supports area codes 408 and > 409. It registers these two voice call prefixes (1408 and 1409) > with GK along with port numbers 2000 and 3000. Any incoming > calls on port 2000 are automatically assumed to be outgoing > calls to area code 408 (so that GW1 need not again parse the > calledPartyNumber in the incoming message). Parsing of the > remaining number would be done at much later point in time. > > Now, when a call originates from netmeeting, the ARQ would contain > the destination telephone number (1408555666) in the > "destinationInfo". GK receives this ARQ and figures out > that it has GW1 which registered the prefix 1408. So, GK returns > the <GW1 IP Address + 2000> to netmeeting. And netmeeting would > directly send the Q.931 SETUP message GW1's port 2000. > > This is what I am looking for. > > Thanks, > -Chris (R) > > > >> >I have a question on RRQ registration in H.323V2. Let us say > >> >I have a gateway that supports area codes 408, 409. I want > >> >my gatekeeper to route calls to area codes 408 and 409 > >> >to my local TCP ports 2000 and 3000 respectively. How should > >> >I construct my RRQ message? > >> > > >> >Shall I send two RRQs with same endpoint identifier > >> >(because I have only one gateway) with tuples > >> ><408, 2000> and <409, 3000>. > >> > > >> ><x,y> means: x: carried in SupportedProtocols.prefix > >> > y: carried in callSignallingAddress of RRQ message > >> > > >> >Is my understanding correct? > >> > > >> >-Chris Rob > >> > > >> > > > > _______________________________________________________________ > Get Free Email and Do More On The Web. Visit http://www.msn.com >

1 0

RRQ Registration in H.323 V2
by Rob B 22 Apr '99

22 Apr '99

Is the implementors mailing list down, apparently no one got this message. If anybody from SG16 can explain ... Thanks From: "Rob B" <robb112(a)hotmail.com> To: h323implementors(a)imtc.org CC: robb112(a)hotmail.com Date: Thu, 15 Apr 1999 14:30:50 PDT SG16 experts, I have a question on RRQ registration in H.323V2. Let us say I have a gateway that supports area codes 408, 409. I want my gatekeeper to route calls to area codes 408 and 409 to my local TCP ports 2000 and 3000 respectively. How should I construct my RRQ message? Shall I send two RRQs with same endpoint identifier (because I have only one gateway) with tuples <408, 2000> and <409, 3000>. <x,y> means: x: carried in SupportedProtocols.prefix y: carried in callSignallingAddress of RRQ message Is my understanding correct? -Chris Rob _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

2 1

Any news on new megaco draft ?
by Boaz Michaely 22 Apr '99

22 Apr '99

Is there an update for the megaco protocol ? I thought one was expected on April 16 ? Thanks, Boaz Michaely Senior Program Manager, Advanced Technologies VocalTec Communications Ltd e-mail boaz(a)vocaltec.com

1 0

Re: FW: RRQ Registration in H.323 V2
by Rob B 21 Apr '99

21 Apr '99

Chris, > >Just trying to understand the problem fully before jumping in with a >suggested solution: >How are you expecting people to call via this gateway? >Is the intention to place a call to multiple destionationInfos, specifying >first an alias that identifies the gateway, followed by a full phone number >starting 408 or 409? If not, what is the intended action from an endpoint >attempting to call through this gateway? > My customers would have something like Netmeeting. They would make calls with an area code, say like 1-408-555-6666. Let us say I have GW1 and GK. GW1 supports area codes 408 and 409. It registers these two voice call prefixes (1408 and 1409) with GK along with port numbers 2000 and 3000. Any incoming calls on port 2000 are automatically assumed to be outgoing calls to area code 408 (so that GW1 need not again parse the calledPartyNumber in the incoming message). Parsing of the remaining number would be done at much later point in time. Now, when a call originates from netmeeting, the ARQ would contain the destination telephone number (1408555666) in the "destinationInfo". GK receives this ARQ and figures out that it has GW1 which registered the prefix 1408. So, GK returns the <GW1 IP Address + 2000> to netmeeting. And netmeeting would directly send the Q.931 SETUP message GW1's port 2000. This is what I am looking for. Thanks, -Chris (R) >> >I have a question on RRQ registration in H.323V2. Let us say >> >I have a gateway that supports area codes 408, 409. I want >> >my gatekeeper to route calls to area codes 408 and 409 >> >to my local TCP ports 2000 and 3000 respectively. How should >> >I construct my RRQ message? >> > >> >Shall I send two RRQs with same endpoint identifier >> >(because I have only one gateway) with tuples >> ><408, 2000> and <409, 3000>. >> > >> ><x,y> means: x: carried in SupportedProtocols.prefix >> > y: carried in callSignallingAddress of RRQ message >> > >> >Is my understanding correct? >> > >> >-Chris Rob >> > >> > _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

Re: Media Gateway Control Requirements
by Kumar, Vineet 21 Apr '99

21 Apr '99

Tom, Seems that multimedia is not a requirement in the Megacodraft. I would assume that Multimedia would be a requirement from SG16 because that's what we do. vineet -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, April 19, 1999 7:41 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Media Gateway Control Requirements If Megaco and SG 16 are to come up with a common Media Gateway control protocol, we must agree on the requirements. I am attaching a zipped copy of the latest draft of the Megaco requirements document, with the hope that SG 16 experts will feel free to comment on it. You can pass comments either to this list or to megaco(a)standards.nortelnetworks.com. A version of this document will be submitted as a Delayed Contribution to the Santiago meeting. Depending on the number of comments we receive, that version may be the attached one or a revision of it. <<draft-ietf-megaco-reqs-02.zip>> Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Re: Media Gateway Control Requirements
by Roni Even 21 Apr '99

21 Apr '99

Tom, I agree with Vineet. I also like to point out that in The H.GCP documents in paragraph 6.1 the requiremenst section 2 specify audio only. On the other hand there is a multimedia hints in number 3 and 5. Roni Even -----Original Message----- From: Kumar, Vineet <vineet.kumar(a)INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: יום רביעי 21 אפריל 1999 19:36 Subject: Re: Media Gateway Control Requirements >Tom, > >Seems that multimedia is not a requirement in the Megacodraft. I would >assume that Multimedia would be a requirement from SG16 because that's what >we do. > >vineet > >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] >Sent: Monday, April 19, 1999 7:41 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Media Gateway Control Requirements > > >If Megaco and SG 16 are to come up with a common Media Gateway control >protocol, we must agree on the requirements. I am attaching a zipped copy >of the latest draft of the Megaco requirements document, with the hope that >SG 16 experts will feel free to comment on it. You can pass comments either >to this list or to megaco(a)standards.nortelnetworks.com. > >A version of this document will be submitted as a Delayed Contribution to >the Santiago meeting. Depending on the number of comments we receive, that >version may be the attached one or a revision of it. > > <<draft-ietf-megaco-reqs-02.zip>> > >Tom Taylor >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) >Tel.: +1 613 736 0961 (ESN 396-1490) >FAX: same number by prior arrangement (manual answer). >

1 0

Re: FW: RRQ Registration in H.323 V2
by Chris Purvis 21 Apr '99

21 Apr '99

Chris, Just trying to understand the problem fully before jumping in with a suggested solution: How are you expecting people to call via this gateway? Is the intention to place a call to multiple destionationInfos, specifying first an alias that identifies the gateway, followed by a full phone number starting 408 or 409? If not, what is the intended action from an endpoint attempting to call through this gateway? Regards, Chris (P) -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Rob B [mailto:robb112@HOTMAIL.COM] > Sent: 21 April 1999 12:17 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FW: RRQ Registration in H.323 V2 > > > Gaurav, > > Nope, it is one single logical gateway. It has only one > terminalAlias (something like voip-gw.hotmail.com) But it > supports outgoing voice calls to area codes 408 and 409. > > As specified in section 7.2.2 of H.323 V2 spec para 2 > "The use of multiple transport addresses may simplify > the routing of calls to specific ports". I am trying to > simplify routing in my gateway. > > Is the above statement in H.323 V2 correct now? Is there > anyone on the list who has tried to do something like > above? > > Or is it that, to acheive my goal I have to divide > my gateway into logical H.323 entities which I am > not sure is needed. > (if each registration of RRQ is allocated a different > endpoint identifier then from GK perspective there are > multiple H.323 entities). > > Regards, > -Chris > > PS: Endpoint identifier is allocated by GK and returned > to endpoint via RCF. (The same endpoint identifier will > be used in keep alive RRQs.) If multiple RRQ's like I proposed > in my original mail is allowed by H.323 V2 then the > second RRQ would copy the endpoint identifier from > first RCF. > > >Hi Chris, > > As per my understanding, you are talking of different logical > gateways > >that > >are bundled together into a single *box*. Each such logical gateway > must > >register with the gatekeeper. The terminalAlias could be used to > identify > >the > >logical GW and the callSignalAddress would specify the contact point. > Hence, > >you > >would have to send 2 RRQs. Also, the endpointIdentifier is generated > by the > >GK > >and returned in the RCF and so cannot be specified by the GW at time > of > >registration. > > > > Any comments? > > > >Regards, > >Gaurav Makkar > > > > > > > >I have a question on RRQ registration in H.323V2. Let us say > >I have a gateway that supports area codes 408, 409. I want > >my gatekeeper to route calls to area codes 408 and 409 > >to my local TCP ports 2000 and 3000 respectively. How should > >I construct my RRQ message? > > > >Shall I send two RRQs with same endpoint identifier > >(because I have only one gateway) with tuples > ><408, 2000> and <409, 3000>. > > > ><x,y> means: x: carried in SupportedProtocols.prefix > > y: carried in callSignallingAddress of RRQ message > > > >Is my understanding correct? > > > >-Chris Rob > > > > > >_______________________________________________________________ > >Get Free Email and Do More On The Web. Visit http://www.msn.com > > > _______________________________________________________________ > Get Free Email and Do More On The Web. Visit http://www.msn.com >

1 0

lost mail
by Sergei Koren 21 Apr '99

21 Apr '99

Hi, because of problem with our mail server 16-17 of April 1999 Your mail, you sent in these days to email address elid(a)radvision.rad.co.il was lost. I would like to ask you to resend the email. Regards, Postmaster, RADVision ltd.

1 0

Santiago meeting information
by Sakae OKUBO 20 Apr '99

20 Apr '99

Dear SG16 colleagues, Attached please find Mr. Tosco's additional information on the Santiago meeting. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Date: Tue, 20 Apr 1999 13:53:11 +0200 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>,"DeGrasse, Bruce" <b.degrasse(a)cwix.com>, Freundlich <ggf(a)lucent.com>,"Geary, Tom" <tom.geary(a)CONEXANT.COM>,"Okubo, Sakae" <okubo(a)giti.or.jp>,"Robin-Champigneul, Yves" <yves.robinchampigneul(a)cnet.francetelecom.fr>,"Skran, Dale" <Dale.Skran(a)ascend.com>,"Thom, Gary" <gthom(a)delta-info.com> MIME-version: 1.0 Dear all, Returning from the coordination meeting held in Geneva on Saturday April 17, I give you some information about events connected to the SG16 meeting in Santiago. * It is confirmed that an International Workshop will be held on Monday, May 17 * There will be a conference dinner on Wednesday, May 19 * There will be a farewell lunch on Saturday, May 29, in a famous vineyard near Santiago (in the conference web site there is an incorrect indication about the date) * Please see the conference site (http://www.ict.uchile.cl/itut.sg16/) for further information Best regards Federico CSELT Via Reiss Romoli 274 10148 TORINO Italy Tel.: +39 0112285321 Fax: +39 0112285295 E_mail: federico.tosco(a)cselt.it

1 0

Re: FW: RRQ Registration in H.323 V2
by Rob B 20 Apr '99

20 Apr '99

Gaurav, Nope, it is one single logical gateway. It has only one terminalAlias (something like voip-gw.hotmail.com) But it supports outgoing voice calls to area codes 408 and 409. As specified in section 7.2.2 of H.323 V2 spec para 2 "The use of multiple transport addresses may simplify the routing of calls to specific ports". I am trying to simplify routing in my gateway. Is the above statement in H.323 V2 correct now? Is there anyone on the list who has tried to do something like above? Or is it that, to acheive my goal I have to divide my gateway into logical H.323 entities which I am not sure is needed. (if each registration of RRQ is allocated a different endpoint identifier then from GK perspective there are multiple H.323 entities). Regards, -Chris PS: Endpoint identifier is allocated by GK and returned to endpoint via RCF. (The same endpoint identifier will be used in keep alive RRQs.) If multiple RRQ's like I proposed in my original mail is allowed by H.323 V2 then the second RRQ would copy the endpoint identifier from first RCF. >Hi Chris, > As per my understanding, you are talking of different logical gateways >that >are bundled together into a single *box*. Each such logical gateway must >register with the gatekeeper. The terminalAlias could be used to identify >the >logical GW and the callSignalAddress would specify the contact point. Hence, >you >would have to send 2 RRQs. Also, the endpointIdentifier is generated by the >GK >and returned in the RCF and so cannot be specified by the GW at time of >registration. > > Any comments? > >Regards, >Gaurav Makkar > > > >I have a question on RRQ registration in H.323V2. Let us say >I have a gateway that supports area codes 408, 409. I want >my gatekeeper to route calls to area codes 408 and 409 >to my local TCP ports 2000 and 3000 respectively. How should >I construct my RRQ message? > >Shall I send two RRQs with same endpoint identifier >(because I have only one gateway) with tuples ><408, 2000> and <409, 3000>. > ><x,y> means: x: carried in SupportedProtocols.prefix > y: carried in callSignallingAddress of RRQ message > >Is my understanding correct? > >-Chris Rob > > >_______________________________________________________________ >Get Free Email and Do More On The Web. Visit http://www.msn.com _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

H.323 Implementers Guide Edits
by Jim Toga 20 Apr '99

20 Apr '99

Greetings, After some delay, I have completed the edits coming out of the Monterey meeting for the Implementers Guide. Please review the changes and verify that everything is as expected. I have incorporated (I believel) all of the relevent text mentioned in the Meeting report namely: APCs 1511,1512, 1520, 1522, 1533, 1506, and TDs 10, 14, 33. If I do not have any comments back by 4/16/99 then I will integrate these changes with the complete document in preparation for the Chile meeting. Best Regards, jimt. MetaTel - Boston, MA mailto:jim.toga@metatel.com +1-781-891-9000 PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7

3 2

Register for e-mail reflector
by sgk 19 Apr '99

19 Apr '99

Please register me for e-mail reflector. Thank you.

1 0

RequestSeqNum for MessageNotUnderstood
by Mike Ely 19 Apr '99

19 Apr '99

The following is an excerpt from H.225 V3: 7.17 Message Not Understood This message is sent whenever an H.323 endpoint receives a RAS message it does not understand. RequestSeqNum - Shall be the requestSeqNum of the unknown message, if it can be decoded, and zero otherwise. But in the ASN.1 included, the range for the request sequence number is: Requestseqnum ::= INTEGER (1..65535) With my latest version of the OSS compiler, I get a constraint violation attempting to send a zero request identifier. Is zero still the correct value when unable to decode a received PDU? Mike Michael Ely mely(a)paknetx.com http:\\www.paknetx.com

1 0

Media Gateway Control Requirements
by Tom-PT Taylor 19 Apr '99

19 Apr '99

If Megaco and SG 16 are to come up with a common Media Gateway control protocol, we must agree on the requirements. I am attaching a zipped copy of the latest draft of the Megaco requirements document, with the hope that SG 16 experts will feel free to comment on it. You can pass comments either to this list or to megaco(a)standards.nortelnetworks.com. A version of this document will be submitted as a Delayed Contribution to the Santiago meeting. Depending on the number of comments we receive, that version may be the attached one or a revision of it. <<draft-ietf-megaco-reqs-02.zip>> Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Re: RRQ Registration in H.323 V2
by Gaurav Makkar 19 Apr '99

19 Apr '99

Rob B <robb112(a)HOTMAIL.COM> on 04/16/99 11:34:28 PM Hi Chris, As per my understanding, you are talking of different logical gateways that are bundled together into a single *box*. Each such logical gateway must register with the gatekeeper. The terminalAlias could be used to identify the logical GW and the callSignalAddress would specify the contact point. Hence, you would have to send 2 RRQs. Also, the endpointIdentifier is generated by the GK and returned in the RCF and so cannot be specified by the GW at time of registration. Any comments? Regards, Gaurav Makkar I have a question on RRQ registration in H.323V2. Let us say I have a gateway that supports area codes 408, 409. I want my gatekeeper to route calls to area codes 408 and 409 to my local TCP ports 2000 and 3000 respectively. How should I construct my RRQ message? Shall I send two RRQs with same endpoint identifier (because I have only one gateway) with tuples <408, 2000> and <409, 3000>. <x,y> means: x: carried in SupportedProtocols.prefix y: carried in callSignallingAddress of RRQ message Is my understanding correct? -Chris Rob _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

1 0

H.323 Annex F - SET questions
by Gunnar Hellstrom 18 Apr '99

18 Apr '99

Dear Jörg and all, When preparing H.323 Annex G - Text SET, I studied the base SET document; Annex F as in TD11 from Monterey, and came across a few points raising questions. I hope I can get clarifications on these points. 1. In section 6. it is said that for the Audio SET, "Data-capability is optional - possibly support for facsimile transmission." If this section is as is stated - for the Audio SET, then "No Data Capability" should be specified. And I think that is a good structure - Then I can write that the Text SET has Media Capabilities as for the Audio Set but with Data Capability for text conversation according to T.140. 2. In section 7.3.2. the explanations of the abbreviations M O I N, refers to Audio SET devices. The rest of this section looks general, why I suggest that the word "Audio" should be deleted in these four explanations. 3. Media Exchange. Insert TCP among the allowed protocols, so that data transmission SET:s can be allowed. 4. In section 7.6.1, the last sentence is "The OpenLogicalChannel structure should offer the same audio encodings that were in use prior to call rerouting." Looking back to the discussions in the list the last few weeks, I find that this sentence is misleading and can safely be deleted. The result should be that coding changes and media additions shall be allowed to occur after the rerouting. 5. In section 7.6.2, change the word "resume" to "start" in the last sentence. Since media additions may occur, media streams may be new after the rerouting. 6. Terminal type for SET types. I want to discuss the "Endpoint Type" specification in H.225.0 as described among the additions to implementor´s guides, titled "Addition of a terminal type for Simple Endpoint Types"and in Annex F, section 7.1. Bit 0 =1 if the device is an Audio SET. My question is: Should this specifier rather mark available functions than complete SETs? Then, bit 0 could indicate "the device has Audio functions" and , bit 2 could indicate "the device has Text conversation features." A Text SET should set them booth. This would allow for a combined text - fax - audio -SET. Regards Gunnar Hellström ------------------------------------------------ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: www.omnitor.se ------------------------------------------------

1 0

Re: H.245 vs. SDP
by Mike Buckley 16 Apr '99

16 Apr '99

Thanks for the clarification Tom. This is exactly what I meant. I agree that caps exchange will generally be a registration process. However I would pose a question whether there might not be a need for a caps exchange after registration to identify resources temporarily unavailable (traffic loading etc) or unavailable in a specific set of circumstances. Also is there a role for a caps exchange to change parameters during a session? This might be particularly important in multimedia situations. Mike ____________________ Begin Original Message ___________________________ Date: Fri Apr 16 09:24:57 -0400 1999 From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor) Subject: H.245 vs. SDP To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 4210 I would like to clarify the issue of H.245 vs. SDP. First off, what we are talking about here is NOT capability negotiation. The latter is handled by signalling between MGCs. A given MGC obtains the information needed to support its end of the negotiation through use of the Audit command. Megaco/H.GCP has the action to ensure that responses to Audit commands convey the necessary information. That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel (OLC) and OLC Ack structures. I think what Mike is saying is that there are two issues in this discussion: content, and ordering of that content. On content, I think we can get general agreement that if the H.245 OLC can request something, the Media Gateway control protocol should be able to propagate that request to the MG. Thus there is no argument in general over content, leaving aside housekeeping items like the H.245 logical channel number which may be irrelevant to the MG. The contentious point is therefore one of how the individual parameters should be ordered. What I suggest is that we see through example how they are used, then decide on ordering. We will probably find that there is a dependency here on how we use contexts to represent multimedia. A single-medium context corresponds to one (bidirectional) or two unidirectional H.245 logical channels. There is an issue here: how does the MGC correlate the second logical channel with the first one? Do we end up with a separate context for each H.245 logical channel? A multimedia context corresponds to a number of logical channels, but the correlation rules are simpler: all logical channels associated with the same call (H.323 definition) are grouped together. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 15, 1999 4:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > I agree with Mike in using H.245 between MGC and MG. SDP is essentially > used > for advertising loosely coupled sessions, so it does not have the > functionality necessary to be considered in H.GCP. Also, H.GCP must re-use > H.323 components whenever possible. > > vineet > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] > Sent: Wednesday, April 14, 1999 7:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > > Bryan, > > I don't know whether this is the right place to comment on the Draft. I > have also > copied some of these comments to the megaco list. > > I would like to see the use of SDP between the MGC and MG added to the > issues list. My understanding is that the symantics and syntax of SDP are > different from H.245OLC. Use of SDP in H.gcp will therefore involve a > reordering > of the information sent in H.245 between endpoints. This will add > transcoding > complexity and latency. In addition, all the features of H.245 I believe > cannot be > presently supported in SDP. For maximum efficiency and flexibility > therefore > I think the mechanism used to convey capabilities should mirror the > semantics > and syntax of H.245OLC. I don't believe there is any extra overhead in > adopting this approach over SDP. The coding used may be different from > PER > or > BER. > > I think this also fits in with the list of H.gcp requirements where it is > stated that > all the features of H.245 should be supported. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Tue Apr 13 08:57:37 -0400 1999 > From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) > Subject: H.GCP draft uploaded > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 367 > > Mr. Okubo, > Please find a version of HGCP.doc and HGCP.zip that I have uploaded into > the > ptel incoming site. These are drafts of the contribution I am preparing > for > Santiago. > > Best Regards, > Bryan Hill > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > bhill(a)videoserver.com <mailto:bhill@videoserver.com>

2 2

Re: H.245 vs. SDP
by Gur Kimchi 16 Apr '99

16 Apr '99

Actually, we can look at this from another angle. For H.GCP, the main protocol suite to interwork with (and work within) is H.323 - not SIP. There is a strong parallel between H.245 and H.GCP as it currently stands, with the exception of the use of SDP. Any effort to ignore H.323 interworking in this group will have the same effect as ignoring SIP in MMUSIC ;-) The following are simple to map between ISUP-over-IP/GCP and H.225/H.245 systems: Function H.245 H.GCP (Megaco Design Group Draft) ------------------------------------------------------------------------ Capabilities Exchange CapsExchange Audit Connection Creation OpenLogicalChannel Add Connection Modification ReplacmentFor OLC Modify Connection Deletion CloseLogicalChannel Subtract Connection Moving ReplacmentFor OLC Move So it is simple to have a Gateway between the two models. We can extrapolate further as we could actually look at H.GCP as doing the same things as H.245 - think of it as a text based alternative to H.245, so we can imagine the following models: current SIP --> future SIP | current 323 --> future 323 +--------------------+---------------+---------------+--------------- +---------------+ | service signalling | SIP | SIP | Annex G | Annex G | +--------------------+---------------+---------------+ ---------------+---------------+ | call signalling | SIP | SIP | H.225/Q.931 | H.225/Q.931 | +--------------------+---------------+---------------+ ---------------+---------------+ | connection control | none | GCP | H.245 | GCP | +--------------------+---------------+---------------+ ---------------+---------------+ | media transmission | RTP/RTCP | RTP/RTCP | RTP/RTCP | RTP/RTCP | +--------------------+---------------+---------------+ ---------------+---------------+ Further, H.GCP after all is just a method to decompose gateways, nothing else, so it will be used to construct logical gatways. These gatways MUST interoperate with any other H.323 host - and they cannot when using SDP. +--------------------+ +--------------------+ | MGC |<---245-->| | +--------------------+ | | | | | GCP | Simple Gateway | | | | +--------------------+ | | | MG | | | +--------------------+ +--------------------+ SDP is just not expressive enough for the products many of us are trying to build. Like or not, the mutex and simultaneous capabilities descriptors in H.245 are there for a purpose - as many systems have limitations that need to be expressed. having to design MG hardware to cope with SDP limitations is not the correct answer. A possible solution is create an ASN.1 Text Encoding Rules (TER? I seem to remember some old work that called this NER) for H.245 that will create tables of structure.name=value pairs. This will allow people to build systems with practically no ASN compilers, and allow simple over-the-wire debugging. This H.245 encoding in TER should be used in H.GCP instead of SDP. Bottom line? We can build SDP to H.245 translators, but there is no way to build full H.245 to SDP translators - SDP is just too limited. I hope that at the end of this difficult, and sometimes painful exercise of decomposing the gateway we dont find ourselves designing a less-capabile gateway then what we had before... I am afraid MMUSIC will come to the same conclusion at some point, and will have to invent a new SDP that allows multi-dimensional (maybe with AND/OR/NOT qualifiers) - but this is clearly beyond the scope, and schedule, of the H.GCP work. - gur ______________________________________________________________________ Gur Kimchi Corporate Director, Advance Technologies, Research and Standards VocalTec Communications Ltd web: http://www.vocaltec.com -------- On 04/16/99 03:50 PM GMT Mike Buckley <mikebuckley(a)ATTMAIL.COM> wrote: Thanks for the clarification Tom. This is exactly what I meant. I agree that caps exchange will generally be a registration process. However I would pose a question whether there might not be a need for a caps exchange after registration to identify resources temporarily unavailable (traffic loading etc) or unavailable in a specific set of circumstances. Also is there a role for a caps exchange to change parameters during a session? This might be particularly important in multimedia situations. Mike ____________________ Begin Original Message ___________________________ Date: Fri Apr 16 09:24:57 -0400 1999 From: internet!NORTELNETWORKS.COM!taylor (Tom-PT Taylor) Subject: H.245 vs. SDP To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 4210 I would like to clarify the issue of H.245 vs. SDP. First off, what we are talking about here is NOT capability negotiation. The latter is handled by signalling between MGCs. A given MGC obtains the information needed to support its end of the negotiation through use of the Audit command. Megaco/H.GCP has the action to ensure that responses to Audit commands convey the necessary information. That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel (OLC) and OLC Ack structures. I think what Mike is saying is that there are two issues in this discussion: content, and ordering of that content. On content, I think we can get general agreement that if the H.245 OLC can request something, the Media Gateway control protocol should be able to propagate that request to the MG. Thus there is no argument in general over content, leaving aside housekeeping items like the H.245 logical channel number which may be irrelevant to the MG. The contentious point is therefore one of how the individual parameters should be ordered. What I suggest is that we see through example how they are used, then decide on ordering. We will probably find that there is a dependency here on how we use contexts to represent multimedia. A single-medium context corresponds to one (bidirectional) or two unidirectional H.245 logical channels. There is an issue here: how does the MGC correlate the second logical channel with the first one? Do we end up with a separate context for each H.245 logical channel? A multimedia context corresponds to a number of logical channels, but the correlation rules are simpler: all logical channels associated with the same call (H.323 definition) are grouped together. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 15, 1999 4:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > I agree with Mike in using H.245 between MGC and MG. SDP is essentially > used > for advertising loosely coupled sessions, so it does not have the > functionality necessary to be considered in H.GCP. Also, H.GCP must re-use > H.323 components whenever possible. > > vineet > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] > Sent: Wednesday, April 14, 1999 7:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > > Bryan, > > I don't know whether this is the right place to comment on the Draft. I > have also > copied some of these comments to the megaco list. > > I would like to see the use of SDP between the MGC and MG added to the > issues list. My understanding is that the symantics and syntax of SDP are > different from H.245OLC. Use of SDP in H.gcp will therefore involve a > reordering > of the information sent in H.245 between endpoints. This will add > transcoding > complexity and latency. In addition, all the features of H.245 I believe > cannot be > presently supported in SDP. For maximum efficiency and flexibility > therefore > I think the mechanism used to convey capabilities should mirror the > semantics > and syntax of H.245OLC. I don't believe there is any extra overhead in > adopting this approach over SDP. The coding used may be different from > PER > or > BER. > > I think this also fits in with the list of H.gcp requirements where it is > stated that > all the features of H.245 should be supported. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Tue Apr 13 08:57:37 -0400 1999 > From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) > Subject: H.GCP draft uploaded > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 367 > > Mr. Okubo, > Please find a version of HGCP.doc and HGCP.zip that I have uploaded into > the > ptel incoming site. These are drafts of the contribution I am preparing > for > Santiago. > > Best Regards, > Bryan Hill > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0

Re: redundant, conflicting multirate indications
by Paul Long 16 Apr '99

16 Apr '99

Bob, But that's not what H.225.0 says. 7.2.2.1/H.225.0v2: Extension bit for octet #4 (bit 8) - Shall be set to '0' if the information transfer rate is set to 'multirate'; shall be set to '1' otherwise. So it indicates whether the octet-4 rate field is set to multirate, which in turn implies that octet 4.1 is present, according to Q.931. It does not directly indicate whether octet 4.1 is present, regardless of what Q.931 says. That's why, IMO, this normative text in 7.2.2.1 is needlessly redundant and error prone, as I found out at the interop. Therefore, the only correct encodings are: extension bit: 0, rate: multirate, octet 4.1 present and extension bit: 1, rate: not multirate, octet 4.1 not present In particular, the encoding which I encountered at the interop, extension bit: 1, rate: multirate, octet 4.1 present is definitely not correct. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Friday, April 16, 1999 7:26 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: redundant, conflicting multirate indications Paul, There appears to be a misunderstanding as to the meaning of "extension bit." For all of the Q.931 coded elements, the extension bit set to zero indicates that the octet is extended. If set to one, the octet is not extended. Section 7.2.2.2/H225.0v2 states that the extension bit of octet 4 is set to zero for when multi-rate is present. This only means that the multirate octet (4.1) is present. Or as an inverse, is the bit is set to one, then octet 4.1 may not be present. This does not mean, in itself, that multirate is not present. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Friday, April 16, 1999 12:03 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: redundant, conflicting multirate indications Why does 7.2.2.1/H.225.0v2 say that the extension bit of octet 4 in bearer capabilities indicates whether the information-transfer-rate field is set to multirate? Isn't this redundant? It caused me a problem at the last interop, because someone sent a Setup message with the extension bit indicating that it _was not_ multirate and the rate field indicating that it _was_ multirate. My EP looked at the extension bit instead of the rate field--they should agree, shouldn't they?--and assumed that octet 4.1 was not present when in fact it was. This caused a decode error decoding what it thought was octet 5 but was in fact octet 4.1. I have changed the code so that it now looks at the rate field but was just wondering if anyone had a better understanding of this situation. Paul Long Smith Micro Software, Inc.

1 0

H.245 vs. SDP
by Tom-PT Taylor 16 Apr '99

16 Apr '99

I would like to clarify the issue of H.245 vs. SDP. First off, what we are talking about here is NOT capability negotiation. The latter is handled by signalling between MGCs. A given MGC obtains the information needed to support its end of the negotiation through use of the Audit command. Megaco/H.GCP has the action to ensure that responses to Audit commands convey the necessary information. That said, the question becomes one of SDP vs. the H.245 OpenLogicalChannel (OLC) and OLC Ack structures. I think what Mike is saying is that there are two issues in this discussion: content, and ordering of that content. On content, I think we can get general agreement that if the H.245 OLC can request something, the Media Gateway control protocol should be able to propagate that request to the MG. Thus there is no argument in general over content, leaving aside housekeeping items like the H.245 logical channel number which may be irrelevant to the MG. The contentious point is therefore one of how the individual parameters should be ordered. What I suggest is that we see through example how they are used, then decide on ordering. We will probably find that there is a dependency here on how we use contexts to represent multimedia. A single-medium context corresponds to one (bidirectional) or two unidirectional H.245 logical channels. There is an issue here: how does the MGC correlate the second logical channel with the first one? Do we end up with a separate context for each H.245 logical channel? A multimedia context corresponds to a number of logical channels, but the correlation rules are simpler: all logical channels associated with the same call (H.323 definition) are grouped together. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@INTEL.COM] > Sent: Thursday, April 15, 1999 4:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > I agree with Mike in using H.245 between MGC and MG. SDP is essentially > used > for advertising loosely coupled sessions, so it does not have the > functionality necessary to be considered in H.GCP. Also, H.GCP must re-use > H.323 components whenever possible. > > vineet > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@ATTMAIL.COM] > Sent: Wednesday, April 14, 1999 7:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.GCP draft uploaded > > > Bryan, > > I don't know whether this is the right place to comment on the Draft. I > have also > copied some of these comments to the megaco list. > > I would like to see the use of SDP between the MGC and MG added to the > issues list. My understanding is that the symantics and syntax of SDP are > different from H.245OLC. Use of SDP in H.gcp will therefore involve a > reordering > of the information sent in H.245 between endpoints. This will add > transcoding > complexity and latency. In addition, all the features of H.245 I believe > cannot be > presently supported in SDP. For maximum efficiency and flexibility > therefore > I think the mechanism used to convey capabilities should mirror the > semantics > and syntax of H.245OLC. I don't believe there is any extra overhead in > adopting this approach over SDP. The coding used may be different from > PER > or > BER. > > I think this also fits in with the list of H.gcp requirements where it is > stated that > all the features of H.245 should be supported. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Tue Apr 13 08:57:37 -0400 1999 > From: internet!VIDEOSERVER.COM!bhill (Bryan Hill) > Subject: H.GCP draft uploaded > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 367 > > Mr. Okubo, > Please find a version of HGCP.doc and HGCP.zip that I have uploaded into > the > ptel incoming site. These are drafts of the contribution I am preparing > for > Santiago. > > Best Regards, > Bryan Hill > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0