- 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