Subject: RE: [SIP] Registration Question

From: [email-masked]
Date: Thu, 23 Nov 2000 12:48:44 +0200

Hi,

In 3GPP (third generation mobile networks standardisation) the situation is
that a UA always has an outbound proxy, who's address is learned using DHCP
(or some other methods). If the user is roaming, this proxy is located in
the visited network, and can offer local services (911 etc.) 

In addition each user has a "Serving proxy" (in 3GPP terminology Serving
Call State Control Function, S-CSCF), which is always situated in his home
network/domain. This proxy performs service control for both outgoing and
incoming sessions. So, each outgoing INVITE (actually any request) from a
user first traverses the outbound proxy and then the "serving proxy", which
then decides what to do with the request based on service control:  

UA--->Outboud proxy (visited nw)--->Serving proxy (home nw)--->

The serving proxy is assigned dynamically to the user during registration,
e.g. using a 3xx response to REGISTER. The reason might be different service
control preferences/capabilities or just load balancing.

The problem is the routing of requests from the outbound proxy (visited nw)
to serving proxy (home nw). Basically, the outbound proxy can check the
user's domain name in From: field and route the request to (some proxy in)
the correct home domain. In the home network a database lookup (or SIP
redirect) would then be used to determine which S-CSCF is currently
allocated to the user and forward the request there. (This is analogous to
what happens with incoming requests to the user in the home domain - S-CSCF
is located by a database query.)

UA--->Outbound proxy--->"Home domain proxy"--->DB lookup--->Serving proxy

However, there is a need to optimize the flow by allowing UA or the outbound
proxy to know the serving proxy's address directly. This could be done
during the registration. The serving proxy's address would need to be
carried in the 200 response to REGISTER, so that Outbound proxy and UA are
able to learn it. So the request routing would be directly:

UA--->Outbound proxy--->serving proxy

In my understanding SIP does not support this at the moment, so there have
been discussions whether to use Record-Route or some new header. So, there
would actually be some use for what Bill Moloney was asking, at least in
mobile networks.

Rgs,
	Markus

Billy Biggs:
> Moloney, Bill ([email-masked]):
> 
> > I have a question on registration -
> > [...]
> > I believe that I could accomplish this by having B respond to the
> > registration with a 301 Moved Permanently, including a 
> Contact header
> > for C in the response.)
> > 
> > The question is this: Does this redirection only impact future
> > registration requests, or does it impact all future 
> requests - such as
> > INVITE?
> 
>   The redirection only impacts the specific registration 
> transaction and
> (optionally) future registration transactions.
> 
>   Requests such as INVITE go to their destination directly, and have
> nothing to do with the registration.
> 
> > What I am trying to accomplish is to have A direct all of its future
> > requests (not just registration) to the new proxy server 
> (C). Will the
> > redirect that I mention above accomplish this?
> 
>   This is called an outbound proxy, where even though the message is
> directed to, say, 'sip:[email-masked]', you send 
> the message
> to 'my.local.proxy.com' which then forwards it on.
> 
>   The outbound proxy is configured directly on the SIP end 
> device, or it
> can receive it from DHCP.  There is no way to signal using REGISTER or
> whatever that the proxy should be used as an outbound proxy, nor would
> it make sense to provide such signalling.
> 
> -- 
> Billy Biggs, 3Com               Email: [email-masked]
> http://www.div8.net/billy/      Phone: [email-masked]
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip