Subject: [Sip] Open Issue #144: Branch ID + isCancel() as transaction ID

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 22:48:36 -0500

Issue:

The computation of the transaction ID in current SIP is, well, challenging.
It is a combination of a bunch of header fields, and conditionally as well
(with or without tags). This requires fairly deep parsing of a number of
fields and is the source of much confusion, even for the co-authors of the
spec (I made numerous errors in the text while updating to bis-05)

Bis-05 has taken a big step forward with a rigorous definition of
transaction, which makes it clear that its a single "branch" in the tree of
requests formed when a UAC sends a request through a bunch of proxies. That
is, the To/From/CSeq/Call-ID identify the root of this tree, and the Via
branch + r-uri further identify each branch in the tree. Based on this, it
is natural to take the final step, and define the transaction ID for a
request/response MUCH more simply - it is the value of the branch ID in the
topmost via, with the small caveat that CANCEL has the same branch ID, but
its a different transaction. Thats needed for backwards compatibility.

Bis-05 has sufficient randomness requirements on the branch ID to satisfy
this definition. Only two things are missing. First, the UAC needs to insert
it also, and secondly, a proxy needs to know whether the previous hop used
the uniqueness properties specified in bis. The proposal would be to specify
in bis-05 that a client can insert the branch ID (and give reasons why its a
good thing). To deal with the compatibility issue, we further mandate that
all branch-IDs generated uniquely according to bis start with some small
magic cookie to identify them as unique. A proxy would extract the via, look
at the branch, and if it has this cookie, need not even look at the call-id,
to, from, or cseq in order to process the request. If, however, the branch
does not contain this cookie, it needs to do the full parse as defined in
bis right now.

We are so close to this final step, I believe it is worth taking. The costs
are small, its still optional - just an optimization - and we have full
interop. However, the benefits will be very good when you  have a lot of
deployed bis elements.

Proposal:

Allow for branch ID to be the transaction ID, by taking the steps described
above.

-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

_______________________________________________
Sip mailing list  http://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: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 06 Dec 2001 14:19:26 -0500

Makes sense, but since the request-response matching is done by the same
entity that inserted the branch-id, why the magic cookie? Wouldn't it
know whether it can do this?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Dec 2001 01:42:07 +0200

Hi,

> know whether it can do this?

The entity receiving this request can use the branch ID to match
retransmissions of a request with its server transaction without needing
to parse the whole message.

The same for matching CANCEL with the original request.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 7 Dec 2001 17:56:21 -0500

> Allow for branch ID to be the transaction ID, by taking the 

I like the simplification.  However using 
"branch" would definitely cause backward 
compatibility issues since it was not
previously required to be globally unique.
I guess a poll could be taken.

Alternatively a new parameter could be 
defined to indicate the global uniqueness 
of branch.

---

From: Vijay Gurbani <[email-masked]>
Date: Mon, 10 Dec 2001 12:35:46 -0600

> Issue:
[...]
> transaction, which makes it clear that its a single "branch" in the tree 
> of requests formed when a UAC sends a request through a bunch of proxies. 
> That is, the To/From/CSeq/Call-ID identify the root of this tree, and the 
> Via branch + r-uri further identify each branch in the tree. Based on 
> this, it is natural to take the final step, and define the transaction ID 
> for a request/response MUCH more simply - it is the value of the branch ID 
> in the topmost via, with the small caveat that CANCEL has the same branch 
> ID, but its a different transaction. 

Also that ACKs for non-2xx response must have the same branch ID as the
INVITE did.

[...]

> Proposal:
> 
> Allow for branch ID to be the transaction ID, by taking the steps 
> described above.

Fine.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

---

From: "REJANI DEVI S" <[email-masked]>
Date: Fri, 21 Dec 2001 17:18:36 +0530

[Rejani]
Wondering if there is a typo in bis 05; Sec 17.2.3 line 2768...

"The ACK request matches a transaction if the Request URI, From, Call-Id,
CSeq Method (not the number), and top Via header match those of the INVITE
request which created the transaction .."
Shouldn't it be "CSeq Number (not the method)".

Also, can you confirm if we are referring to only the CSeq Number part
in the branch id calculation?

thank you,
Rejani

Fine.

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 23:30:32 -0500

> Shouldn't it be "CSeq Number (not the method)".

Ooops!!!! Thats a BIG ONE. Thanks for catching that. I am shocked it got 
  through since I poured over that text for some time....

> in the branch id calculation?

Huh? The proposal for branch ID would involve the client simply 
selecting a random number using a random generator, or something, as a 
transaction ID. Anything so long as its globally unique. A stateless 
proxy needs to perform hashes to guarantee that the computation is 
consistent across requests in the transaction, and in that case, the 
hash could NOT include the cseq method, since that varies from INVITE, 
CANCEL, and ACK, yet the branch ID would need to be the same.

-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