- sg16-avd - lists.packetizer.com

Re: Annex G
by Roy, Radhika R, ALTEC 08 Sep '98

08 Sep '98

Chris: I am glad that you have asked for some clarifications. The whole point is that we are considering GK-to-GK communications in multiple GK environment. Let there be any number of GKs to participate for GK-to-GK communications depending on specific configurations. It can be as simple as single GK (single zone) or multiple GKs consisting of multiple zones and multiple (administrative)-domains. Before going to details, I guess that most of the questions that you have asked have been clarified by me on September 1, 1998, in response to Douglas Clowes' questions. AT&T's contribution is considering the RAS signaling messages only (NOT call setup, media negotiation, or data packets). In response to Mr. Clowes' questions (please see the details in the email sent on Sept 1), it has been explained that, in H.323, a GK's knowledge is limited to zone-level only (no "notion" of network-level path as in the case of IP, ATM, FR, or other networks). The proposal does not mandate what path will be followed by the call setup, media negotiation, or data packets associated with the call. Yes, AT&T's contribution, like other proposals, also separates between the RAS signaling stage and the call signaling stage. So, the call signaling is free to take any path as appropriate. In addition to AT&T's contribution, Nokia's APC 1382 (S. Sengodan, Nokia, "On the Use of Multicast Scope for Gatekeeper Discovery," APC 1382, Q.11-14/16 Rapporteur Meeting, Cannes, France, June 8-11, 1998) will also explain why additional fields are needed in signaling messages. The extra fields are primarily needed to facilitate routing of the messages between the GKs in multiple GK environment. I like to point out that a service provider, in general, can create a variety of back-end services through intercepting signaling messages from the appropriate entities (e.g., GKs) situated in the optimal locations as needed if the signaling messages are allowed to pass through those entities. I hope that the above explanations will clarify the things. Regards, Radhika > ---------- > From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, September 07, 1998 12:29 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > Radhika, > > In my view there is a fundamental difference between the scheme that you > are proposing and the other contributions on inter-administrative-domain > communication: > > Your proposal continues to expect all RAS, call setup, media negotiation > and, (for all I know - it's not clear to me in your proposal), data > packets > associated with a call to follow a path through intermediate entities that > are on the path that address resolution messages happened to take. > > All the other proposals I have seen preserve a separation between the > resolution phase (where messages may indeed need to be sent to a number > of different places), and the call signalling stage which follows a more > direct route between endpoints. > > Your proposal requires the addition of extra fields to almost all RAS > messages, and will generate a significant amount of extra call signalling > traffic on the global network. > > I still fail to understand what the technical (or business) advantages of > this extra propogation of messages are. My impression was that the vast > majority of the people on last Friday's conference call share my > scepticism. > > Regards, > Chris > > -- > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > Phone:+44 1753 661359 email: cpurvis(a)madge.com >

1 0

H.225.0 Annex G Conference Call
by Glen Freundlich 08 Sep '98

08 Sep '98

There will be another conference call to discuss H.225.0 Annex G: date: 9 September 1998 (Wednesday) time: 9:00am Mountain Time (8:00 Pacific, 11:00 Eastern, etc) bridge number: +1 212 271 4784 code: 4699660 duration: 1 hour Tentative agenda (time permitting): - review of Andrew Draper's proposal - review of Pete Cordell's proposal? -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: Annex G
by Santo Wiryaman 08 Sep '98

08 Sep '98

