Subject: RE: [SIP] Outbound call routing

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

I'm asking for a bit more than that.

The big problem is that the user may be roaming away from his home network,
and be logged in to a SIP phone not only outside of the firewall of his home
network, but also behind the firewall of a foreign network. Because of this
second firewall all SIP requests have to be routed through the local SIP
proxy to get to the outside world. However the user would also like his
requests to be routed through a proxy server from his home domain - so his
services can be provided. This requires that the SIP request have some
routing at the SIP protocol layer, not just the internetwork layer.

More simply - any of the user's home proxy servers may not be directly
reachable from the client, if the user is behind a foreign firewall. Hence
simply passing an IP address back in the register reply that the client
should send future requests to is not sufficient. We must provide a
mechanism whereby the SIP network can transport the requests to a server in
the user's home domain.

Simon

-----Original Message-----
From: Wayne Cutler [mailto:[email-masked]]
Sent: Friday, September 15, 2000 2:09 AM
To: Jonathan Rosenberg
Cc: 'Simon Barber'; 'sip
Subject: RE: [SIP] Outbound call routing

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 - e.g. the GK may be
composed
of several physical platforms and the allocation may be done on the basis of
dynamicaly sharing work/load amongst the platforms and therefore
avoiding/minimising pre-provisioning.

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: Howard Hart <[email-masked]>
Date: Mon, 18 Sep 2000 08:55:02 -0700

I won't speak for the second part, but the first part could probably be
addressed with a new DNS SRV record, say "sipoutbound". The roaming user would
do a SRV lookup on his new, DHCP-derived local domain, and if "sipoutbound"
exists, use that as the first hop.

Howard Hart
ipDialog, Inc.

> requests. Such a capability would be useful, I believe.

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

---

From: "Simon Barber" <[email-masked]>
Date: Thu, 21 Sep 2000 14:49:06 -0700

I'm not quite sure if this is what you mean, but I do see a possible
solution to the problem:

Currently SIP has a mechanism for routing outbound requests via a local
proxy - to solve the problem of routing through firewalls, or other network
partitions. This is either a manually configured outbound proxy (just like
HTTP requests, or first hop SMTP) or configured via DHCP.

This first local hop must be maintained.

When a SIP message is first sent out from a UAC the requestURI could be set
to the contents of the DNS SRV record "sipoutbound". When the INVITE reaches
the user's outbound server, then the request URI would be set to the
contents of the to: header. This assumes that the UA always wants the
request routed to the to: header. Is this always true? This also changes the
handling of the to: header. It is now not interpreted by the proxy servers
between the terminal and the user's outbound server. This means that local
semantics will not be applied. I guess sometimes this is good, sometimes
bad!

The closest system in the real world to current SIP outbound routing is
outbound routing of calls from a roaming GSM subscriber. This routing has
been a big barrier to deployment of roaming pre-pay on GSM, since outbound
calls are routed out without the knowledge of the user's home network, it is
not possible to control outbound calling according to a billing function.
One aspect that is both an advantage and a disadvantage is that the number
dialled is interpreted in the local network, hence local numbers can be
dialled without codes. It does mean, however that the user's numbers from
their home network (recorded in their phone book) are wrong, and the user
must apply some codes to dial. Of course this is probably irrelevant for the
future vision of SIP, where the identifier is the same as an e-mail address
and globally significant. Interpretation of tel: urls remains an open
question though.

Using the SRV record has the advantage that the UA does not need to be
registered before outbound calling will work correctly. I see this
decoupling of outbound and inbound calling as an important advantage.

Simon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 18, 2000 8:55 AM
To: Simon Barber
Cc: 'Sip@Lists. Bell-Labs. Com'
Subject: Re: [SIP] Outbound call routing

I won't speak for the second part, but the first part could probably be
addressed with a new DNS SRV record, say "sipoutbound". The roaming user
would
do a SRV lookup on his new, DHCP-derived local domain, and if "sipoutbound"
exists, use that as the first hop.

Howard Hart
ipDialog, Inc.

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 22 Sep 2000 09:10:57 +0300

> semantics will not be applied. I guess sometimes this is good, sometimes

This is not quite right,  the UAC sets the request-uri to the address of the UAS
(which, in most cases, is the same as the URI in the to: header) and not the
out-bound proxy. The UAC is configured to send the request to that proxy.  The
out-bound proxy then performs the SRV lookup etc.  according to the request-uri
to find the UAS and routes the request.

regards,
Hisham

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 22 Sep 2000 11:34:39 +0100

> Currently SIP has a mechanism for routing outbound requests via a
> local proxy - to solve the problem of routing through firewalls, or
> other network partitions. This is either a manually configured
> outbound proxy (just like HTTP requests, or first hop SMTP) or
> configured via DHCP.
> 
> When a SIP message is first sent out from a UAC the requestURI could
> be set to the contents of the DNS SRV record "sipoutbound". When the
> INVITE reaches the user's outbound server, then the request URI
> would be set to the contents of the to: header. This assumes that
> the UA always wants the request routed to the to: header. Is this
> always true?

I would say very likely to be true, for an initial INVITE.  I
would stay away from "always", however. &:)

> This also changes the handling of the to: header. It is
> now not interpreted by the proxy servers between the terminal and
> the user's outbound server. This means that local semantics will not
> be applied. I guess sometimes this is good, sometimes bad!

