> Douglas:
>
> I am so happy to see your insights in solving the specific problems. I
> exactly understand where you are driving at. The inter-GK signaling are
> the most interesting problems. The more you dig, the more jewels will come
> up. Let me explain why I am saying so.
>
> Instead of providing point by point reply of your email, I will provide a
> generalized answer so that you can find answers for other specific schemes
> as well.
>
> H.323v2 envisions that signaling messages can be passed through the GK. We
> are just extending the situation in the case of multiple GK environment.
> In your example, you have made an assumption that all signaling messages
> will follow the same path (Please forgive me that this path is the not
> network-level path. This path notion is of GK-to-GK level) between the
> GKs. It does NOT have to be so. A GK is an application layer entity, and
> can be made to have much higher intelligence (what we cannot expect at the
> network level devices or entities because they have other constraints). A
> GK can understand each signaling message, and a decision can also be taken
> how to route each signaling message that if one wants to implement that
> way. (As if it appears that the routing has become multidimensional!)
>
> For example, a GK can be used to route messages for authentication in one
> way while the billing messages in another way. Similarly, ARQ messages may
> be routed in another way. This routing between the GKs can be
> implementation specific, and at H.323 level, we are creating abstraction
> of routing of signaling messages (Please note that we are NOT providing
> any solutions for specific rotuing schems at the H.323 level for any
> specific signaling messages. Let an implemetor decide that). Please note
> that we are NOT making assumptions, at H.323 level, that all signaling
> messages will be sent through the same GK-GK path.
>
> I hope that it may clarify the fundamental question for which we are
> looking for an answer.
>
> Regards,
> Radhika
>
> ----------
> From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU]
> Reply To: Mailing list for parties associated with ITU-T Study Group
> 16
> Sent: Tuesday, September 08, 1998 8:17 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Annex G
>
> At 18:17 08/09/98 -0400, Radhika wrote:
> > <<m_Glenn>>
> >
> >Hi Glen:
> >
> >My reply is enclosed herewith. Many thanks for provding me an opprotunity
> to
> >clarify the points.
> >
> Radhika,
>
> In part, you wrote:
>
> >>>>
>
> In the direct endpoint, the call will be established directly between the
> endpoints although the call will be established over the multiple zones,
> and no GK will be involved.]
>
> <<<<
>
> You have also made other statements made about bandwidth management in
> intermediate zones. I _still_ have the feeling that, despite statements to
> the contrary about media routing, you are still expecting the media
> packets will flow "over the multiple zones". In the general case,
> especially with no explicit path management (suck as GK-routed media),
> there is absolutely no reason why they should.
>
> In the scenario Z2---Z3---Z4
> / \
> / \
> C1--Z1--------------Z5--C5
>
> Each Zone may be in a different administrative domain. The relationships
> between administrative domains may not be mesh topology, but linear;
> sequential in increasing numerical order. Inter-gatekeeper communication
> may have to go the long way round because of established relationships,
> authentication, and authorisation requirements. But, in my aspirations,
> call setup and media would be able to take the direct route. There is
> nothing to be gained by having Zones Z2, Z3, and Z4 active in bandwidth
> management at the ARQ, It is even counter-productive to have Zone Z3
> reject the call because its LAN is busy with internal traffic.
>
> What needs to happen here, is that the source gateway (GW1) needs to
> obtain, from the ARQ stage, an authorisation token acceptable to the
> destination gateway (GW5), or its gatekeeper (GK5). This token
> authenticates the call, authorises it, and provides for the payment
> mechanism. The token is to be included in the call setup, and probably in
> the ARQ in response, meaning GK5 generates and validates the token.
>
> Payment follows the relationships, Z1=>Z2=>Z3=>Z4=>Z5, but, for each zone
> to authorise the call, it needs the call to be identified as originating
> from a trusted party. Since only Zone Z1 trusts Customer C1, the source
> information needs to be augmented along the way. Zone Z2 only trusts Zone
> Z1 and expects to be paid by Zone Z1, not Customer C1. And, so it goes
> down the path.
>
> Coming back, the ACF needs to contain the ultimate call signalling address
> in Zone Z5, be it the gateway or gatekeeper in that zone. You can always
> go for GK routed through each zone, if you want to measure call duration
> yourself; but, I would expect that to be limited to exclude the media.
>
> At settlement time, the billing goes in the reverse direction. Zone Z5
> bills Z4=>Z3=>Z2=>Z1=>C1 and the customer, hopefully, pays.
>
> Now, whether token generation and validation, and all the authentication,
> validation, billing and settlement, is done within the gatekeeper, or by
> the elusive Back-End Services provider, is unresolved at this time.
>
> Regards,
>
> Douglas
>
> >Thanks,
> >Radhika
> >
> >> ----------
>
>
>
