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:

...

...

...

<excerpt>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.]

</excerpt><<<<<<<<

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

...

---