Re: Comments on AT&T proposal

Some follow-on comments inserted below : them ... the parties in agreement could also store some IP addresses. The home GK can find who is the visited domain GK from a token inserted in the relayed xRQs, or another comvention such as name mangling (source alias toto@francetelecom.com modified as toto@francetelecom.com!deutschetelecom.com ) This doesn't have to be standardized, it is just added value programming on top of the GK. prepaid account that allows only to call some numbers (your company ...). This restriction would be enforced as well in the visited domain. Of course the visited domain can also enforce its own policy, because it relays the xCFs. For instance if the home GK allow to call a premium rate number, but the local policy does not allow this, then the visited GK would simply change the ACF into an ARJ.
We plan to bring this work to ITU/ETSI as soon as we have something that seems flexible enough to build most services.

At 09:13 21/08/98 +0200, HERSENT Olivier CNET/DSE/CAE wrote:
This really does beg the question of "what are the back-end services?". If these types of services are "Back-End Services" then it is appropriate for the "visited gatekeeper" to request these services of its _own_ Back-End Server, rather than try to identify whether they are local or not.
From the Gateway POV, the services _may_ be provided by the GK, logically. Although, there does exist a link between the GW and the BES in most diagrams.
Obviously, the users "home" address needs to be identified. My question is whether the GK, or the BES, should be doing this. I expect there to be many more GK than BES.
Well, No. I don't think that (what I regard as) zonal policies operate outside a zone. I regard the GK as supporting zonal policy. I regard Administrative Domain policy as the responsibility of the BES, but that's the open question.
I don't understand this. Or at least, how it relates to Back-End Services.
We plan to bring this work to ITU/ETSI as soon as we have something that seems flexible enough to build most services.
Using the above example, abbreviated dialing, that should be the same as I move from zone to zone. It should be dependent on who I am, not where my home zone is. If I transfer, within my company, from one zone to another, should my identity change for my new home gatekeeper? Should my abbreviated dialing list change? I don't think so. I think that Back-End Services should be able to support traditional AAA, as it applies. This includes user-identification, and therefore roaming. This does not preclude this occuring at the gateway by utilising RADIUS, for example. I think that BES should support address translation. This would include both abbreviated dialling, plus prefix stripping and interpretation (e.g. international access codes, like 011). By allowing the translation to return any alias address, including transport addresses, it could also support gateway location. I think that the BES should be able to support call detail recording, accounting, billing and settlement services. If all of that is acceptable, as the province of Back-End Services, how does it affect the Gatekeeper-to-Gatekeeper Communication and the Communication between Administrative Domains? Quite substantially, I would have thought. So, even if we don't yet define the protocols to operate between H.323 elements and the BES (at reference point D), I think it would be constructive to determine what's in there, and is therefore _not_ between gatekeepers (at reference point C). Regards, Douglas
participants (2)
-
Douglas Clowes
-
HERSENT Olivier CNET/DSE/CAE