September 1998 - sg16-avd - lists.packetizer.com

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

09 Sep '98

<<m_Glenn>> Hi Glen: My reply is enclosed herewith. Many thanks for provding me an opprotunity to clarify the points. Thanks, Radhika > ---------- > From: Glen Freundlich[SMTP:ggf@lucent.com] > Reply To: ggf(a)lucent.com > Sent: Tuesday, September 08, 1998 2:58 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > <<File: m_G.doc>> > I have added my comments as change-marked text in Radhika's document, > attached here. > > Glen > > > Roy, Radhika R, ALTEC wrote: > > > > 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 > > > > --------------------------------------------------------------- > > > > Name: m_G.doc > > Part 1.2 Type: application/msword > > Encoding: base64 > > -- > 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 >

2 1

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

08 Sep '98

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

3 2

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

08 Sep '98

Chris: I guess that you have received my earlier email addressed to you via ITU-T SG16 mailing list. As I mentioned before, AT&T's contribution deals with RAS signaling messages only. The proposal does separates RAS signaling in one stage, and call signaling in another stage. (In this respect, you are confused in understanding the AT&T's contribution. I guess that the above answer will clarify the situation. If still you have questions, please let me know.) Based on this clarification, you can now create the RAS or call signaling scenarios as appropriate. We are taking about the communications between the GKs in multiple GK environment. So, the communication is occurring at the GK level, and is above the so-called network level (e.g., IP, ATM, or FR) level. If a GK decides which one is the next GK it needs to choose for sending a message, it constitutes a kind of routing at the GK level. As I mentioned before, H.323v2 does envision to transfer messages between the GKs, but H.323v2 does not have the means to abstract that notion of routing at the GK level. The communications between multiple GKs mean communications between multiple zones (or can also be said communications between "chain of zones"). Each GK will have a complete knowledge of its own zone. Each GK will have its address table, and the knowledge of the addresses can be obtained through exchanges of zone/LRQ messages. Each GK will have its ability how to route RAS message between the GKs knowing the destination addresses. So, the notion for communicating between the zones knowing the destination address is known (not a discovery in a random fashion as mentioned by you). In the case of multicasting between the GKs, the assumption is that it is again happening at the GK level. The notion is that the same message has to be "routed" to all GKs. The notion of "routing" between the GKs is still there although the network level multicasting can be used for implementation to route the message to each GK (as in your case you have chosen IP network. Please also note that a H.323 network can also be LAN, IP, ATM, FR, and/or others - in any combination). I hope that the above explanation will clarify the things. Thanks, Radhika > ---------- > From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Tuesday, September 08, 1998 4:50 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > 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

Locating users
by William Pimentel 08 Sep '98

08 Sep '98

Last time i asked i was simply ignored (i guess that's better than being flamed but didn't help either), so if you think this is not the place to ask this, sorry. How do i locate a user when i don't know his/her alias? GK's mantain a list (or table) of alias-adress to perform translation when another H.323 entity requires this, what other information does the GK know about the registered endpoint? user's name, e-mail adress? I think it would be a good idea to have like an extension of the GK funtionality to include a directory service (LDAP maybe?). I think this does have to do with inter-GK communication (maybe just within the admin domain to have a directory of the users in a domain) and to make it easier for end users of H.323 terminals to locate people that are curently on-line. What do you think? -- William Pimentel w-piment(a)uniandes.edu.co

1 0

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

08 Sep '98

Radhika, >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. Thank you for this clarification. Given that you are now permitting call-signalling and RAS messages to follow different routes I see no advantage, when placing a call between administrative domains, to routing any RAS message other than LRQ/LCF/LRJ between gatekeepers/BEs. The other problem your proposal appears to be trying to solve appears to be that of roaming users. Andrew Draper's email of 21st August explains why there is no necessity for a roaming endpoint to register with a foreign gatekeeper. Thus support of roaming users is no reason to route GRQ/GCF/GRJ, RRQ/RCF/RRJ, ARQ/ACF/ARJ, BRQ/BCF/BRJ, URQ/UCF/URJ, DRQ/DCF/DRQ, IRQ/IRR/IACK/INACK and RAI/RAC/RIP/NSM/XRS between gatekeepers. Nokia's APC 1382 (S. Sengodan, Nokia, "On the Use of Multicast Scope for Gatekeeper Discovery," is explicitly limited to GRQ/GCF/GRJ, and may be of interest as a way of propogating knowledge of gatekeepers within an administrative domain. The zone messages proposed by Jim Toga in APC-1422 are an alternative solution to a similar problem. 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 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