Subject: RE: [SIP] Outbound call routing

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

Henning.

That is right. It is a broken idea..and quite unfriendly. :-)
I did not say that I agree with this idea (even that I did suggest it), but it illustrates that this seems to be the only way to route the SIP messages to P4.

Personally I think that the realistic solution will be that a visited network partner will do the services that is required for the roaming user (user A in this example). So, this would lead to trust between the home network and the visited network. 
(which is then a network operator issue, I believe that the AAAArch group is working on this interdomain work).

Arnoud

-----Original Message-----
From: Henning Schulzrinne [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: dinsdag 26 sep 2000 17:46
To: Arnoud van Wijk (ETM)
Cc: 'Simon Barber'; [email-masked]
Subject: Re: [SIP] Outbound call routing

"Arnoud van Wijk (ETM)" wrote:
>
> Hello Simon,
>
> Yes. I see the problem. I have been wrestling with similar architecture problems.
> Right now, nothing can force the SIP messages from User A to go through P3 and P4.
>
> I think that the solution will be in forcing the client of User A to use the registrar of the home domain of user A. And then have P4 add itself in the via header (route header).
> This means that P4 receives the location search request from user A when A places a call to B, and P4 will then use the registrar to find the definite location of user B. Then P4 will send the SIP message with the IP address of user B's UA (via P5). But before P4 sends the SIP message, it will add itself to the via header or route header. (I am in a hurry, sorry for the sketchy details).
>
> Bottomline is that a roaming user should never be allowed to use the current domain's location server/registrar. Always ONLY the homedomain's locator servers. And then it is just a matter of the insertion of the desired servers.

This is a fundamentally broken idea. This is not your grandpa's phone
network. Any notion of "forcing" clients to do anything is just not a
workable proposition in the Internet. In some circumstances, using the
current ("visited") registrar makes perfect sense, so I see no reason to
prohibit that.

>
> I will work this out in more detail if this is too unclear.
>

> 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.
>
> > -----Original Message-----
> > From: [email-masked]
> > [ mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of
> > [email-masked]
> > Sent: Monday, September 25, 2000 3: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] <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 <http://lists.bell-labs.com/mailman/listinfo/sip> 
> >
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip <http://lists.bell-labs.com/mailman/listinfo/sip> 

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

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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 28 Sep 2000 06:19:13 +0100

>I believe
>that the AAAArch group is working on this interdomain work

Theodore Havinis and I have submitted two drafts the the AAAarch
RG at the last IETF and they are still in the archive.
Any comments are welcome, since we would like to come to closure
on any open issues we may become aware of.
Please send us your comments.

Thanks, Henry

>[mailto:[email-masked]]On Behalf Of
>Arnoud van Wijk (ETM)
>Sent: Wednesday, September 27, 2000 8:25 AM
>To: 'Henning Schulzrinne'
>I did not say that I agree with this idea (even that I
>did suggest it), but it illustrates that this seems to
>be the only way to route the SIP messages to P4.
>
>Personally I think that the realistic solution will be
>that a visited network partner will do the services
>that is required for the roaming user (user A in this
>example). So, this would lead to trust between the
>home network and the visited network.
>(which is then a network operator issue, I believe
>that the AAAArch group is working on this interdomain work).
>
>Arnoud
>
>
>
>From: Henning Schulzrinne [
>mailto:[email-masked]
><mailto:[email-masked]> ]
>> I think that the solution will be in forcing the
>client of User A to use the registrar of the home
>domain of user A. And then have P4 add itself in the
>via header (route header).
>> This means that P4 receives the location search
>request from user A when A places a call to B, and P4
>will then use the registrar to find the definite
>location of user B. Then P4 will send the SIP message
>with the IP address of user B's UA (via P5). But
>before P4 sends the SIP message, it will add itself to
>the via header or route header. (I am in a hurry,
>sorry for the sketchy details).
>>
>> Bottomline is that a roaming user should never be
>allowed to use the current domain's location
>server/registrar. Always ONLY the homedomain's locator
>servers. And then it is just a matter of the insertion
>of the desired servers.
>
>> > [ mailto:[email-masked]
><mailto:[email-masked]> ]On Behalf Of
>> > [email-masked]
<http://lists.bell-labs.com/mailman/listinfo/sip>
<http://lists.bell-labs.com/mailman/listinfo/sip>

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

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 28 Sep 2000 06:48:32 +0100

Thanks, Henry