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@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

...

---