Radhika, Since your proposal for passing all RAS messages differ radically from how an inter-zone call works in H.323, today, it would be helpful for you to describe in detail how call signaling messages flow between, say, Endpoint1 in Zone1 to Endpoint4 in Zone4, which traverse zones 2 and 3. Up to now you have strongly advocated that all RAS messages be passed from one GK to another without giving a specific example on how the following messages would be propagated: 1. RRQ/RCF/RRJ 2. ARQ/ACF/ARJ 3. LRQ/LCF/LRJ 4. IRQ/IRR 5. BRQ/BCF/BRJ 6. DRQ/DCF/DRJ 7. URQ/UCF/URJ Therefore an example of an inter-zone call such as proposed above from you would be helpful for us to see why you are proposing what you are proposing. Thanks. -santo ---------- From: Chris Purvis WVdevmt-WS [SMTP:cpurvis@MADGE.COM] <mailto:[SMTP:cpurvis@MADGE.COM]> Sent: Monday, September 07, 1998 12:30 PM To: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> Subject: Re: Annex G Radhika, In my view there is a fundamental difference between the scheme that you are proposing and the other contributions on inter-administrative-domain communication: Your proposal continues to expect all RAS, call setup, media negotiation and, (for all I know - it's not clear to me in your proposal), data packets associated with a call to follow a path through intermediate entities that are on the path that address resolution messages happened to take. All the other proposals I have seen preserve a separation between the resolution phase (where messages may indeed need to be sent to a number of different places), and the call signalling stage which follows a more direct route between endpoints. Your proposal requires the addition of extra fields to almost all RAS messages, and will generate a significant amount of extra call signalling traffic on the global network. I still fail to understand what the technical (or business) advantages of this extra propogation of messages are. My impression was that the vast majority of the people on last Friday's conference call share my scepticism. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com <mailto:cpurvis@madge.com>

1 0

Re: Annex G
by Chris Purvis WVdevmt-WS 08 Sep '98

08 Sep '98

Radhika, >The "abstraction of routing" between the GKs is an option. Whether the >"abstraction of this routing option" to be used through a chain of zones or >not is left up to the implementation schemes. >If one does not feel the advantage of this option, then one may not use it. >I hope that this will clarify the things. In that case I for one don't understand your proposal (nh_gkx2.doc). As I understood it, it works like this: A source endpoint sends an ARQ to its gatekeeper (GKA) to try to make a call. GKA sends LRQs to various "friends" (GKB1, GKB2, GKB3, say), which do the same in turn until they find the destination alias (which is for instance known by GKD111, discovered via GKB1 and GKC11). Now GKA needs to send an ARQ somewhere (if I understand your scheme correctly). The only place it knows that it can send an ARQ to is GKB1, as the address returned in the LCF is a call signalling address rather than a RAS address, and may refer to the destination endpoint itself. Hence the ARQ must, as I understand your scheme, be routed via GKB1, GKC11 and GKD111 and not direct from GKA to GKD111. Yet you say the "chain of zones" is an option. Therefore I misunderstand your proposal. >PS When we see references in H.323 that a message is to be sent from one GK >to another GK, it implies that the message has to be "routed" from one GK to >another. (In another scenario, when in H.323 it is assumed that messages are >to be sent between the GKs via "multicasting", it is also a kind of >"routing" through a tree architecture that has a "chain of branches" where >GKs are located.) You appear to confuse IP (or equivalent) routing with routing messages via a number of H.323 entities. In order to route messages via a number of H.323 entities (as you suggest) the IP routing phase needs to be done multiple times. Worse, the message needs to be processed multiple times on its travels, whereas if we leave IP to do a job it is good at the message only needs to be processed at relevant places. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Re: Annex G
by Chris Purvis WVdevmt-WS 07 Sep '98

07 Sep '98

Radhika, In my view there is a fundamental difference between the scheme that you are proposing and the other contributions on inter-administrative-domain communication: Your proposal continues to expect all RAS, call setup, media negotiation and, (for all I know - it's not clear to me in your proposal), data packets associated with a call to follow a path through intermediate entities that are on the path that address resolution messages happened to take. All the other proposals I have seen preserve a separation between the resolution phase (where messages may indeed need to be sent to a number of different places), and the call signalling stage which follows a more direct route between endpoints. Your proposal requires the addition of extra fields to almost all RAS messages, and will generate a significant amount of extra call signalling traffic on the global network. I still fail to understand what the technical (or business) advantages of this extra propogation of messages are. My impression was that the vast majority of the people on last Friday's conference call share my scepticism. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Re: Annex G
by Roy, Radhika R, ALTEC 07 Sep '98

07 Sep '98

Dear Mr. Clowes: The "abstraction of routing" between the GKs is an option. Whether the "abstraction of this routing option" to be used through a chain of zones or not is left up to the implementation schemes. If one does not feel the advantage of this option, then one may not use it. I hope that this will clarify the things. Regards, Radhika R. Roy PS When we see references in H.323 that a message is to be sent from one GK to another GK, it implies that the message has to be "routed" from one GK to another. (In another scenario, when in H.323 it is assumed that messages are to be sent between the GKs via "multicasting", it is also a kind of "routing" through a tree architecture that has a "chain of branches" where GKs are located.) > ---------- > From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Sunday, September 06, 1998 6:21 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > At 19:38 05/09/98 -0400, you wrote: > > >3.2 Routing > > > >Like inter-zone, the communications between the domains also need > >the abstraction of routing to facilitate inter-GK communications > >since the inter-domain communication is nothing but the communications > >through a chain of zones. > > It would appear to me that "the communications through a chain of zones" > is > prone to introducing problems. > > Douglas > > >Hi Editor/SG16 Members: > > > >A proposal on Annex G is enclosed. Your comments will be highly > appreciated. > > > > <<m_G.doc>> > >Sincerely, > > > >Radhika R. Roy > >AT&T > >Tel: + 1 732 949 8657 > >Email: rrroy(a)att.com > > > >Attachment Converted: "c:\eudora\attach\m_G.doc" > > >

1 0

TD indicating typographical errors in COM 16-68-E
by Sakae OKUBO 07 Sep '98

07 Sep '98

Dear Q.12-14 experts, The following TD has been placed at PictureTel ftp site: ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/TDb_for_16-68.zip This points out some printing errors contained in COM 16-68-E Draft H.310 V2 for Decision. 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

Q14 status report and index file
by Sakae OKUBO 06 Sep '98

06 Sep '98

Dear Mr. Thom and other Q.12-14/16 experts, G Thom> I have uploaded q14stat.doc to the incoming directory. This has been zipped and moved to /9809_Gen/Input_TD directory. Please also be advised that I have updated /9809_Gen/9809_Gen.html (index of the documents). 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: No root node
by Santo Wiryaman 04 Sep '98

04 Sep '98

Pete, Thanks. I like that. -santo ---------- From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: Friday, September 04, 1998 2:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: No root node Santo, In general, to a first order approximation, I would expect a fully meshed arrangement of 'country' border elements. However I would see the fine detail of the structure being down to who people have arrangements for resolving addresses with. For example, BT might go to AT+T to resolve all North and South American numbers, and AT+T might come to BT for all European numbers. I could also see that opportunistic companies could set up global clearing houses that would handle address translation for outfits that haven't been able to establish their own knowledge of all the borders such as ISPs, or corporates. This would look like a root node to the people that used it, but it would be used purely as a commercial expedient and not mandated by the way the standard works. On the issue of France moving its entry point to Lyon for the week, I think we have to allow France to have more than one entry point. After all, Paris could all of a sudden slide into the Seine, and the press, if nobody else, would still want to make calls into France to find out what's going on. By having multiple entry points, the French can turn off their Paris BE for a while and switch on their Lyon one, and if the data didn't propagate around the system for a while it wouldn't really matter too much. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] >Sent: 04 September 1998 17:29 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: No root node > >Hi All, > >I am not at all opposed to eliminating the root domain. A couple of >questions for Pete and the group: > >1. Are you suggesting that at the national level the border elements >are fully meshed together, or alternatively arranged in a big ring as >Radhika is suggesting? >2. If so, when a new country "goes on-line" endpoints in the new >country would not be reachable until the information is propagated in >this fully meshed database (or inserted in the ring). >3. Same if, say France, had to switch its National H.323 Border Element >from Paris to Lyons for one week. >4. Are you open to the idea of a global clearing house to resolve the >address of border elements of countries which are currently not listed >in the fully-meshed database. > >Regards, > >Santo Wiryaman >Videoserver > > >---------- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, September 03, 1998 10:20 AM >To: ITU-SG16(a)mailbag.cps.INTEL.COM >Subject: No root node > >Dear All, > >Apologies for not being on the last call, but... > >I feel one really important issue with Santo's contribution is that we >must remove the root domain. Having such a concept would give >politicians and lawyers far too much work!!! I believe the notes that >I >put forward would allow the root node to be removed, and based on >comments I heard from Jim, I believe what he is proposing would allow >this too. > >Regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= >

1 0

Re: No root node
by Pete Cordell 04 Sep '98

04 Sep '98

Santo, In general, to a first order approximation, I would expect a fully meshed arrangement of 'country' border elements. However I would see the fine detail of the structure being down to who people have arrangements for resolving addresses with. For example, BT might go to AT+T to resolve all North and South American numbers, and AT+T might come to BT for all European numbers. I could also see that opportunistic companies could set up global clearing houses that would handle address translation for outfits that haven't been able to establish their own knowledge of all the borders such as ISPs, or corporates. This would look like a root node to the people that used it, but it would be used purely as a commercial expedient and not mandated by the way the standard works. On the issue of France moving its entry point to Lyon for the week, I think we have to allow France to have more than one entry point. After all, Paris could all of a sudden slide into the Seine, and the press, if nobody else, would still want to make calls into France to find out what's going on. By having multiple entry points, the French can turn off their Paris BE for a while and switch on their Lyon one, and if the data didn't propagate around the system for a while it wouldn't really matter too much. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] >Sent: 04 September 1998 17:29 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: No root node > >Hi All, > >I am not at all opposed to eliminating the root domain. A couple of >questions for Pete and the group: > >1. Are you suggesting that at the national level the border elements >are fully meshed together, or alternatively arranged in a big ring as >Radhika is suggesting? >2. If so, when a new country "goes on-line" endpoints in the new >country would not be reachable until the information is propagated in >this fully meshed database (or inserted in the ring). >3. Same if, say France, had to switch its National H.323 Border Element >from Paris to Lyons for one week. >4. Are you open to the idea of a global clearing house to resolve the >address of border elements of countries which are currently not listed >in the fully-meshed database. > >Regards, > >Santo Wiryaman >Videoserver > > >---------- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, September 03, 1998 10:20 AM >To: ITU-SG16(a)mailbag.cps.INTEL.COM >Subject: No root node > >Dear All, > >Apologies for not being on the last call, but... > >I feel one really important issue with Santo's contribution is that we >must remove the root domain. Having such a concept would give >politicians and lawyers far too much work!!! I believe the notes that >I >put forward would allow the root node to be removed, and based on >comments I heard from Jim, I believe what he is proposing would allow >this too. > >Regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= >

