Subject: RE: [SIP] Outbound call routing

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Sep 2000 22:28:46 -0400

I agree with Jon on all counts.

Seems like general consensus that Route would be the right mechanism here,
no?

-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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 25, 2000 6:46 PM
> To: [email-masked]
> Subject: RE: [SIP] Outbound call routing
> 
> 
> 
> 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
> 

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 27 Sep 2000 15:42:43 +0100

> Seems like general consensus that Route would be the right mechanism
> here, no?

The only problem I can see is where there is some need to end up
at a UA on a specific port.

For instance, I want to contact: sip:[email-masked]:8000
and route through supersip.com, this means I would form the Route
<sip:[email-masked]:8000;maddr=supersip.com>
Normal processing rules would have a proxy try and resolve
supersip.com using A records, and contact it on port 8000; this
probably isn't going to work.

Thoughts?

 - Jo.