Subject: [Sip] Re: [Sipping] Flaw in loose routing?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 12:38:13 -0500

Moved to sip, and inline.

Peter Päppinghaus wrote:
> 
> Hi,
> 
> I have a few questions and comments on the bis-07 draft of SIP, mainly
> concerning the new loose routing mechanism.
> 
> 1) Unless I misunderstand something, I believe there is a flaw in the
> loose routing mechanism, leading to the consequence that a loose routing
> proxy may have to handle a request differently depending on whether the
> previous hop proxy is a strict or a loose router. Presumably this is an
> undesired effect.
> 
> I'll try to explain the problem using a modification of the Basic SIP
> Trapezoid example of section 16.11.1.1 in bis-07.
> 
> Assume the initial INVITE sent by U1 (cf. line 2983f.) has a preloaded
> Route header, and so the following request is forwarded from U1 to proxy
> P1.
> 
>         INVITE sip:[email-masked] SIP/2.0
>         Route: <sip:p1.example.com;lr>
>         Route: <sip:p2.domain.com;lr>
>         Contact: sip:[email-masked]
> 
> P1 then forwards the following request to proxy P2.
> 
>         INVITE sip:[email-masked] SIP/2.0
>         Route: <sip:p2.domain.com;lr>
>         Contact: sip:[email-masked]
>         Record-Route: <sip:p1.example.com;lr>
> 
> P2 processes this request according to sections 16.3, 16.4 and 16.5 of
> bis-07. Let us assume the request was successfully validated (section
> 16.3) and processing of section 16.4 follows. The processing of lines
> 2456-2484 effectively is a no-op in this case (P2 being responsible for
> domain.com). Now P2 runs a location service yielding several possible
> destinations to route the request to. But since there is a Route header
> present in the request, P2 is not allowed to fork, P2 MUST choose a
> single destination, place it into the Request-URI and continue according
> to section 16.5.

Good catch. The problem is that the route stripping needs to happen
fairly early on. We'll move the text to the right place. Thanks.

> In my opinion it seems that in the procedures of sections 16.4 and 16.5
> a loose routing proxy removes a topmost Route header addressing itself
> much too late. One can consider the processing of lines 2452-2474 as
> preprocessing. If checking and possibly removing the topmost Route
> header would be done immediately after this preprocessing stage, and
> before determining the destination set, then the problem outlined above
> would disappear.

Agreed.

> 
> Maybe I overlook some other problem being created by such an early
> removal of an own Route header.

Not that I can think of; maybe Robert has some thoughts but I think it
is just an oversight. Mostly because our thinking during most of the
writing was about requests that had route headers all the way through to
the end.

> 
> 2) Semantics and manipulation of Request-URI and Route headers are now
> clearly separated in SIP. In view of this, I find the title of section
> 16.4 ("Making a Routing Decision") very confusing.

Another excellent point. We should be consisting in our usage of
terminology, and the new split now introduces two things - discovery of
the destination, and figuring out the route to get there. 

 Determining the
> destination set (and accordingly updating the Request-URI) is what
> section 16.4 really is about. This confusion is enhanced by wording like
> "At this point, the proxy must decide where to forward the request."
> (line 2452), "next-hop location" (line 2455), "the element MAY use
> whatever mechanism it desires to determine where to send the request."
> (line 2486f.). Only after reading section 16.5, it became clear to me
> that the next-hop routing decision (namely possibly updating the Route
> header and forwarding the request according to the topmost Route header,
> if present) is the subject of section 16.5 and not of section 16.4.

We'll work through this text to make it more consistent.

THanks,
Jonathan R.

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

_______________________________________________
Sip mailing list  https://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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 13:58:44 -0500

Bob Penfield wrote:

> > They do say it, in bullet 5:
> >
> > In absence of a policy for forwarding a request through specific next
> > hops, the proxy MUST inspect the topmost Route header field value. If
> > that value indicates this proxy, the proxy MUST remove the
> > value from the copy (removing the Route header field if that was the
> > only value).
> 
> That's in 16.5, I mean the procedures in 16.4. It says that the proxy
> computes a set of destinations. But it also says if there is a route
> header,
> then is should only put one destination in that set (line 2487).
> Shouldn't
> it check the route header for its own address BEFORE it consults the
> location service to construct a set of destinations?

Yes. I agreed with Peter's comment in that regard, and the change will
be made.

-Jonathan R.