1 0

Re: No root node
by Santo Wiryaman 04 Sep '98

04 Sep '98

Hi All, I am not at all opposed to eliminating the root domain. A couple of questions for Pete and the group: 1. Are you suggesting that at the national level the border elements are fully meshed together, or alternatively arranged in a big ring as Radhika is suggesting? 2. If so, when a new country "goes on-line" endpoints in the new country would not be reachable until the information is propagated in this fully meshed database (or inserted in the ring). 3. Same if, say France, had to switch its National H.323 Border Element from Paris to Lyons for one week. 4. Are you open to the idea of a global clearing house to resolve the address of border elements of countries which are currently not listed in the fully-meshed database. Regards, Santo Wiryaman Videoserver ---------- From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: Thursday, September 03, 1998 10:20 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: No root node Dear All, Apologies for not being on the last call, but... I feel one really important issue with Santo's contribution is that we must remove the root domain. Having such a concept would give politicians and lawyers far too much work!!! I believe the notes that I put forward would allow the root node to be removed, and based on comments I heard from Jim, I believe what he is proposing would allow this too. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

latest RDC docs posted to ftp site
by Charles M Grandgent 04 Sep '98

04 Sep '98

Andy's latest RDC doc revisions are now posted to the IMTC ftp site. The files are: TrdcRevC.zip and VrdcRevB.zip and are at: ftp://ftp.imtc-files.org/imtc-site/T120-top/geneva98-2/ Chuck Forwarded message:

