Subject: RE: [SIP] Outbound call routing

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2000 02:33:52 -0400

> -----Original Message-----
> From: Simon Barber [mailto:[email-masked]]
> Sent: Thursday, September 14, 2000 3:47 PM
> To: [email-masked]
> Cc: Jonathan Rosenberg
> Subject: RE: [SIP] Outbound call routing
> 
> 
> The issue is service transparency with user mobility. User mobility is
> supposed to be one of SIP's strengths.
> 
> Solving the problem by having the client add Route to future requests
> requires a specific client. This does not fit in well with 
> user mobility -
> the user should be able to log into any generic client, and 
> still have his
> services work. He should not have to use a special client for 
> his services
> to work. This is client mobility, not user mobility.

Indeed, he should be able to log into any generic client, and have his
services still work. That will happen without a hitch if the user is allowed
to register directly with his normal registration server. The glitch is
that, for some reason, the local domain has insisted that instead messaging
pass through it via some dedicated proxy server. It is a subject of intense
debate, apparently, about whether such a server is needed. 

> 
> A possible solution would be to add a header like 
> record-route, but rather
> than scoping it to a call leg, scope it to a particular registration.

I don't follow how this would work. Where does this new header come from?

> 
> There are many services that get broken by not being able to 
> track outbound
> calls.

No disagreement; I think you definitely want to work through your normal
registrar/proxy as you move around.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Wayne Cutler" <[email-masked]>
Date: Fri, 15 Sep 2000 10:28:00 +0100

(I'm resending this since it didn't go to the list last time due to clumsy
fingers).

I believe that what Simon is asking for (please shout up if I'm misrepresenting
you)  is the abiltiy for the registrar/proxy to be able to explicitly assign an
address to be used by the SIP user for all future requests during this
registration.

An analogue would be the h323 GK scenario where there may be a well know RAS
(h323 registration) address which may be used by a h323 user to register with
his "home" GK. For a succesful registration, the response provides a completely
separate address to be used for h225 (call) signalling. The allocation of the
h225 address is subject to local policy in the GK.

In the SIP case, there doesn't seem to be a way (at least not one that's
explicitly stated) for a Registrar to accept a registration request and tell the
recipient an address that the registrar/proxy requires to be used for all future
requests. Such a capability would be useful, I believe.

Regards, Wayne.

---

From: "Wayne Cutler" <[email-masked]>
Date: Fri, 22 Sep 2000 11:10:09 +0100

Henning Schulzrinne wrote :-
>Forcing routing seems yet another user configuration parameter, along
>with other service parameters that I'd like to keep even as I change
>terminals. Thus, this is probably best addressed as user configuration
>data downloaded from the REGISTER server, along with things like
>speed-dial buttons or, say, CFB/CFNA end system behavior. If we define
>an extension of CPL that's tailored to user agents, this might be a
>useful feature to have, as one may want to make this feature
>conditional.

This just feels like a misuse of CPL. CPL is about describing internet telephony
features whereas
what is being proposed is a mechanism by which the Registrar can mandate an
address/hostname
to be used for future requests. SIP has a number of headers which are used to
influence/mandate future
routing of requests/responses. Isn't this just another example of a header that
influences message routing?
I believe that there  should be an explicit  mechanism in the registration
response (e.g. a new header?) to
enable this functionality.

Regards, Wayne.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Sep 2000 01:59:28 -0400

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, September 22, 2000 8:56 PM
> To: Jonathan Lennox
> Cc: Jo Hornsby; Simon Barber; [email-masked]; 'Sip@Lists. Bell-Labs.
> Com'
> Subject: Re: [SIP] Outbound call routing
> 
> 
> > 
> > I have a suggestion here: use the 'maddr' parameter of the 
> Request-URI.
> > I.e. to the local proxy server, I send a request with the 
> Request-URI
> > 
> 'sip:[email-masked];maddr=outbound-services.home-i
> sp.example'.
> 
> ---
> 
> This approach has one subtle problem. The maddr parameter 
> can't specify
> a port number, so that if the destination URL has a non-5060 
> port number
> (or the home proxy has a non-5060 port), things don't work right.
> 
> Henning

Well, there is also a not-so-subtle problem that this will cause a loop.

To summarize, we have a user agent A, local proxy PL, home proxy PH:

A----->PL----->PH

The proposal is that the request URI in the A->PL request be
sip:uas@uasdomain;maddr=PH. THus, when it arrives to PL, PL will forward it
to the URL in the request URI, arriving at PH. 

Now, PH looks at the request. The domain in the request URI (uasdomain), is
not its own, so it forwards it to the URL in the request URI. Problem is,
that will cause the request to loop back to itself.

This could be fixed by having PH basically discard the maddr parameter. Sort
of like popping the top route. I would argue, in fact, that you really
should be using the Route mechanism instead of trying to hack that mechanism
into the maddr parameter.

The Route mechanism will probably work. The primary issue is one of
configuration; how does my UA determine the Route? Thats a separate
question, and one that requires a lot of discussion. I think you would find
its application specific, and that there are numerous scenarios, each of
which is valid.

-Jonathan R.
---

---

From: "Arnoud van Wijk (ETM)" <[email-masked]>
Date: Wed, 27 Sep 2000 13:16:30 +0200

