Subject: [Sip] RE: [Sipping] Loose Routing Proposal

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 11:55:05 -0400

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 4:34 AM
> To: Dean Willis; [email-masked]
> Subject: RE: [Sipping] Loose Routing Proposal
> 
> 
> [Moved to SIP.  Hopefully this is the right thing todo.]
> 
> > I believe Jonathan R looked at the Route: header and determined that
> > there does not appear to be a reasonable way to do this and preserve
> > backward compatibility -- rather than ignoring the "loose" flag,
> > older proxies would probably choke the route.
> 
> I have to say that I'm still confused as to why we can't
> just say that Route is loose.  Neil has pointed out that
> the notion of DNS-incapable clients has already created
> a sortof precedent for this.  The only problem I've heard
> so far is that you lose the identity of the called party
> (because the Request-URI gets clobbered by some Route pop
> along the path); however, I fail to see why the proposal
> of adding the called party as the last Route entry will
> not work...?

I think that will probably solve that aspect of the problem.

There is one more worth discussing. In loose routing, the header is popped
at the receiver, in strict, at the sender. This can cause problems. Here's
the example.

A UAC wants to call [email-masked] through home.com. So, he sends an INVITE
like:

INVITE sip:[email-masked] SIP/2.0
Route: sip:home.com;loose=true
Route: sip:[email-masked];loose=true

He sends this to the local outbound proxy of his visited domain,
outbound1.visit.com. That one supports loose routing. Recognizing that its
not home.com, it proxies the invite to its outbound proxy,
outbound2.visit.com, which also supports loose routing. That forwards it to
foo.com. This one also supports loose, so it pops off home.com, and sees
[email-masked]. Now, it sends it to its outbound proxy, outbound1.foo.com. Now
here is the problem.

outbound1.foo.com doesn't support loose routing. So, it pops the top route,
puts it in the r-uri, and sends it there. This goes back to the foo.com
proxy, which now detects a loop, since it already saw a request with the
r-uri of foo.com.

Basically, you introduce the possibility of looping whenver you mix loose
and source routing, and have the r-uri equal to one of the loose routes
(which has to be the case anyway). Perhaps this is also fixable; if the
foo.com proxy includes a hash of the route headers in its branch-id
computation (which it probably should based on the bis-04 discussion on via
brnach id computation), the loop back around to foo.com will be detected as
a spiral. 

There may be other cases where this cannot be easily detected as a spiral; I
need to think about it.

Assuming we can nail that, it is my strong preference to keep this backwards
compatible. I know there are interop issues with route/rr since this has
evolved, but that is mostly because of the mix of incorrect implementations
along with the changing nature of this piece. If everyone implemented the
rfc2543 approach exactly as specified, you would find that what is
documented in bis 04 is totally backwards compatible. Juha's issue, for
example, of someone reversing the order of the routes, was never something
that was recommended or discussed, and is purely an implementation error on
their part. SHould we ditch backwards compatibility just because some people
have trouble implementing this stuff right? I don't think so.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 7 Sep 2001 17:21:28 +0100

> There is one more worth discussing. In loose routing, the header
> is popped at the receiver, in strict, at the sender. This can
> cause problems. Here's the example.

Hmmm....  This was not my understanding of the proposal.
I thought that if you used the Route:, you popped as
currently specified; however, obeying the Route: was
totally optional.

> Route: sip:[email-masked];loose=true

[And there would be no "loose" parameter because of
the omission of extension-params from Route: in 2543.]

> outbound1.visit.com. That one supports loose routing. Recognizing
> that its not home.com, it proxies the invite to its outbound proxy,
> foo.com.

Here's where I think I'm proposing different.  If
the outbound2.visit.com proxy supported loose routing,
it would know that "home.com" was the next important
stop, and thus be aiming for there.

> This one also supports loose, so it pops off home.com, and sees
> [email-masked]. Now, it sends it to its outbound proxy,
> outbound1.foo.com. Now here is the problem.

Argh.  I think I'm really misunderstanding this
example.  Why is "home.com" proxied now -- we
haven't even hit there yet.  Or was the "forward
to foo.com" a shouldhavebeen "forward to home.com"?

> outbound1.foo.com doesn't support loose routing. So, it pops the
> top route, puts it in the r-uri, and sends it there. This goes
> back to the foo.com proxy, which now detects a loop, since it
> already saw a request with the r-uri of foo.com.

Hmmm....  Okay.   So a long long long time ago, when
we were thrashing in the Sea of Record-Route Pain
(i.e., trying to define a backwardly-compatible
approach that worked in the reverse direction), you
[Jonathan] proposed that proxies did not do loop
detection when Route headers were present.

In fact, I would argue that this is still necessary.
If a Proxy spirals in an initial INVITE, and
Record-Route:s on both "parts" of a spiral.  Then if
the called party in this INVITE was 2543, any requests
in the reverse direction will look like loops to this
Proxy.

> have trouble implementing this stuff right? I don't think so.

Agreed. &:)

 - Jo.

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 7 Sep 2001 19:56:54 +0300

Jonathan Rosenberg writes:

 > SHould we ditch backwards compatibility just because some people

my point was that every sip proxy in anykind of production service needs
to be currently upgraded many times per year because of all kinds of
bugs and new features.  we are not in that stable state in the industry
yet, that backwards compatibility would be any real issue in proxies.
it may be an issue for UAs, because some of them are not supported
anymore.

-- juha