1 0

RDC documents - version submitted to Geneva
by Andy Woollett 04 Sep '98

04 Sep '98

------ =_NextPart_001_01BDD801.3DDD4480 Content-Type: text/plain Hi Chuck, I have another version of RDC. Could you please place these documents into the Geneva98-2 directory at the IMTC site directory and then forward the following message to the Q3 reflector. Thanks Andy Woollett --------------------------------------------- All: The following draft documents have been placed in the Geneva98-2 directory at the IMTC site. /pub/imtc-site/T.120-top/Geneva98-2/VRDCrevB.zip /pub/imtc-site/T.120-top/Geneva98-2/TRDCrevC.zip VRDVrevB.zip contains VRDCrevB.doc - submitted to Geneva as a delayed contribution VRDCrevB_CB.doc - as above but with revision marks TRDVrevC.zip contains TRDCrevC.doc - submitted to Geneva as a delayed contribution TRDCrevC_CB.doc - as above but with revision marks Main Changes * The detailed description of the device list how been moved from T.RDC into V.RDC. The ASN.1 describing the device list has moved into V.RDC. * An optional flag has been added to the RDC-Device-Control primitive to allow the User Application to send the request via a low latency data channel. * Explicit references to H.RDC have been removed since it will not be determined until April 1999. * The optional Stream Identifier flag in the RDC-Source-Select request primitive has been made mandatory. * The ASN.1 in V.RDC has been completed. * The Pan View, Tilt View and Zoom Magnification attributes must be supported if the Pan Position, Tilt Position and Zoom Position attributes are supported. * Added a section describing the allocation of camera device IDs for interoperability with H.281. Andy Woollett ImageCom Limited UK -- ---------------------------------------------------------- Chuck Grandgent, Nexus Systems Inc., Salem, NH 603-894-6110 x1017 chuck(a)nexussystems.com chuck(a)k1om.com http://www.nexussystems.com http://www.k1om.com *** "PCs - Automobiles for the mind." *** ----------------------------------------------------------

1 0

Delayed Contributions and Input TDs
by Sakae OKUBO 04 Sep '98

04 Sep '98

