Subject: [SIP] Second branch parameter

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 30 Sep 2000 15:26:58 -0500

All:
 
Justifiably, the updated definition of an "isomorphic" request now 
includes the "second" branch parameter of the topmost Via header.  My 
problem is, how does one recognize the "second" branch parameter?  The 
bis draft says that "...The [branch] token MUST be unique for each 
distinct request.  The precise format of the token is implementation- 
defined.  In order to be able to both detect loops and associate 
responses with the corresponding requests, the parameter SHOULD consist 
of two parts separable by implementation." (Section 6.46, August bis)
 
Two questions: 
1) should the SHOULD be changed to a MUST?
2) should the bis specify what the separator token is?  If not, consider 
   a proxy that gets the following SIP request:
 
   INVITE sip:[email-masked]
   ...
   Via: SIP/2.0/UDP exp1.example.com;branch=a7c68feda6711e3efa55
   Via: SIP/2.0/UDP sip.ih.lucent.com  
 
   How does the proxy know which is the "second" branch parameter of 
   the topmost Via if it does not know what the separator is?  The 
   bis examples show branch parameters being delimited by a "." (at 
   least that's my interpretation of them).  However, I am not 
   comfortable parsing the branch token looking for a "." to figure 
   out what the "second" branch parameter is.
 
Am I missing something here, or is this a problem?
 
Thanks,

-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 3 Oct 2000 15:18:08 +0100

> Am I missing something here, or is this a problem?

I wouldn't perceive this as a problem, since the "second branch
parameter" is by definition part of the whole branch parameter,
thus you just use the whole branch parameter to distinguish.

I don't see why the text bothers mentioning the "second part"
explicitly, however; might as well just strike the word "second"
from the definition of an Isomorphic Request.

 - Jo.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Oct 2000 14:25:14 -0500

Henning/Jonathan:

Should we chop off the word "second" (vis-a-vis the branch parameter) 
from the definition of an isomorphic request, as Jo suggests?  I am for
it.  For all its worth, I was confused on the initial reading of the 
definition and reconciliation of how the branch parameter is 
constructed.

Comments?

Jo Hornsby wrote:
> [email-masked] wrote: 
> > includes the "second" branch parameter of the topmost Via header.  
> > My problem is, how does one recognize the "second" branch parameter? 
> > The bis draft says that "...The [branch] token MUST be unique for 
> > each distinct request.  The precise format of the token is 
> > implementation- defined.  In order to be able to both detect loops 
> > and associate responses with the corresponding requests, the 
> > parameter SHOULD consist of two parts separable by implementation." 
> > (Section 6.46, August bis)
> >
> > Two questions:
> > 2) should the bis specify what the separator token is?  If not, 
> >    consider a proxy that gets the following SIP request:
> >
> >    INVITE sip:[email-masked]
> >    ...

- vijay