On behalf of Espen and myself I will post this (delayed) reply to Douglas Best regards Lill -- Lill Kristiansen, Ericsson Internet Development, XoIP (former MMTS) Billingstad, Norway email: etolkr@eto.ericsson.se
- - Hi,
Thanks for clarifying this. We're basicly happy with an agreement that mobility issues more work.
It is not enough to just say "roaming"! Douglas
Fully support this statement! There are (at least) two different aspects of mobility: Terminal mobility - A terminal communicating independent of location User mobility - The user receives his phone service independent of of terminal and underlying network (domain). In addition we have the discrete vs continuous cases. See Tiphon WG7 for more definitions
In wireless one mostly talk about the continuous case (aka handover). Discrete user mobility may very easy be achieved by user oriented E.164 numbers and RAS messages Discrete terminal mobility is often out of scope of the application (may be done by Mobile IP or other means) Digression: In case an H.323 E.164 number is assigned to a terminal/plug in the wall, (i.e. similar to the PSTN case) then you place a call towards this fixed
place. The fact that my phusical phone can be plugged in also at another
house, does not offer 'mobility', as the calls will still be charged to the plug in the wall. So even though is is a sort of 'discrete terminal mobility', it is not what we're after. (and why the UPT concept
was invented) end digression
However in most cases with terminal mobility the continuous/wireless case is the interesting one. We consider wireless to be a very important
and radio specific access technology, outside the scope and competence of sg16 and Tiphon.
Here we're talking about user mobility, as we hope terminal mobility can
be achieved with other/access techniques.
But the point is, when we are introducing "user mobility" between the Annex G domains, we should make sure that any supplementary services the user subscribes to are also reachable. This includes both services invoked by the service provider and terminal invoked services.
For the service provider invoked services one can see solutions as 1. Downloading a service profile from home domain to the visited domain This is done in GSM networks, and requires all services to be standardized.
2. Route the call signaling channel through the home domain This allows proprietary services within the domain to be executed anywhere. I.e. one obtain service mobility, and virtual home environment
There is danger of "tromboning" which is the reason it hasn't been introduced in switched networks, but as H.323 uses a packet network, the tromboning applies only to the signaling, which in many cases might not be problematic.
See also some comments below Espen and Lill
-----Original Message-----
From: Douglas Clowes [mailto:dclowes@ozemail.com.au] Sent: 27. april 1999 01:01 To: Espen Skjæran Cc: ITU-SG16@mailbag.cps.intel.com Subject: Re: Annex G and Roaming?
Espen, It all depends on what you mean by "roaming of users between different
domains".
Annex G does support some functionality for some favours of roaming,
but
requires further development - particularly in how to use these
aspects
between domains.
Comments below. At 14:54 1999-04-23 +0200, Espen Skjæran wrote:
Hi all,
I've recently heard (unofficially) that some claim Annex G (APC-1546/TD-20 in Monterey) also to support roaming of users between different domains.
If this is true, I wonder how.
I can see how the AccessRequest/ValidationRequest might be sent from
a
visiting domain to the home domain for per-call authorization. While this might work in simple cases, it will hinder the use of services while roaming.
Per call authorization permits a user from one domain to use gateway equipment from a second domain, to make calls to through a gateway in
a
third domain. There could even be a fourth domain present as a
clearinghouse.
I don't know what you mean by "hinder the use of services while
roaming" in
this context. Perhaps you could elaborate please.
This is the VAS/supplementary services issue mention above
I can not either see any mechanism to authorize the roaming registration.
Registration is a completely different issue, and I don't see support
for
it in Annex G. Perhaps an RRQ with a remote e.164 or IP address could
be
issued to the home domain, by the terminal or host gatekeeper?
I am sorry to post based on "rumors", but this may change the scope
of
Annex G significally, and I worry if this might affect future work on
roaming. As Tiphon has just started their work on roaming by
analysing
existing roaming techniques in telco and datacom/IETF work,and not
yet
reached any conclusion, it seems premature to use annex G in its current state for roaming.
These concepts will have to be developed in parallel. There is more
than
one "type" or "roaming", and different people will think of different things when that word is used.
Maybe have a look at Tiphon 12TD088 for an overview of existing techniques for mobility and roaming in datacom and telecom
Some people think of terminal mobility,
yes, and often the continuous/wireless one
while others think of mobile IP. Neither of these apply to the mobile user on public ingress gateways depicted above, but they are no less valid and need to be considered.
If we compare to the terminology used above, we think what you refer to is discrete user mobility, more like in UPT, where you register for in/outgoing calls to be routed to your current location. I.e. it relates to you and your H.323 application, and the call routing you want (including routing to IVR etc..) And it is true that this is neither wireless nor Mobile IP. But it is important as well.
When we know what the opportunities are, we will be better placed to
seek
solutions. It is not enough to just say "roaming"! Douglas
Espen