Dear Q.12-14/16 experts, The following documents have been moved to /Delayed or /Input_TD directories: Chimura> ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/H323DTCP_rev.rtf Chimura> ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/H323anxD.rtf Chimura> ftp://standard.pictel.com/avc-site/9809_Gen/Delayed/H450Comm.rtf Kajos> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/HMMIB01.ZIP Okubo> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/H220AM6.zip Okubo> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/Interim.zip Okubo> ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/Q12status.zip 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

H.225 Annex G
by Glen Freundlich 03 Sep '98

03 Sep '98

Has anybody looked at any of the iptel work to see if it's applicable to H.225.0 Annex G? I've not yet reviewed any of the material so can't comment. There is a framework document and some others to be found at http://www.bell-labs.com/mailing-lists/iptel. Additionally, there are some viewgraphs at http://www.cs.columbia.edu/~jdrosen/papers/ietf_iptel_aug98.ppt. Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

3 2

Re: H.225 Annex G
by Scott Bradner 03 Sep '98

03 Sep '98

Douglas reports: One is for IP routers to route e.164 addresses in the same way as they do IP packets. In this scheme, gateway advertisements would occur via a modified IP routing protocol (BGP I think it was). yes, this idea was mentioned but the person who presented it called it "a bad idea" most people who run Internet service providers or who deal with routing protocols fully agree with that conclusion as Douglas noted the state of much of the effort is a "still-debated problem definition" Scott (Area co-director for Transport in the IETF, the area in which this work is being debated)

1 0

RAI time-out and retry count
by Kaynam Hedayat 03 Sep '98

03 Sep '98

Hi, Looking over H.225.0 we have noticed that the recommended time-out and retry count values for RAI (ResourceAvailabilityIndication) command are not specified in the table of section 7.19. We would like to recommend a time-out value of 3 seconds and retry count of 2 (same as RRQ). Thank you. Kaynam Hedayat PictureTel Corporation

1 0

Re: Q. about master/slave determination in H.245
by Jim Toga 03 Sep '98

03 Sep '98

My comments below.... Regards, jimt. At 12:13 PM 8/21/98 +0800, you wrote: >Hi.. > I have some questions about master/slave determination in H.245. >Perhpas these questions are stupid... but could you please kindly give me >some help? > > With H.245, we need to do master/slave determination to resolve >conflicts between two endpoints which can be the MC in a conference. > >(1) If there is no MC is active and all entities are of different types, >the priority to win the master/slave determination is MCU > Gatkeeper > >Gateway > terminal. THis means. e.g., with Gatekeeper and terminal, >Gatekeeper always wins the determination? then why bothering to >set "statusDeterminationNumber" to be a random no. in that certain range? > >or only when those entities are all in the same type, then such setting >just makes sense? i.e., "terminalType" overrules >"statusDeterminationNumber" ?? Seems like a reasonable optimization.....it has been discussed before but never documented. > >(2) An MC that is already acting as an MC shall always remian the active >MC. However, assume that there are only terminals participating in a >conference, what if a terminal that won the determination already >decides to leave the conference at some time during the call? Should we >need to perform such master/slave determination again?, or the terminal >can assign the other to be an active MC?, or the terminal by no means can >not leave the conference in the middle of the call? > If more than two terminals are in the conference then there must be an MC envolved. If the MC leaves the conference (note that this is not the same as the colocated Terminal leaving...) then the conference must end. The H.245 connections all go to the MC.... >Please advise... thanks a lot.. > >Best regards, > >Wanjiun Liao > ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

No root node
by Pete Cordell 03 Sep '98

03 Sep '98

Dear All, Apologies for not being on the last call, but... I feel one really important issue with Santo's contribution is that we must remove the root domain. Having such a concept would give politicians and lawyers far too much work!!! I believe the notes that I put forward would allow the root node to be removed, and based on comments I heard from Jim, I believe what he is proposing would allow this too. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: H.323 Addresses
by Pete Cordell 03 Sep '98

03 Sep '98

