Annex G

[Roy, Radhika R, ALTEC]

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