Subject: [Sip] Some Loose Routing feedback

From: [email-masked]
Date: Fri, 15 Feb 2002 19:35:08 +0200

Hi Editors of RFC2543bis!

I am really facinated, that the dilemma Loose Routing vs. Strict Routing could be solved even in a backwards compatible way. Great job! 

Studying the Loose Routing approach more deeply, I'd have the
following feeback:
(I am referring line numbers in the pdf version.)

- 2464: LaTeX mistake. I guess the \ref tag is miss-spelled.

- 2508-2509 and 2598-2600 might be somewhat confusing concerning
  in which situations it is allowed to push route headers

- The example in section 16.11.1.2 maybe should have the
  following configuration: p1;lr, p2;lr; p3; p4;lr

  Then it would show a difference in the processing, if after
  a strict router, there follow two loose routers.
  The processing descibed in 3048-3050, would have to deal with
  the case, if there is a Route header present in the outgoing
  request. This make the example more general.

  I propose to modify section 16.11.1.2 to something like the following:

---BEGIN---

16.11.1.2 Traversing a strict-routing proxy

   In this scanario, a dialog is established across four proxies, each
   of which adds Record-Route header field values.  The third proxy
   implements the strict-routing proceedures specified in RFC2543 and
   the bis drafts up to bis-05.

   U1->P1->P2->P3->P4>U2

   The INVITE arriving at U2 contains

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

   Which U2 responds to with a 200 OK. Later, U2 sends the following BYE
   to P4 based on the first Route header field value.

   BYE sip:[email-masked] SIP/2.0
   Route: <sip:p4.domain.com;lr>
   Route: <sip:p3.middle.com>
   Route: <sip:p2.looser.com;lr>
   Route: <sip:p1.example.com;lr>

   P4 is not responsible for the resource indicated in the Request-URI
   so it will leave it alone.  It notices that it is the element in the
   first Route header field value so it removes it.  It then prepares to
   send the request based on the now first Route header field value of
   sip:p3.middle.com, but it notices that this URI does not contain the
   lr parameter, so before sending, it reformats the request to be:

   BYE sip:p3.middle.com SIP/2.0
   Route: <sip:p2.looser.com;lr>
   Route: <sip:p1.example.com;lr>
   Route: <sip:[email-masked]>

   P3 is a strict router, so it forwards the following to P2:

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

   P2 sees the request-URI is a value it placed into a Record-Route
   header field, so before further processing, it rewrites the request
   to be

   BYE sip:[email-masked] SIP/2.0
   Route: <sip:p1.example.com;lr>

/*** I guess this is the intended behaviour ***/

   and sends the request to P1 based on the first Route header field value.

   P1 notices that it is the element in the first Route header field
   value so it removes it.
   Since P1 is not responsible for u1.example.com and there is no Route
   header field, P1 will forward the request to u1.example.com based on
   the Request-URI:

   BYE sip:[email-masked] SIP/2.0

---END---

  I hope there no mistakes...:-)

- I was thinking, whether a marking of the intended destination
  (e.g. ;fd ) makes the backwards compatibility mechanisms for
  loose/strict routing more robust. I am not yet sure, whether
  this really helps in anything. I was thinking about cases,
  where the final destination disappears due to a wrong proxy
  operation or is otherwise absent. Just something to think about...

That's all for now. Maybe I find some more things later...

Have fun!

cheers,
 Bernie

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Sun, 17 Feb 2002 22:06:20 -0600

responses inline

>   in which situations it is allowed to push route headers

This might be less confusing with the latest text that more clearly

distinguishes determining targets from determining the next hop in
the route. Retargetting (2508 now talks about adding URIs to a target
set based on the abstract location service) and pushing new routes
are independent.

> /*** I guess this is the intended behaviour ***/

Yes!

>   I hope there no mistakes...:-)

Nope - I'm making the suggested changes to the example.

>   operation or is otherwise absent. Just something to think about...

Well - there's a whole universe of ways that things can go bad if
some element starts violating protocol. In general, we don't address
these (because it truly is an unbounded problem).

Further, with the exception of dealing with strict-routing elements,
any time something puts a URI in the Request-URI, as far as
its concerned, it _is_ indicating the intended destination, so I
don't know where an ;fd would get introduced.

A variation of your suggestion is making URIs provided by endpoints
as the Contact in a dialog initiating request/response syntactically
special. I haven't found a compelling reason to do that yet.

> That's all for now. Maybe I find some more things later...

Thanks for the feedback.

---

From: "Jack W. Lix" <[email-masked]>
Date: Wed, 20 Feb 2002 09:32:42 -0800

<SNIP>

>>    the bis drafts up to bis-05.

<SNIP>

>Nope - I'm making the suggested changes to the example.

The last > should be an -> 
>>    U1->P1->P2->P3->P4>U2  Should Be
>>    U1->P1->P2->P3->P4->U2

Yes??

Jack