Douglas, Although billing for IP based calls is very likely to be very different from that used in the PSTN world, (and I would be prepared to bet that it was distance independent!!!), I think it is far too early to enshrine such a concept into the work we are doing. For example, an operator, possibly a start up, may want to connect a big fat intra-net style IP pipe out the back of there new local POTS point of presence and use that to inter-connect with the rest of their network. They would want to have the option of doing distance based charging so that they can shadow their competitors on pricing policy. I don't think we should dive into billing etc., but I still think we need to allow for geographically based routing. On the following the sun policy, I see this as much the same as 'basic' user mobility. I would expect this to be based around something like home and foreign gatekeeper concepts that have been posted on this list. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >Sent: 03 September 1998 02:57 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: H.323 Addresses > >Hi All, > >It's a shame I wasn't on the call, I might find out what's going on :-( >Thanks to those who are exposing it on the list. :-) > >In my mind, address resolution (or number translation) is a multistage >process. > >In the context of the caller, a destination address may be an >"internal" >form like an abbreviated dialing number (*21), a service prefixed >number >(01161294332374), or a nickname ("doug"), that has to be translated >into an >"external" form. The result of this stage is an external address. > >Once in the external form that identifies the callee, the number is >subject >to resolution in the context of the callee. I think that 800 numbers >are >like this. Since geographical information is probably not known about >the >source or the destination, much less path metrics between them, >factoring >that into the resolution may be a problem. The result of this stage is >an >effective address. > >If the response is a prioritised sequence of endpoints, then the source >can >select from the endpoints within each priority based on >characteristics. >For example 1-800-555-1212 => (1-415-555-1212, 1-212-555-1212) and I >can >select my area code if I know it. > >The third step involves endpoint location, sometimes called gateway >location. This involves taking the effective address and locating a >physical (transport) address that can handle it. This could also be a >prioritised sequence of endpoints (gateways), for each effective >address. >The source can then select from the endpoints within each priority >based on >characteristics. I might look in my IP routing tables, ping them or use >RSVP. > >I don't think that "geographical" proximity is the *real* determining >factor here. It doesn't matter if the source is sitting on top of the >destination if the link is a 300 baud serial line. > >I think that the problem being canvased here is one that comes from the >PSTN domain where the 800 charges are distance dependent. I don't think >that it translates directly to the packet network domain, where charges >are >often distance independent. > >What's more likely to be interesting, is the moving call centre where >the >effective address follows the sun from London to San Francisco to >Sydney to >maximise daytime staff utilisation. Here your 1-800 number will >translate >to 44-171, 1-415, and 61-2 depending on the time of day. > >Regards, > >Douglas > >At 18:01 02/09/98 +0100, Chris wrote: >>All, >> >>Good point, Pete! It's a shame you weren't on the call (there was a >>certain amount of guesswork as to how 800 numbers work)! >> >>There are two ways of handling this that I can see immediately. Although >>philosophically different, in practice they will normally amount to the >>same thing: >>1. The "owner" of a domain needs to be told where a query originates, >>given that the calling location may affect the answer it gives or: >>2. A border element handling queries for 800-type numbers needs to know >>what to do with it depending on the origin of the query. >> >>Regards, >>Chris >>---------------------------------------- >>Dr Chris Purvis - Senior Development Engineer, WAVE CC Software >>Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. >>Phone:+44 1753 661359 email: cpurvis(a)madge.com >> >>-------------------------------- >>Dear All, >> >>It may not be possible to handle 800 numbers in the same way as other >>numbers as the destination may be based on the geographical location of >>the caller. For example, ISPs may be accessible by something like an >>800 number which may be fixed for a whole country, but the POP you end >>up connected to may vary depending on where you called from. >> >>I'm not sure what the implications of this are, but it is something to >>think about!!! >> >>Regards, >> >>Pete >>================================= >>Pete Cordell >>BT Labs >>E-Mail: pete.cordell(a)bt-sys.bt.co.uk >>Tel: +44 1473 646436 >>Fax: +44 1473 645499 >>================================= >> >> >>>---------- >>>From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] >>>Sent: 02 September 1998 13:09 >>>To: ITU-SG16(a)MAILBAG.INTEL.COM >>>Subject: Re: H.323 Addresses >>> >>>Radhika, >>> >>>>We are discussing about H.323 addresing schemes in our bi-weekly H.323 >>>>inter-GK conf calls. >>>> >>>>The H.323 addresses that are being considered are 1. E.164, 2. E-mail, >>>3. >>>>URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I >>guess). >>>> >>>>Although a hierarchical notion of addressing scehmes have been >>>discussed, we >>>>have also recognized that some other variations of addressing schemes >>>are >>>>there. >>>> >>>>For example, people change their physical locations, but they might >>have >>>to >>>>keep the same E.164 addresses. So, a translation is needed. Therefore, >>>the >>>>very physical relationship of E.164 addressing scheme (e.g., knowing >>>NPAs >>>>and NXXs, one can find the distance) has been broken. >>> >>>I was under the impression that finally (after several weeks of >>>discussion) we'd reached closure on this in last Thursday's call. The >>>solution that I understood had been agreed came in two parts: >>>1. Mobile IP solves most of the problem for us - E.164 number resolves >>>to >>>an IP address which may be anywhere in the world at any given moment in >>>time. >>>2. If a user wants to move (and take their number with them) to being >>>in >>>an administrative domain with an otherwise reasonably contiguous E.164 >>>address space, this is easily handled as follows. The domain that >>>"should" (in the hierarchical sense) "own" the number that the user is >>>keeping holds a record of where to contact the current holder of that >>>number (which will typically be an entity to which an LRQ message can >>>be >>>sent). >>> >>>>Another example can be 800 numbers where the translation is also >>needed. >>>It seemed to be agreed in the call that 800 numbers are not a special >>>case, but merely an example of number portability. >>> >>>>In addition, from mobility point of view (device or person) wired (and >>>>wireless?) environement may also be looked into. >>>Does this mean anything at all? >>> >>>>As we go froward, we may consider many of those aspects as pointed >>above >>>to >>>>provide solutions for the H.323 addressing schemes. >>>I was under the impression that we'd reached closure on most of these >>>already. >>> >>>Regards >>>Chris >>>---------------------------------------- >>>Dr Chris Purvis - Senior Development Engineer, WAVE CC Software >>>Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. >>>Phone:+44 1753 661359 email: cpurvis(a)madge.com >>> >> >> >