This is slightly problematic; how does a proxy know that it is
supposed to be interpreting the To: instead of the Request-URI?
Although I guess it's only the first proxy (the "home" proxy?)
after the firewall prox(y|ies) that needs to know that To is
overriding.  Hmmm...

[...]
> Using the SRV record has the advantage that the UA does not need to
> be registered before outbound calling will work correctly. I see
> this decoupling of outbound and inbound calling as an important
> advantage.

Using the SRV record also has the disadvantage that someone has to
be responsible for configuring the record for a user's address,
and since the granularity is at a domain level, this isn't that
flexible (I might like to have my own "outbound" proxy, that I'd
written with my own funky features, for instance).

The notion of using source routing mentioned earlier in this
thread, by embedding a Route header, as Anders and Sean suggested,
would seem to solve all of these problems, and it reuses existing
syntax quite nicely.  Plus -- as Sean pointed out -- it generalises
to multiple proxies; not to mention the possibilities with implying
other headers (State perhaps?).

Do you forsee any problems with this approach?

Cheers,

 - Jo.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 22 Sep 2000 15:57:57 -0400 (EDT)

> > the UA always wants the request routed to the to: header. Is this

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-isp.example'.
The local proxy server does whatever magic it needs to do, and then sends
the request, with the URI 'sip:[email-masked]', to the machine
'outbound-services.home-isp.example'.

How that maddr is provisioned is a separate issue; it could be statically
configured in the UA, or specified in the registration response like Henning
suggested.

I believe that under a strict reading of 2543bis this is already the defined
behavior of proxy servers, but it could be made a lot more explicit.  I
don't think there are currently any examples with an maddr in a Request-URI.

One thing to note is that the 'From' header of the outgoing request needs to
be correct (and, probably, authenticated) in order for the
'outbound-services' machine to be able to tell whose services to apply.
This means that the UA can't proxy other people's calls and expect to
receive its outbound services, but I don't think that's a huge restriction.

Note that this means that the UA can always choose *not* to use the
outbound-services server as a proxy, by not including an maddr parameter.
So you can't use this for billing and the like.  This is true in general in
an IP environment, though -- users see administrative restrictions as
damage, and route around them.

-- 
Jonathan Lennox
[email-masked]

---

From: "Simon Barber" <[email-masked]>
Date: Fri, 22 Sep 2000 17:48:23 -0700

> would stay away from "always", however. &:)

A valid argument. We should maintain the ability of the UAC to set
the requestURI of the invite to whatever it wants.

> written with my own funky features, for instance).

Hisham - Apologies, I have misunderstood your meaning for outbound server.
By outbound server I mean a server that is part of my domain, that all my
outbound requests will pass though (whether I am originating those requests
from part of the network within my domain or not).

I would suggest the sipoutbound SRV record is domain wide, not user
specific - just like the SIP SRV record for incoming calls. If you
want to use a specific server for your particular user, then you
should have the server that handles the domain direct the request to
a server that handles your particular user.

Using a domain wide SRV record means that it's all or nothing for that
domain, of course. This forces outbound requests to be routed like this for
all users. Using the response to REGISTER means this is configurable on a
user by user basis, but it does require the user be registered.

> other headers (State perhaps?).

Route does seem to be a neat solution. Excuse my ignorance, but why does it
have to be embedded in the requestURI?

Indeed I am not sure that we even need a separate SRV record for
outbound and inbound calls at all. Why not simply say that a Route:
header for initial requests should be set to the sip URL for the
user making the request (normally also the contents of the From:
header.).

This way all outbound requests pass through the same server that
handles the user's inbound calls. This should be completely compatible
with current procedures. It does tie the server which handles services
for outbound calls to the same server that handles services for inbound
calls, but is this a problem?

This also means that this form of outbound routing is used for all SIP
requests, irrespective of whether this is required for services or not.

In summary, 3 approaches:

1) configuration using REGISTER
- outbound routing can be controlled on a per specific registration basis

2) configuration using SRV record
- outbound routing can be controlled on a per domain basis

3) always route through user's home server
- no option not to route through user's home server

or

4) other method?

> Do you forsee any problems with this approach?

Seems very sensible!

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 Sep 2000 20:55:59 -0400

> behavior of proxy servers, but it could be made a lot more explicit. 

It already says that 'maddr overrides the host port' in the URL
description and in the first bullet item for the introduction.

 I
> don't think there are currently any examples with an maddr in a Request-URI.

Given that this is a somewhat specialized case, this probably belongs in
the call-flows document.

---

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

---

From: Howard Hart <[email-masked]>
Date: Mon, 25 Sep 2000 10:11:36 -0700

> calls, but is this a problem?

Depends on the installation size, and whether you want to guarantee outbound
calls with a dedicated server versus sharing cycles with a possibly overloaded
(or DDoS'ed) inbound server.

> - no option not to route through user's home server

Only possible issue I see for 1) is early deployments may only use remote
public Registrars that are outside local control and can't be preloaded with
Route: info on local outbound proxies. Of course, 2) has the same problem if
you don't own your local domain. 3) is always the fallback. 4) Someone
mentioned SIP DHCP extensions.

Howard Hart
ipDialog, Inc.