At 09:13 21/08/98 +0200, HERSENT Olivier CNET/DSE/CAE wrote:
Some follow-on comments inserted below :
If you are visiting another IP network, are you asking the GK for more than bandwidth and address resolution (absent BES-based AR).
--- Yes, for instance if I dial an E164 number, or if I use a high level of QoS, I will be billed, probably based on the GK info. Maybe I also have a set of short numbers programmed in your home GK, and you would like to use them ...
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.
recognize from the calling party alias that the terminal si from an
external
administation having an agreement with the visited administration. It would then forward the xRQs to the home gatekeeper of the terminal and get the xCFs in reply.
This proposition requires the calling party alias to identify the "home" administration, and the gatekeeper to be able to resolve the "home" gatekeeper.
--- Yes, this would be based on the domain name of an email alias. When completing a roaming agrement, each party would pass the other party a list of domains to include in the agreement. That could be *.francetelecom.fr, *.myprefferredcustomer.com, ...
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.
Then to identify the GK, the usual DNS TXT record lookup could be used, or 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.
This has many benefits :
- The home GK knows where is the roaming teminal and can forward calls.
- Any policy implemented at the home gatekeeper (restricted phone usage,
etc
...) is still enforced in any visited domain
So, bandwidth restrictions in the home zone would be enforced in a visited zone?.
--- Yes, and many more services. for instance you could be using aprepaid 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.
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.
- It is simple
I think we should be looking at Back-End Services, at least so we know what to expect of them, and don't make GK-GK break later, or make GK-BES difficult/impossible.
--- We are looking into this. So far the main restriction we see in existing toolkits for this type of GK/GK services is that they are sometimes unable to initiate RAS/Q931 messages (no API to send an xRQ). Hopefully this will be improved in future versions.
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.
From my point of view, gatekeepers should be responsible for policies and
actions that relate to their zone of influence. Things that extend beyond a gatekeeper's zone, are candidates for the Back-End 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