Some follow-on comments inserted below :
simplest ways to do it was that the roaming terminal would send the ARQ, ... to the visited network GK (discovered my broadcast/multicast). This GK
would
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 ...
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, ... 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 a 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.
- 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.
We plan to bring this work to ITU/ETSI as soon as we have something that seems flexible enough to build most services.
So roaming might be a good reason to forward xRQs ... just my FF.02.
Best regards, Olivier HERSENT-- France Telecom CNET IP Telephony Technical Proj. Manager - TULIP