Subject: [Sipping] Flaw in loose routing?

From: Peter Päppinghaus <[email-masked]>
Date: Fri, 08 Feb 2002 14:34:48 +0100

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.

In a second scenario assume that proxy P1 is a strict router, U1 knows
this, and hence the initial INVITE sent from U1 to P1 looks as follows.

	INVITE sip:p1.example.com SIP/2.0
	Route: <sip:p2.domain.com;lr>
	Route: sip:[email-masked]
	Contact: sip:[email-masked]

P1 then forwards the following request to proxy P2.

	INVITE sip:p2.domain.com SIP/2.0
	Route: sip:[email-masked]
	Contact: sip:[email-masked]
	Record-Route: <sip:p1.example.com>

P2 after successfully validating the request follows the procedures of
section 16.4. By analysing the Request-URI, P2 discovers itself,
concludes that the previous hop was a strict router, and according to
lines 2456-2460 of bis-07, P2 modifies the request to the following
form.

	INVITE sip:[email-masked] SIP/2.0
	Contact: sip:[email-masked]
	Record-Route: <sip:p1.example.com>

Note that this request differs from the request received by P2 in the
first scenario by the missing Route header. Consequently P2 can now use
all the results of its location service and fork the request to several
destinations.

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.

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

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. 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.

Regards, Peter Paeppinghaus

-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1702 / Room 530
D - 81359 München     | Email:    [email-masked]

_______________________________________________
Sipping mailing list  https://www1.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: "Bob Penfield" <[email-masked]>
Date: Fri, 8 Feb 2002 11:00:38 -0500

The rules in 12.2.1.1 for populating the Route header indicate that the next
hop (first URI in the route set) is included in the Route header. However,
the procedures in 16.4 do not indicate that the receive proxy should check
to the top-most Route for its own address. If the top-most route is the
receiver's address, and it is the only Route, the receiver should be able to
put multiple entries in the destination set.

Is there a specific reason that the next hop (first URI in the route set) is
included in the Route header? If it must be there, then the receiver should
check the top-most route for it own address.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

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

> put multiple entries in the destination set.

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).

> check the top-most route for it own address.

The reason it stays is that the URI might contain state or other useful
information for the proxy. When it record-routes, it needs to get this
information back. Furthermore, only the element that created the route
header is ultimately qualified to know that its been reached. Thus,
remove on receive is much better.

-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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 8 Feb 2002 12:30:36 -0500

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
> value from the copy (removing the Route header field if that was the

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?

> remove on receive is much better.
OK. thanks.