Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local Proxy?

From: "Dean Willis" <[email-masked]>
Date: Tue, 31 Jul 2001 16:00:27 -0500

UUCP used strict source routing with ! seperators. There's a multitude of
reasons we don't use that anymore, with the underyling dynamics of network
topology being the fundamenmtal reason.

IP netwworks use dynamic routing to accomodate for changes in network
topology in more-or-less real time without having to readdress the packets.

Strict source routing approaches like preloaded route headers break this
concept. I think it's one of the most annoying ideas I've ever heard of.

--
Dean

----- Original Message -----
From: "Bob Penfield" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; "'Dean Willis'"
<[email-masked]>; "Gonzalo Camarillo"
<[email-masked]>; "James Undery" <[email-masked]>
Cc: "Sudharsana krishnan P" <[email-masked]>; "Sipping
(E-mail)" <[email-masked]>
Sent: Tuesday, July 31, 2001 7:44 AM
Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local Proxy?

> Jonathan Rosenberg <[email-masked]> wrote:
> >
> > > -----Original Message-----
> > > From: Dean Willis [mailto:[email-masked]]
> > > Sent: Monday, July 30, 2001 3:04 PM
> > > To: Gonzalo Camarillo; James Undery
> > > Cc: Sudharsana krishnan P; Sipping (E-mail)
> > > Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local
> > > Proxy?
> > >
> > >
> > >
> > > Here's another point -- according to the developers I talked
> > > to, hacking the
> > > existing code to deal with %@ routing is easier than dealing
> > > with maddr,
> > > which seems to require fundamental parser changes as well as
> > > mods to the
> > > spec.
> >
> > One thing to note about the %@ routing is that its not for free.
Remember,
> > the interpretation of the LHS of the @ is at the discretion of the
server
> > handling the domain on the RHS. So, if you have:
> >
> > sip:[email-masked]
> >
> > This will only work if myhomeproxy.myhome.com knows to look for
> URL-encoded
> > user@hosts in the LHS of the @. Thats why, in general, constructing URLs
> is
> > not going to work, you need to make use of a URL that has been handed to
> you
> > in some way (business card, message, etc.).
> >
> > James Undery wrote:
> > > >
> > > > I would thus vote for something more along the lines of the maddr
> > > > suggestion, as what we're trying to accomplish is to give a
> > > routing "hint"
> > > > to the outbound proxy (a parameter thing) as opposed to changing the
> > > > destination (an address thing).
> > >
> > > The problem with maddr is how it gets treated, the outbound
> > > proxy has to remove
> > > the maddr (breaking it's normal behaviour) or the second
> > > proxy has to ignore the
> > > maddr.
> >
> > I think the normal behavior as defined in bis-03 onwards will support
the
> > maddr approach. The spec talks about using the maddr to route if its
"not
> an
> > interface you are listening on", and stripping it if it is. Normally,
> > interfaces are associated with IP addresses, not domains. But, if you
> simply
> > resolve the domain and then apply the logic, it will work. Probably the
> bis
> > spec itself needs to be clarified on the treatment of maddr with domain
> > name.
> >
> > James also writes:
> > > A third option is pre loaded Route header.
> > >
> > > e.g.
> > > INVITE sip:myhomeproxy.myhome.com SIP/2.0
> > > Route: sip:[email-masked]
> > >
> > > (IIRC the outbound proxy should not pop and use the route)
> >
> > I think the spec does say the outbound proxy will pop the route and use
> it.
> > Are you proposing alternate behavior?
> >
> > Dean wrote:
> > > However, the evils of strict source routing have long been
> > > known to the
> > > IETF, and that's why we use dynamic routing protocols. If
> > > there's any kind
> > > of change in network topology, one has to re-route, and that
> > > can be a messy
> > > process. This makes load-balancing, multi-path networks, and failure
> > > suvivability really complex.
> >
> > I'm really not sure I agree that the problems are identical. There is an
> > important distinction between the application layer routing and IP
> routing -
> > all elements are directly addressable. Strict source routing fails in IP
> > when a router doesn't have a "direct" connection to the next hop IP.
But,
> in
> > SIP, in principal a proxy can send a request to any URL and it will go
> there
> > (yeah, yeah, nats and firewalls and other evils...). Load balancing is
not
> a
> > problem in the SIP routing model because of things like SRV, and you'll
> get
> > similar failover capabilities. So, the problem is nowhere of the same
> scope.
> >
> >
> > That said, I do realize there are things like I-CSCFs and other beasties
> > that need to be traversed to get from A to B. As such, I do agree with
> you,
> > Dean, that the UA should not need to specify the route for these things
> > explicitly. Rather, the UA should be able to say "call A by somehow
> getting
> > this request to proxy P and going from there". In other words, the
caller
> is
> > asking for proxy P to take some user field and route it to some other
> place.
> > That, to me, argues for something like the % embedded approach.
> >
> > A few variants on that approach, which I think are documented in
Hennings
> > registration draft in part:
> >
> > 1. before making the call, the caller sends a REGISTER to establish
> > forwarding logic:
> >
> > REGISTER sip:myhomeproxy.com SIP/2.0
> > From: sip:[email-masked]
> > To: sip:[email-masked]
> > Contact: sip:[email-masked]
> >
> > It then sends an INVITE to sip:[email-masked] which will get
> > routed properly.
> >
> > 2. We can define a new user parameter. We have user=ip and user=phone.
> These
> > things are meant to define specify a particular semantics and syntax of
> the
> > user part. Well, thats what we're doing here. I'd generalize it, though,
> to
> > something like:
> >
> > sip:[email-masked];user=url
> >
> > which means that the LHS of the @ is interpreted as a URL to which the
> > request should be sent. This construct will allow arbitrarily deep
> nesting,
> > and also solve the issue I raise above, of how the proxy would know to
> > interpret the LHS in the way you want. It would also allow us to put tel
> > URLs and other things in the user part.
> >
> > My preference is solution 2.
> >
>
> OK, I'll stick my neck out.
>
> Whether you use a Route header or the % embedded approach, you are
> essentially asking the proxy to do what Dean compares to strict source
> routing. Given that some proxies will not deal with the LHS and even more
> will not understand "user=url", it seems to me that using the Route header
> is the cleanest and most likely to succeed. The likelyhood of success in
> routing to myhomeproxy.com is the same regardless of how the proxy
extracted
> the URL. I think using a Route header is the best. The other methods seem
a
> bit hackish to me. Why can't the UAC be up front about wanting to route to
> its home proxy?
>
>
>

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 06 Aug 2001 17:07:23 -0700

Rumor has it that 3GPP is planning to 'enhance' SIP by a header called
Path. It might be helpful if the 3GPP experts could indicate whether
this is the same problem.

Eric Burger wrote:
> 
> I guess the bang reminded me why I didn't want to hack the Request-URI in
> the first place.
> 
> I will readily concede that sip:[email-masked]
> will work if myproxy.com understands to parse the RHS and continue routing,
> and that sip:[email-masked];user=url will always
> work.
> 
> However...
> 
> We seem to really be mixing the meaning of a Request-URI.  I think that's
> why we're getting such push-back and counter-suggestions like preloading
> Route (won't work), maddr (works sometimes), etc.
>

Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 6 Aug 2001 16:55:50 -0400

However...

The thing I'd like to see explored is: will anything break by using the %@
(a.k.a. uucp bang!) Request-URI?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dean Willis
Sent: Tuesday, July 31, 2001 5:00 PM
To: Bob Penfield; Jonathan Rosenberg; Gonzalo Camarillo; James Undery
Cc: Sudharsana krishnan P; Sipping (E-mail)
Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local
Proxy?

--
Dean

----- Original Message -----
From: "Bob Penfield" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; "'Dean Willis'"

Remember,
server
the
"not
But,
not
caller
Hennings
extracted
a

---

From: "Neil Deason" <[email-masked]>
Date: Tue, 7 Aug 2001 08:51:44 +0100

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> Eric Burger
> Sent: 06 August 2001 21:56
> To: Sipping (E-mail)
> Subject: RE: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy?
>
> I will readily concede that 
> sip:[email-masked]
> and that 
> sip:[email-masked];user=url will always
> work.
> 
> However...
> 

Please elaborate on why pre-loaded Routes wont work.
maddr is broken when you want to add a different port
number. (Remember how record-routing didn't work pre 03
text because of the same reason).

> (a.k.a. uucp bang!) Request-URI?

Well a preloaded route could overwrite a cleverly 
constructed Request-URI.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

<snip>

---

From: [email-masked]
Date: Tue, 7 Aug 2001 05:00:05 -0500

Path: is a pre-loaded Route:. 
This works *for the 3GPP architecture* but it is
ugly. It is the same problem with the exception 
that the UA is not involved. The Path: header
(pre-loaded Route:) is handled entirely by the
proxies (local and non-local outbound proxies).
The UA only knows about the local outbound proxy
in the 3GPP architecture because the non-local
outbound proxy is effectively hidden from the 
end user.

cheers,
Sean Olson
Ericsson Inc.

>From: Henning Schulzrinne [mailto:[email-masked]]
>Sent: Monday, August 06, 2001 7:07 PM
>To: [email-masked]
>Cc: Sipping (E-mail)

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Aug 2001 01:17:00 +0300

Hello,

The problem with this thread is that we have mixed two things:

1) How to perform source routing
2) How to get services from a non-local proxy