When I replied in the previous postings, I had a different thing in my mind. Now I see what the "problem" is.

I agree with Simon that only the client and the home outbound server should understand the request.
I am not so eager to have another URL parameter.

I think that the key lies indeed with the user preferences. When a UA registers at a registrar, it will also do this at the home registrar. The UA can then get the user preferences as mentioned previously from the home registrar. And one of the options is then the home outbound server into the SIP request routing. And the UA client can insert the home outbound proxy into the route header.

To prevent that certain settings are erased from a certain UAC in a visiting domain (like outbound server from the visiting domain itself due firewall and other network related settings etc). The UAC should work at 2 levels. First level is domain specific settings (which could be sent to the UAC upon logging into the domain itself at the same time when the IP is assigned etc) and the second level is via the user preferences obtained from the home registrar upon REGISTERING the UAC.
The UAC should be intelligent enough to place any routing information after the domain specific routing info).

The job is then done by the SIP clients. I do realise that this has to work for simple SIP clients as well for the superdeluxe SIP clients, though the latter should easily support all options.

What do you think?

Arnoud

_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
ABACUS Lab
Research & Development
Fax: +31-161 247569
_______________________________________________________________

-----Original Message-----
From: Simon Barber [mailto:[email-masked]]
Sent: woensdag 27 sep 2000 6:19
To: Jo Hornsby; Henning Schulzrinne
Cc: Hisham Khartabil (LMF); [email-masked]; Jonathan Rosenberg
Subject: RE: [SIP] Outbound call routing

How would a current implementation of a proxy server handle this new URL
parameter (route).

Would the parameter be ignored by current proxies, or would the request be
rejected?

If current proxies would ignore the route, perhaps it would be better to put
the home outbound server (the destination we wish to loose route through) as
the requestURI (so current implementations send the request in the right
direction), and the final destination in the route parameter. This way only
the client, and the home outbound server need know about the new parameter.

Simon Barber.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jo Hornsby
> Sent: Monday, September 18, 2000 3:02 AM
> To: Henning Schulzrinne; Simon Barber
> Cc: Hisham Khartabil; [email-masked]; Jonathan Rosenberg
> It's a nice idea, but I would guess that is going to be difficult
> in a lot of situations.
>
> I think the real problem lies with the fact that if a UA has an
> Outbound Proxy configured, then in a lot of cases, this is going
> to be for a very good reason (Firewall, or whatever).  Therefore,
> if I happen to be working on some remote part of this Planet, and
> thus using "somebody else's" UA, I'm not necessarily going to be
> able to just reconfigure it to use my "home" proxy.
>
> As Jonathan pointed out, one could utilise Route to achieve this
> goal, but there is no guarantee that a proxy will honour this,
> since it will previously have been unaware of this "call".
>
> I've always wondered if it might be useful to have SIP URLs
> slightly more expressive, so that routing can be slightly richer
> without any information being lost as it occurs.  And this seems
> as good a time as any to bring this point up.
>
> What I'm proposing, is a new SIP URL parameter, let's say: "proxy".
> The value of the "proxy" parameter is a `hostport'.
>
> This means that I can now roam to somebody else's domain, and
> send out an INVITE a la:
>     INVITE sip:[email-masked];proxy=sip.ubiquity.net SIP/2.0
>     ...
> In which case the INVITE is routed through the UAs normal
> outbound proxy, as needed, and "sip.ubiquity.net" supercedes
> any normal routing decisions.
>
> This would seem to satisfy the "always use this proxy" requirement,
> whether an outbound proxy is in the loop or not.
>
> Futhermore, it helps with the following scenario...
>
> Say my public SIP Address is sip:[email-masked], but today I'm
> going to be working at buffy.com, thus I would like all my calls
> to be routed through to buffy.com.  I plug in my laptop, and
> get allocated some private intranet IP via DHCP.  I would like
> to send a REGISTER to my proxy at ubiquity.net, but my IP is
> not globally routable, so the Contact address my UA deduces is
> useless; however, it is trivial for me to multicast a REGISTER
> locally for sip:[email-masked].
>
> So how does the proxy serving ubiquity.net know to route messages
> to buffy.com?  Well, I can think of three solutions:
>  1) I send a REGISTER to ubiquity.net with my non-globally-routable
>     IP in the Contact, and some proxy at buffy.com rewrites the
>     Contact (and notes where I am for subsequent routing).
>  2) I have some sort of temporary account set up at buffy.com
>     by the Systems Administrator, say "sip:[email-masked]".
>     The necessary registrations are then done at both ubiquity.net
>     and buffy.com .
>  3) I register my Contact at ubiquity.net as
>     sip:[email-masked];proxy=buffy.com
>
> I prefer 3), since maximum information is retained and very little
> messing around is required (i.e., we don't require any bastardisation
> of the message, nor extra staff).
>
> But in the end, I'm just bouncing this around, to see what people
> think.  Routing is already very flexible, so this might be only
> really useful for the constant threat of firewall, in which case
> other, probably rewriting-based, solutions are probably preferable
> (since they're probably already going to have to be in place).
>
> Thoughts?
>
> Cheers,
>
>
>  - Jo.
>
>
>