Subject: RE: [SIP] Outbound call routing

From: [email-masked]
Date: Mon, 25 Sep 2000 16:46:25 -0600

It seems to me that this discussion is considering two issues - firstly, how
does a UA discover that it should use a particular PS as an outbound proxy,
and secondly, how does the UA signal the first-hop and final destinations of
the session in an INVITE. I think the second question can and should be
considered independently from the first, as it has bearing on other
architectures that require a very similar mechanism.

For example, consider a case in which a UA sends an INVITE that reaches a
local PS which then performs some sort of lookup and decides to forward the
call to a remote PS in another administrative domain. In order to reach the
remote PS, however, the local PS must send the call through a specific
firewall - perhaps there are several firewalls in the local administrative
domain, and one is a better way to reach the remote domain than the others.
When it has made its decision about which specific firewall is the right one
to traverse (which could have been discovered in any of a number of ways),
it must use some mechanism in its signaling to the firewall to describe the
first-hop server (the firewall itself) and the final destination (the remote
PS). I see no reason why we couldn't use the same signaling mechanism for
this that we would use in the UA-to-outbound-proxy case. It could be as
simple as just sending the INVITE to the first-hop server with a Request-URI
indicating the final destination. Or it could be, as has been suggested
here, an early Route header (an idea that's fairly attractive to me). I'm
not sure how this could be made compatible with DNS SRV records (for reasons
similar to those brought up by Jo@ubiquity earlier in the thread), but I
think SRV speaks more to the first issue than to the second anyway.

As a bit of an aside, I'd also like to suggest that a UA should not break
Record-Route regardless of any internally configured PS for outbound
requests. That is, the outbound proxy routing mechanism should be consulted
for new session requests only, not for requests associated with a
pre-existing session. When the UA is the -caller-, if the outbound proxy
chooses to add itself to the Record-Route, all future requests for the
session will cross the outbound proxy, so this shouldn't be broken. What
concerns me here are cases in which a UA is the -callee-, a Record-Route
exists for the call that does not include the outbound proxy (for whatever
reason), and the UA decides to a issue, say, a BYE, and is forced to break
Record-Route in order to send it to the outbound proxy. This could lead to
various problems. Ultimately, the inbound routing procedures should
guarantee that the outbound proxy has the opportunity to Record-Route itself
on the initial INVITE if this is appropriate; this shouldn't be
retroactively enforced by a UA.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Simon Barber [mailto:[email-masked]]
Sent: Friday, September 22, 2000 6:48 PM
To: Jo Hornsby; [email-masked]
Cc: 'Sip@Lists. Bell-Labs. Com'
Subject: RE: [SIP] Outbound call routing

> > 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. &:)

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

>
> > 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).

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.

>
> 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?).
>

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!

> Cheers,
>  - Jo.

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

---

From: "Simon Barber" <[email-masked]>
Date: Tue, 26 Sep 2000 02:14:27 -0700

Terminology:

I have certainly helped confuse the issue by using unclear terminology -
specifically outbound server. Perhaps a clearer name might help the
discussion. Perhaps "home outbound proxy" HOB. This is a proxy server under
control of the user's home administrative domain, through which outbound
calls may be routed, to allow services on outbound calls. How this routing
is controlled and achieved is the subject of the discussion.

The problem is:

If the user is using a UA in a part of the network within his administrative
domain it is possible to arrange for his outbound calls to have some
processing applied under the control of his administrative domain, but if
the user is roaming in a network under another administrative domain there
is no mechanism for his home administrative domain to have any knowledge or
control of his outbound calls within the SIP specification.

A diagram:
(switch to a fixed pitch font to view this)

........................        ....................
  Administrative       :        :Administrative
  domain X             :        :domain A, a.com
                       :        :
User A ----- P1 ----- P2 ----- P3 ----- P4 (HOB)
                       :     /  :
.......................:    /   :...................
  Administrative       :   /
  domain B, b.com      :  /
                       : /
         User B ----- P5
                       :
.......................:

User A wishes to call User B - but the call must pass through proxy P4, user
A's home outbound server, so that a service can be applied to the call.

Simon Barber.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Monday, September 25, 2000 3:46 PM
> To: [email-masked]