Subject: [Sip] Constructing the branch parameter at stateless proxies

From: Robert Sparks <[email-masked]>
Date: 03 Dec 2002 10:35:01 -0600

This list has seen a couple of requests to clarify the language in
RFC 3261 concerning how a stateless proxy creates a branch identifier.

The current text requires uniqueness, dependency on route decision
affecting parameters and care to be sure that those parameters are
retransmission invariant. It goes on to recommend a hash over a
set of fields (this set has been the subject of the requests for
clarification).

I think there's a much simpler solution. The purpose of this 
branch parameter is to act as a transaction identifier. Who
cares about this identifier? Only the stateful elements at
each end of the transaction. Any stateless proxies between
these elements don't use that identifier in any of their
decisions, so I assert that it is not useful to change it
as it crosses the stateless proxy.

I propose, then, that a stateless proxy simply copy
the branch parameter from the topmost Via header field
value it receives into the Via header field value it adds
to the request. 

I don't believe it matters that this parameter contain the
magic cookie. If it doesn't, the next stateful hop will use
the 2543-style transaction identifiers provided by the sending
stateful element. The stateless elements are by definition
transaction transparent.

So - can anyone construct a scenario where this doesn't 
function correctly? If not, we can remove several convoluted
paragraphs from the spec and replace them with a very simple
couple of sentences.

RjS

_______________________________________________
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: Anders Kristensen <[email-masked]>
Date: Wed, 04 Dec 2002 10:54:02 -0500

Hi Robert,

Sounds like a very good idea. One special case to consider is what 
happens if the request spirals back to the sending proxy (which 
presumably is stateful) -- either directly from the stateless proxy or 
via a number of other stateless proxies.  The stateful proxy in this 
case will have a server transaction and a client transaction with the 
same id, which might confuse some implementations.

This can be addressed simply by appending a fixed string to the branch 
value at each stateless proxy doing this trick, e.g. a single character. 
This guarantees the uniqueness properties required by rfc 3261, which 
seems desirable.

Anders

---

From: Robert Sparks <[email-masked]>
Date: 04 Dec 2002 10:05:36 -0600

> same id, which might confuse some implementations.

This is no different from the same proxy spiraling directly to itself
is it?

> This guarantees the uniqueness properties required by rfc 3261, which 

There are several things we could do here - append the count of present
via header fields for example to make sure you get different values as
you spiral through the stateless elements, etc. I don't think any of
this is necessary though - the stateless elements are supposed to be
transaction invisible. If they _can_ do something that botches the
transaction, we've got a weak spot in the protocol. I propose that
preserving the transaction identifier provided by the stateful element
is exactly the right thing to do, and that any mucking with it brings
nothing good to the table, and has the potential to bring harm.

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 04 Dec 2002 11:11:54 -0500

> This is no different from the same proxy spiraling directly to itself

Well, it's different in that it is NOT spiraling directly to itself and 
so is currently guaranteed to see a different branch ID in a spiralled 
request. It may be the case that noone depends on this but who knows?

> nothing good to the table, and has the potential to bring harm.

Like what?

Anders

---

From: Robert Sparks <[email-masked]>
Date: 04 Dec 2002 10:33:50 -0600

> request. It may be the case that noone depends on this but who knows?

Ok - so an implementation _may_ have gone to some effort to ensure
that it wasn't sending a message to itself and is counting on not
seeing the same transaction identifier come back to it. Not a choice
I would recommend, but I can see how someone might have made it.

We could avoid this with the suffix mechanism you suggest, or we
could add an admonishment to the spec to tell systems to be prepared
to have their transaction ID come back. I'd rather do the second.

> > nothing good to the table, and has the potential to bring harm.

Well, nothing earth-shattering. Right now, just an increased probability
that implementation error will lead to protocol failure. Its hard to get
this right, and we can greatly simplify it.

My growing distaste for what the stateless proxies are currently doing
comes from seeing it somewhat like a NAT. The transaction is really 
between the two stateful elements reguardless of how many stateless
elements lie between. Right now, the stateless elements are 
"translating" the transaction identifier as the message goes through.
We haven't identified anything in the protocol that breaks as long
as they do this consistently, but I haven't been able to identify any
benefit to the behavior. 

Now I'll go out on a limb. In the future, we might want as part of 
diagnostics, error recovery, or some similar function, to be able
to refer to the transaction by its identifier. It would be very
nice if that identifier were the same at the stateful elements on
each end of the transaction.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Dec 2002 02:25:35 -0500

inline.

> to have their transaction ID come back. I'd rather do the second.

