Neel, There is no specification that branch parameter MUST be a RFC 4122 GUID. In fact, RFC 3261 branch parameters are never an RFC 4122 GUID since they starts with the magic cookie "z9hG4bK". All that it is required that branch parameter MUST be globally unique. Applications can generate branch parameter in any manner they choose as long as they can grantee uniqueness. Furthermore, applications can add any application specific information to the branch parameter for instance by base64 encoding with URL safe alphabet and adding it to the end of globally unique branch value. Since it is guaranteed that Via branch parameter will return to proxy which generated it without changes (otherwise proxy will discard the message), storing application specific data in branch parameter provides for a standard compliant, guaranteed to work mechanism for storing such data. On the other hand, using a custom Via parameter is not standard compliant and might cause issues with some of the implementations, similar to what Alex have experienced.
Regards, _____________ Roman Shpount On Thu, Oct 6, 2016 at 7:45 AM, Neelakantan, Neel <nneelakan...@sonusnet.com > wrote: > Hi, > > If branch parameter got introduced in 3261 and this MUST be GUID. > > From 3261: > > The branch parameter value MUST be unique across space and time for > all requests sent by the UA. The exceptions to this rule are CANCEL > and ACK for non-2xx responses. As discussed below, a CANCEL request > will have the same value of the branch parameter as the request it > cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx > response will also have the same branch ID as the INVITE whose > response it acknowledges. > > The uniqueness property of the branch ID parameter, to facilitate > its use as a transaction ID, was not part of RFC 2543. > > Thanks, > Neel. > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto: > sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roman Shpount > Sent: Friday, September 30, 2016 10:19 PM > To: Alex Balashov > Cc: Sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Arbitrary Via parameters > > On Fri, Sep 30, 2016 at 5:38 PM, Alex Balashov <abalas...@evaristesys.com> > wrote: > > > On 09/30/2016 03:52 PM, Roman Shpount wrote: > > > > As far as Via is concerned, the better and standard compliant > >> practice is to encode any application specific data in VIA tag > >> parameter using some sort of proprietary encryption scheme. It is > >> guaranteed that Via tag will be returned to the proxy unmodified. > >> > > > > That might conflict with the requirement that the branch parameter be > > a GUID. > > > > It's less important for transaction-identifying GUIDs than for > > something like Call-ID, but still. > > > Via branch parameter is the transaction identifying parameter. Its format > and contents are implementation specific. There is no requirement for Via > branch (or SIP Call-ID for that matter) to be a GUID. All that is required > is that these parameters were unique. > > Regards, > _____________ > Roman Shpount > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
