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

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