Chris:

I have enclosed my reply below. Thanks for providing me an opportunity to clarify further.

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: Tuesday, September 08, 1998 1:25 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Annex G

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.

[Radhika: A H.323 call is end-to-end. Moreover, H.323 is an application. That is, it will have both network layer and upper layer (above network layer) resources. An MCU in the carrier network that will have resources at both network layer and upper layer may be shared among thousand of users. Now an end-to-end H.323 call may span between the domains that will have H.323 networks (LAN, IP, ATM, FR, and/or others - in any combinations). It happens to be that the two domains need to send signaling messages via border GKs/Border Elelments. H.323v2 envisions that the GK will have an abstraction of BW/QOS at the GK level. If we take the example of ARQ messages, then the ARQ has to be confirmed between the end-to-end considering both network layer and upper layer resources as well. So, this simple example shows why the signaling messages need to be sent across the domains if one needs to implement that option to differentiate services.]

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.

[Radhika: I feel that Mr. Draper's email is not the last word in solving the H.323 mobility problems. It may be one of the options (may not be the best) to solve the H.323 mobility problems in a limited way. (For example, IP mobility problems could also be solved in a similar way that has described by Mr. Draper. Unfortunately, mobile IP people has taken a different approach.) I personally feel that the H.323 mobility problems are much more complex, and it requires careful study to find efficient solutions. Probably, a mini-group, like inter-GK, may have to work to find the appropriate solutions. The most important point is that the signaling messages need to be sent across all Zones and Domains, because a services provider may find numerous ways to create back-end services through intercepting the signaling messages from the GKs as appropriate. The more important point is that H.323 signaling messages exist, and it is almost against the principle of standard making process to MANDATE not to use those signaling messages either for the inter-zone or for the inter-domain communications, and I believe that it may also NOT be acceptable to the ITU-T as a matter of principle.]

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.

[Radhika: Here, I am not sure whether we are speaking the same thing. In APC 1382, Mr. Sengodan has shown why the exiting GRQ message fields need to be extended for the GK-to-GK communications considering the multiple GK communication environment if multicasting is used. I think that this work has become one of the most important contribution if one needs communicate between the multiple GKs considering the multicasting. I was referring that work. (Mr Toga also has done a beautiful work for the zone message sets.) Similarly, AT&T contribution, similar to Nokia's, has proposed the extension of the existing RAS message fields for communications in multiple GK environment.]

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@madge.com