I agree with Robert. Over time, our view of stateless proxies has 
changed a lot. Initially, we tried to treat them as the same as stateful 
ones, but it has become clear that there are important differences (for 
example, there are restrictions on the types of routing logic that are 
permitted).

One of the big changes in bis was the formal definition of a transaction 
  as being between a client transaction in one element and a server 
transaction in another (figure 4). Whats important is that the 
transaction is between transaction-stateful elements (by definition). It 
would seem very logical, then, that the transaction identifier (the 
branch ID) would be the same for all messages in this transaction. Since 
a stateless proxy doesn't muck with the transaction, just forwards 
messages, I would argue that the transaction ID should stay the same.

Indeed, the analogy is similar to the dialog identifiers in a stateful 
proxy; they too are not modified, since the proxy doesn't act as a 
termination point of the dialog. If it did (b2bua), it would need to 
modify those identifiers.

> as they do this consistently, but I haven't been able to identify any

I agree. I think its really legacy at this point.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Dec 2002 02:30:06 -0500

By the way, I am now tracking this in bugzilla:
http://www.sipwg.org/sipwg/show_bug.cgi?id=680

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 16 Dec 2002 12:54:56 +0200

Hi,

I was thiking of an scenario where we may have problems:

        +----->S1-----+
        |             v
UAC--->P1             P2--->UAS
        |             ^
        +----->S2-----+

The UAC sends an INVITE. P1 forks to S1 and S2 (both stateless). Both S1
and S2 will route the INVITE to P2 (stateful).

From P2 perspective, both INVITEs will have the same branch ID.
Therefore, P2 will treat the INVITE that arrives later as a
retransmission of the first INVITE.

P2 could be able to differentiate both INVITEs using the received Via
parameter or the port number in the Via header. But P2 is not supposed
to need to include these paramteres when calculating the transaction ID.

In this situation, everything will recover fine (P1 will CANCEL the
branch that does not return a final response), but it is, nevertheless,
an error situation.

Thoughts?

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
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: "Kowsalya Subramanian" <[email-masked]>
Date: Mon, 16 Dec 2002 17:03:36 +0530

Hi Gonzalo,

From my understanding of 16.5, forking will be done by P1 only if its the
edge proxy for the req-uri. The only way the forked request can reach other
proxies is through route headers. so the scenario under question can never
happen or am i missing something?.

Thanks
Kowsalya

----- Original Message -----
From: Gonzalo Camarillo <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
Cc: Robert Sparks <[email-masked]>; Anders Kristensen
<[email-masked]>; <[email-masked]>
Sent: Monday, December 16, 2002 4:24 PM
Subject: Re: [Sip] Constructing the branch parameter at stateless proxies

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 16 Dec 2002 14:11:28 +0200

Hi,

to give you a more concrete example:

P1: SIP proxy at ericsson.com
S1: Stateless proxy at cs.columbia.edu
S2: Stateless proxy at lmf.ericsson.se
P2: proxy at hut.fi, where I am giving a speech today.

You send an INVITE to [email-masked]. That proxy will fork the
INVITE to try to reach me at the university (cs.columbia.edu) or at my
office (lmf.ericsson.se). In both places, I have registered myself as
being in hut.fi. There request will reach me at hut.fi

Regards,

Gonzalo

---

From: Robert Sparks <[email-masked]>
Date: 16 Dec 2002 09:24:05 -0600

inline
> retransmission of the first INVITE.

P1 spawned two branches - why would it use the same branch ID
on each of them?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Dec 2002 22:01:15 -0500

inline.

> P1 spawned two branches - why would it use the same branch ID

Yes, I was going to ask that too. It should have used two different 
branch IDs.

Indeed, this is a good example of why not touching the branch ID works 
better. In order for P2 to properly disambiguate the transactions, it 
needs to have S1 and S2 BOTH correctly set them. GIven the ease with 
which this is done improperly, having S1 and S2 not change them reduces 
the chances of a problem.

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 17 Dec 2002 11:04:38 +0100

Do we really need to specify algorithms for branch computing?
Isn't it sufficient to mandate uniquiness within address in Via,
so that downstream elements can use it for transaction matching?
Implementers may decide whether their branch construction features
additional properties such as loop detection, transaction matching
ability and whatsoever.

If you still like to do that, I see a possible problem with
your specific proposal. The spec now promises the branch parameter
to be unique within space of address stated in Via. If a proxy
only reuses branch, it effectively merges two spaces, which may
result in a collision. That would prevent a downstream server
from recognizing two such requests as parts of distinct transactions.

-Jiri

ps -- regarding your motivation to have a globaly unique tid for
the purpose of diagnostics -- can't bottommost via make the job?