Subject: Re: [SIP] transaction identification

From: "Sharath Rajasekar" <[email-masked]>
Date: Wed, 6 Sep 2000 17:10:36 -0700

Implementing loop detection in *stateless proxies*, is it essential to
compute the first part of branch id as a hash of To, From, CallID, Cseq in
addition to RequestURI and topmost Via.

Is it not sufficient to simply use the request URI and topmost Via alone for
the hash computation since the other values are not going to change anyway ?
I am not sure I understand why these fields are being used for the hash
computation even in the case of stateless proxies.

The second part of the branch could be computed as the hash of outgoing
request uri + some server instance ?

--Sharath R.

Sharath Rajasekar
Sylantro Systems Inc.
http://www.sylantro.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, September 04, 2000 8:41 PM
To: Henning Schulzrinne
Cc: Neil Deason; [email-masked]
Subject: Re: [SIP] transaction identification

Henning Schulzrinne wrote:
> 
> Neil Deason wrote:
> >
> 
> >
> > This possible fix was not introduced just for Via hiding.
> > The original discussion was about request retransmissions
> > on reverse spirals when record routing is in operation.
> >
> >   A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B
> >
> > A is originating UA, B is receiving UA, P1 & P2 are proxies
> > that Record-Route. B now sends a BYE. When the P2-P1 "portion"
> > of the BYE reaches P1, how will it distinguish that request
> > from the initial B-P1 as the spec stands? So the idea was to
> > change the definition of isomorphic requests to include a
> > globally unique branch param.
> 
> Added to the spec. The definition of the second branch parameter was
> always pretty vague, including "a sequence number", which presumably
> would do as long as the count is across all transactions.

Just to be clear here; the discussion to date of having a third
component that is globally unique is going to be folded into the second
component. That component was used for the actual "branch"
identification - if a proxy forks, and the response comes, for which
forked request is the response? So, a globally unique ID will be used
here instead of a simple sequence number that resets for each
transaction.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Steve Donovan" <[email-masked]>
Date: Thu, 7 Sep 2000 22:38:11 -0500

I'll admit that I have not been able to track this discussion in its
entirety and I applaud those that have been both able to keep up and to
understand the intricacies involved.

I also apologize as I am sure that I am asking for a repeat of what has
already been discussed.  However, I am very concerned that we are jumping
through hoops and inventing things that are making implementation of proxies
more complicated then they need to be.

Back in a previous life, I thought I understood the solution to spirals (I
think I called them legal proxy loops back then).  The solution was for the
proxy to use the request-uri as part of its identification of a request
transaction and to add a branch tag to the via.  The branch tag (which to
the protocol could be an opaque blob) helped the proxy map responses to the
appropriate call leg.  Using the request-uri was used to map future requests
(for call stateful proxies) to the original call leg.

I recall at the Ericsson bake-off, I believe, that a number of us discovered
that the wording had been added on building the route header that the
original uri in the record-route header was not to be used.  I did not
understand then, and still do not understand why that is necessary.  If that
rule is removed, then it seems to me that all of this discussion goes away
and the implementation of a proxy server becomes much more straight forward.

So, can someone please explain again why that wording is required.  In
addition, please point out what I am missing in my assertion that all of
these seemingly hundreds of messages on this topic would go away if this
change is removed from the bis draft.

As an alternative, if this is not removed from the bis draft, I would
suggest that we owe it to future developers of SIP proxies to write up an
informational rfc on how to handle loop detection and spirals.  There is too
much knowledge buried in the mailing list right now for anyone to be
expected to be successful in the implementation (without asking the same
questions all over again).

OK, go ahead and throw things at me, but remember, my motives are pure.  The
protocol needs to be easy to implement.  And given that this was added to
the bis draft to fix 2543, removing it or changing it should not suffer a
backwards compatibility test.

Steve

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Sharath Rajasekar
> Sent: Wednesday, September 06, 2000 7:11 PM
> To: [email-masked]

---

From: Neil Deason <[email-masked]>
Date: Fri, 08 Sep 2000 11:23:53 +0100

Good comments Steve, so nothing to throw here ;) 
I think a summary would be useful to make sure 
we haven't ended up chasing our own shadows. There 
was a lot mixed into the many postings over 3 threads 
but I take some encouragement if we we are getting 
down to the harder to find bugs. I can 
appreciate that it is not easy to follow for anyone 
not, or possibly just not yet, having to deal with 
this in an actual implementation. Hopefully it is
true that implementing the solution is a lot simpler 
than describing the problem. So grab a coffee and
I'll begin ...

Proposed Change:
Include the topmost Via branch param in the
definition of isomorphic requests and make
the Via branch param globally unique.
 
[Note the addition of the topmost Via itself
to the definition of isomorphic requests 
was not a direct result of this latest discussion 
but needed to be brought in to fix request merging.
 
Also whether all of the Via branch param or the 
Xth part needs to be unique is really an implementation 
decision. Being more precise will help new implementers
but should be no more than a MAY.]

The Problem:
Consider the following case where there is a legal 
loop and both proxies add themselves to the 
Record-Route.
                 R-R       R-R
	A -INV-> P1 -INV-> P2 -INV-> B

B now sends a BYE:

	A <-BYE- P1 <-BYE- P2 <-BYE- B

