Subject: RE: [SIP] Outbound call routing

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Sep 2000 11:21:20 -0400

> -----Original Message-----
> From: Simon Barber [mailto:[email-masked]]
> Sent: Thursday, September 14, 2000 6:35 AM
> To: [email-masked]
> Subject: [SIP] Outbound call routing
> 
> 
> This question may be due to my lack of understanding of 
> request routing in
> SIP - if so please excuse me!
> 
> Is it possible for a registration server to reply to a 
> registration request,
> and insist that all future outbound requests be routed to a 
> certain proxy?

No.

> 
> For instance, I want to implement a service that logs all my 
> outgoing calls.
> 
> To implement this service I must be able to monitor all outgoing call
> requests. If I am always at home, I will be using my usual 
> outbound proxy,
> and this can implement the service. The problem occurs if I 
> am away from
> home - using a SIP client in another network. This SIP client 
> will use it's
> local outbound proxy, and hence requests will not pass 
> through my outbound
> proxy.

This has come up as a subject of discussion a few times, primarily with
wireless.

If you, as a client, wish to force a request to route through your normal
proxy, you can do so by inserting a Route header into the request, even
though you have not previously gotten a record-route. This is most
definitely a hack; I am not certain it will be completely interoperable
since most proxies expect to see Route only if they previously
record-routed.

-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: "Simon Barber" <[email-masked]>
Date: Thu, 14 Sep 2000 12:46:41 -0700

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.

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.

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

Simon

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 8:21 AM
To: 'Simon Barber'; [email-masked]'
Subject: RE: [SIP] Outbound call routing

No.

-Jonathan R.
---

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 15 Sep 2000 09:50:39 +0300

I think that a user initiating a transaction and not having to go half way
across the world through his/her proxy is a feature, not a disadvantage.  If
you require a special service, then you need a special client (eg:  a
configureable client that allows you to specify the outbound proxy).

Regards,
Hisham

---

From: "Simon Barber" <[email-masked]>
Date: Fri, 15 Sep 2000 18:21:36 -0700

I am not proposing that the user initiating a transaction have to go half
way across the world, only that when the user registers the registration
server can specify that all transactions be routed through a home proxy, if
necessary. This way the transactions will be only be routed via the home
server if the user has services that require this routing.

Simon

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 11:51 PM
To: Simon Barber
Cc: [email-masked]; Jonathan Rosenberg
Subject: Re: [SIP] Outbound call routing

Regards,
Hisham

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Sep 2000 21:27:48 -0400

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.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 18 Sep 2000 11:02:29 +0100

> useful feature to have, as one may want to make this feature

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.

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 18 Sep 2000 12:50:23 +0200

> any normal routing decisions.

So this is another way of doing source-routing.  I would have thought
that if we really want to address this issue a better way would be to
make sure Route: works even for initial requests. As far as I can tell
that would be no more and no less backwards compatible than what you're
suggesting, but it would use the existing mechanism, and it might even
work with some existing implementations.

>     sip:[email-masked];proxy=buffy.com

Could be done by registering
sip:[email-masked]?Route=<sip:[email-masked]> (suitably URL escaped)

--
Anders Kristensen

---

From: Sean Olson <[email-masked]>
Date: Mon, 18 Sep 2000 12:56:13 +0200

> any normal routing decisions.

Why not use a Route: header in the headers portion of the SIP URI?
The outbound proxy can then decided whether or not to honor the 
Route:. This also generalizes to multiple proxies very nicely.

There are probably encoding issues with embedding a Route: in the URI
that I have not thought about yet, but this seems to work.

--
Sean Olson <[email-masked]>

---

From: "Simon Barber" <[email-masked]>
Date: Tue, 26 Sep 2000 21:18:48 -0700

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 27 Sep 2000 16:03:57 +0100

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

I would guess that most proxies today would ignore a Route header
embedded in a SIP URL.

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

I would think it be unlikely that a current proxy would reject a
request as a result, but you never know.

> 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

Ummm...no, this won't work, since the proxy will obey the Route
header (and thus ignore the Request-URI).

There is no problem here, however; the client just whacks an
extra Route that represents the "home outbound server" in before
the final destination Route (and so on).

 - Jo.