Since 2 can be acomplish using 1, we have been discussing 1 all the
time. However, it would be good if in the 3GPP architecture 2 could be
acomplished without using 1.

In the 3GPP architecture the proxy providing services is the S-CSCF and
the UA only knows about his outbound proxy (P-CSCF).

A way to resolve their problem without using source routing would be to
make an extra querry to the HSS (a location server), for instance.

I do not know which of all these issues we want to discuss tomorrow, but
if, as Henning suggested, some 3GPP people could attend it would be a
very useful discussion.

Best regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 9 Aug 2001 08:27:03 -0500

Yep. Same problem.

In the current 3GPP work, a Path: header is used to accumulate route
information duriing REGISTER. It's sort of like record-routing REGISTER.

The resultant route information is stored, with on the phone or its default
proxy (I've heard conflicting reports here), and is inserted into Route:
headers on appropriate messages emitted by the node that stored the PATH.

This has the effect of source-routing all mobile-originated INVITEs through
exactly the same route that was traversed by REGISTER.

My feeling is that this is an awfully heavy and restrictive technique to
apply in order to get outbound services from a non-local proxy. It induces
many side-effects, such as requiring a registration in order to place calls.

3GPP has carried this even further by assuming that since REGISTERS are
authenticated and the signaling channel may be integrity protected at layer
2 that there is no need to perform authentication of INVITES, but that's
another can of worms.

--
Dean