According to the way Route is constructed for 
a reverse request path, using the originating 
name-addr (Section 6.34.2), the Request-URI ends 
up the same across transmissions and
so this is incorrectly failed as an illegal loop.

As you say this wouldn't be a problem if 
original uri in the record-route header was used 
instead. But Jonathan pointed out that using the 
originating name-addr... 

" maintains the fundamental principle that the 
request URI indicates for whom the request is 
destined. By relying on Route headers to get the 
request there, even though the request URI says 
something completely difference, makes the 
operation of the protocol brittle. We have seen 
this at bakeoffs - loops often occur if any proxy 
has anything slightly wrong with their route 
processing."

[I would point out that you hope this is the case, 
because the port could be incorrect for the intended
recipient if sending UA copies a different port 
from the Record-Route into the Request URI 
in accordance with 6.34.2]

So the simplest proposed solution appeared to be
that a Proxy doesn't need to do loop detection 
if it's following a Route.

However there is a slight problem. Consider the 
following more complex scenario...
    R-R       R-R       R-R       R-R       R-R  
 A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> P2 -INV-> B

A is originating UA, B is receiving UA, P1 & P2 
are proxies that Record-Route. The loops in the 
above scenario are both 'legal' loops, i.e. 
Request-URI gets rewritten between proxies. 
B now sends a BYE.
                  
 A <-BYE- P1 <-BYE- P2 <-BYE- P1 <-BYE- P2 <-BYE- B
               (b)                 (a)       

How can P1 distinguish the BYE marked (a) from the
one marked (b) as non isomorphic requests?

Again according to the way Route is constructed for 
a reverse request path, using the originating 
name-addr (Section 6.34.2), the Request-URI ends 
up the same across transmissions. We are now not doing
loop detection but we still need to be able to 
distinguish a new request from a retransmission.

At this time the definition of isomorphic requests 
included same values for the Call-ID, To, From, CSeq 
Request-URI and topmost Via. So the proposal to fix 
this was to add a globally unique identifier to the
Via branch param.

Doing this has some other apparent benefits. 

It helps with general protocol robustness a proxy 
which detects a loop down the chain from where it 
actually happened, can use it to differentiate 
ACKs/CANCELs for the 1st/2nd time it saw the request. 

It also helped Proxies do loop detection with Via 
hiding more efficiently. However, there now appears 
to be a consensus to remove Via hiding completely. 

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

---

From: "Steve Donovan" <[email-masked]>
Date: Fri, 8 Sep 2000 16:16:25 -0500

Neil Deason wrote:
<snip>
> has anything slightly wrong with their route

Let me push on this one a little bit.  If the fundamental principle is to be
held for Route headers in requests from the callee to the caller then why is
that principle not also enforced for routes in requests going from the
caller to the callee?  If this is important then the same rule should be
applied for building the route in both directions and the uri in the contact
received in the 200 OK should be used for building the caller to callee
route.  Don't get me wrong, I don't think this should be done, I just don't
understand the value of the request URI fundamental principle.

I also don't understand how having broken proxies at bakeoffs makes the
protocol brittle.  It is also the case if proxies have anything wrong with
their via processing.  If the proxy is implemented correctly then using the
original uri's in the Record-Route should work just fine.  After all,
proxies need to be able to handle routes with the original request uris
correctly in the caller->callee direction.  Why should they not be able to
in the callee->caller direction?

My other question on the proposed solution is how can call stateful proxies
correlate requests with Route headers going in the callee->caller direction
with the correct call leg/transaction without the original request-uri?

Steve

---

From: Neil Deason <[email-masked]>
Date: Mon, 11 Sep 2000 12:04:00 +0100

> with the correct call leg/transaction without the original request-uri?

Can you elaborate on this please. As I see things call leg, 
transactions and call state are 3 slightly different things.
The Request-URI is only important in the transasction ID. In 
this example the new request would be part of a new transaction. 
It is also part of an existing call leg as defined by the 
Call-ID, To and From headers (user, hostport and tag parts). 
If it needs to a Proxy can maintain call state by keeping track 
of all requests and responses over this call leg.

Cheers,
Neil.

---

From: "Steve Donovan" <[email-masked]>
Date: Mon, 18 Sep 2000 14:03:04 -0400

> of all requests and responses over this call leg.

Neil, you are correct, I was mixing issues on this.  There was a related
discussion, I believe at the same bake-off, about the posibility of adding a
"state blob" to the record-route header and having that come back in the
request-uri of subsequent requests.

Sorry for mixing issues.

---

From: "Robert Sparks" <[email-masked]>
Date: Mon, 18 Sep 2000 13:38:05 -0500

The attached revision to sip-cc-transfer has been submitted to the
internet-drafts repository.

This revision addresses the following:

. Separated definition of the REFER method and headers from the definition
of its use to achieve transfer.
. Replaced the syntax of the Referred-By header to align with
sip-ietf-sip-guidelines.
. Added short forms of Refer-To and Referred-By as recommended by
sip-ietf-sip-guidelines.
. Allows REFERs outside the scope of an existing call-leg.

I've tried to reflect most of the feedback received since the Pittsburg
meeting. Please
review - if I've missed something, let me know.

RjS