1 0

Three TDs have been uploaded
by Sakae OKUBO 03 Sep '98

03 Sep '98

Dear Q.12-14/16 experts, I have placed the following three TDs for the coming SG16 meeting at the Incoming directory (ftp://standard.pictel.com/avc-site/Incoming/) H220AM6.zip - Amendment 6 to H.222.0 for Determination Q12status.zip - Q.12/16 status report Interim.zip - Report of interim Q.12-14/16 meetings They were all produced with Word 98 Mac (compatible with Word 97). 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: H.323 Addresses
by Chris Purvis WVdevmt-WS 02 Sep '98

02 Sep '98

All, Good point, Pete! It's a shame you weren't on the call (there was a certain amount of guesswork as to how 800 numbers work)! There are two ways of handling this that I can see immediately. Although philosophically different, in practice they will normally amount to the same thing: 1. The "owner" of a domain needs to be told where a query originates, given that the calling location may affect the answer it gives or: 2. A border element handling queries for 800-type numbers needs to know what to do with it depending on the origin of the query. Regards, Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com -------------------------------- Dear All, It may not be possible to handle 800 numbers in the same way as other numbers as the destination may be based on the geographical location of the caller. For example, ISPs may be accessible by something like an 800 number which may be fixed for a whole country, but the POP you end up connected to may vary depending on where you called from. I'm not sure what the implications of this are, but it is something to think about!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] >Sent: 02 September 1998 13:09 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: H.323 Addresses > >Radhika, > >>We are discussing about H.323 addresing schemes in our bi-weekly H.323 >>inter-GK conf calls. >> >>The H.323 addresses that are being considered are 1. E.164, 2. E-mail, >3. >>URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I guess). >> >>Although a hierarchical notion of addressing scehmes have been >discussed, we >>have also recognized that some other variations of addressing schemes >are >>there. >> >>For example, people change their physical locations, but they might have >to >>keep the same E.164 addresses. So, a translation is needed. Therefore, >the >>very physical relationship of E.164 addressing scheme (e.g., knowing >NPAs >>and NXXs, one can find the distance) has been broken. > >I was under the impression that finally (after several weeks of >discussion) we'd reached closure on this in last Thursday's call. The >solution that I understood had been agreed came in two parts: >1. Mobile IP solves most of the problem for us - E.164 number resolves >to >an IP address which may be anywhere in the world at any given moment in >time. >2. If a user wants to move (and take their number with them) to being >in >an administrative domain with an otherwise reasonably contiguous E.164 >address space, this is easily handled as follows. The domain that >"should" (in the hierarchical sense) "own" the number that the user is >keeping holds a record of where to contact the current holder of that >number (which will typically be an entity to which an LRQ message can >be >sent). > >>Another example can be 800 numbers where the translation is also needed. >It seemed to be agreed in the call that 800 numbers are not a special >case, but merely an example of number portability. > >>In addition, from mobility point of view (device or person) wired (and >>wireless?) environement may also be looked into. >Does this mean anything at all? > >>As we go froward, we may consider many of those aspects as pointed above >to >>provide solutions for the H.323 addressing schemes. >I was under the impression that we'd reached closure on most of these >already. > >Regards >Chris >---------------------------------------- >Dr Chris Purvis - Senior Development Engineer, WAVE CC Software >Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. >Phone:+44 1753 661359 email: cpurvis(a)madge.com >

2 1

Re: Communications between Administrative Domains
by Andrew Draper WVdevmt-WS 02 Sep '98

02 Sep '98

On Wed, 2 Sep 1998 10:37:32 +1000 Douglas Clowes wrote: > From my POV, this underscores the need for thought on the Back End > Services, both in terms of the services to be offered, and the protocol(s) > to support those services. Just for my information, where does the term Back End Services come from? Is this related to some sort of protocol currently run by telcos (SS7 database services for example)? Does the term always refer to a third server somewhere else which communicates with both the originating and destination border elements? While discussing billing, I assume that we are only discussing payment from the originating administrative domain to the destination administrative domain and that we are not discussing payment to the transport network providers (such as ISPs) for QoS connections (such as those set up by RSVP). > Here, it is fairly clear that authentication and billing is a Back End > Service. The available destinations for a call may be dependent on the > (authenticated) identity of the caller. Yes, I agree that some entities will reject SETUP messages which are not authenticated and do not provide a suitable payment token. However, I think we should try hard to design a protocol which will not cause hopeless (bound to fail) SETUP messages to be sent. This is important because a) SETUP messages create state in the recipient and b) SETUP messages may involve charges to the originating administrative domain. Later on in this message I use the term "setup requirements" to refer to a description of setup messages which the destination administrative domain will accept. Examples would be "you must authenticate using mechanism X (and server Y)" or "you must pay using method Z" (are there any other forms of setup requirement?). I use the term "setup capabilities" to refer to the set of mechanisms which the originating border element is able to send in a SETUP message (because they have been implemented and enabled). > The "token" to be included in the > Setup message is produced by the Back End Service and may well be > destination sensitive. I agree. > Which raises the possibility of address translation > also being a back end service. In the sense of having a third party server (not belonging to the originating or destination administrative domain) perform address translation I agree. > Back-End Services (may) include: > > o caller identification, authentication, and authorisation; > o address translation, gateway location; > o call pricing; > o call detail recording, billing, and settlement; By my understanding of the term back-end services (which might be wrong) call pricing is for the destination administrative domain and is unrelated to any third party server. Call detail recording is also a problem only for the destination administrative domain. > which are all interrelated Out of interest, are you expecting/requiring that the services provided by each of your bullet points must be provided by the same third party server (or would using one server for address translation and another for billing be acceptable). If not then how are they all interrelated? > and, in total, outside the scope of the > gatekeeper to gatekeeper communications. I disagree. Here are my reasons for thinking that identifying the requirements of the destination administrative domain fall within the scope of communications between administrative domains (an important subset of gatekeeper-gatekeeper communications). To prevent hopeless SETUP messages from being sent the originating border element (or a third party) needs to work out the intersection of its setup capabilities and the destination border element's setup requirements. As far as I can tell there are three ways for the originating BE to find out the destination administration domain's setup requirements: a) It can find out during the resolution stage (the stage where an email-ID or E.164 number is translated to the address of a border element). b) It can find out during the LRQ/LCF exchange. c) We could design an extra protocol which is used before/after LRQ/LCF to let the originating BE find out what the requirements of the destination BE are. For an email-ID type destinationAddress using the DNS to find the destination border element seems non-controversial. DNS only provides the name and address of the destination, so method a is not appropriate. In this case I favour method b over method c for two reasons: firstly because it reduces the number of round trips required for a call setup and secondly because requirement 7 (of the latest annex G draft "diff0201.doc") suggests that the minimum number of changes to existing protocols should be made. The E.164 to border element address protocol is as yet unspecified, so it could return the requirements of the destination administrative domain at the same time as it returns the address to which to send LRQ. If the E.164 number resolves to an administrative domain which can be contacted directly then this doesn't seem to help much (as only one address is provided to which an LRQ must be sent anyway - so there are no efficiency savings to be made). If the E.164 number would resolve to one or more third party gateways (eg. for a POTS number) then passing the setup capabilities of the originating border element might help narrow down the responses which the resolution server returns. However this has security implications and so should be a choice for the originating BE. We still need a mechanism for the originating BE to ask the destination BE about its setup requirements if it is being paranoid and not telling the resolution server. Hope this makes sense (and my assumptions aren't too wildly different from yours). Regards, Andy. -- Andrew Draper - Principal Development Engineer - WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks. mailto:adraper@dev.madge.com phone:+44 1753 661329 pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F

2 1

Directory Services?
by William Pimentel 02 Sep '98

02 Sep '98

Hi all I haven't seen anything about directory services interacting with GKs, how would a user know the alias (number or string) of the other party he/she wants to call? Or is there any way for a Terminal user to retrive/search the users currently registered with a GK? And what if the other party is register with another GK? Thanks -- William Pimentel w-piment(a)uniandes.edu.co

1 0

subscribe, how to
by Barnaby Duncan 02 Sep '98

02 Sep '98

I wish to subscribe to this list. Please infrom me of the way to do that. Barnaby

1 0