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(a)francetelecom.com modified as
toto(a)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
>
>
