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

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 6 Dec 2001 13:48:08 -0000

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

I do not disagree. &:)

But one caveat: I have never been fully sure that the branch
parameter is globally unique.  I think it can be deduced
that it is locally unique (i.e., within the Via hostport
space); but I'm failing to find text that nails down the
uniqueness globally.

 - Jo.

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 22:53:03 -0500

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Thursday, December 06, 2001 8:48 AM
> To: Jonathan Rosenberg; [email-masked]
> Subject: RE: [Sip] Open Issue #144: Branch ID + isCancel() as
> transaction ID
> 
> > Proposal:
> > 

Line 2188 sort of:

The proxy MUST include a "branch" parameter (Section 22.40) in the Via
header. When the path of 2188
a request through one or more forking proxies is graphed, the result is a
tree. The branch parameter 2189
identifies the "branch" each request was forwarded on. The branch parameter
value MUST be unique 2190
for each client transaction to which the request is forwarded. The precise
format of the branch.token 2191

I read this as "unique" scoped across all client transactions. One could
read it as unique across all client transactions for this incoming request.
We would need to additionally clarify that it means globally unique in order
for this to work.

-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: "Jo Hornsby" <[email-masked]>
Date: Mon, 10 Dec 2001 01:54:30 -0000

> read it as unique across all client transactions for this 

Ah. &:)  I was reading it as the latter.

> We would need to additionally clarify that it means globally 
> unique in order for this to work.

Agreed.

 - Jo.