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(a)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(a)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
