RFC 3261 section 8.2.6.2: "The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering."
RFC 3261 sections 8.1.1.7 and 17.2.3 discuss the Via branch magic cookie. If cookie present, the INVITE and OPTIONS must not have the same Via branch. If the cookie is not present, the INVITE and OPTIONS branches may be equal; if needed, see RFC 2543 for more details when no cookie. > -----Original Message----- > From: Gio Navarrette [mailto:brutw...@gmail.com] > Sent: Wednesday, September 11, 2013 12:01 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SIP In-Dialog OPTIONS Ping Branch IDs > > Hi all - > > I've encountered an oddity that I'm not too sure how exactly it should > be > handled and was hoping for a second opinion. Here's the scenario: > > PBX --INVITE;branch=A--> Service Provider > PBX <-- 100 Trying;branch=A -- Service Provider > PBX <-- 183 Session Progress;branch=A-- Service Provider > PBX --OPTIONS;branch=B--> Service Provider > PBX <--200-OK/OPTIONS;branch=B-- Service Provider > PBX <--200-OK/INVITE;branch=B-- Service Provider > > In short, during a call setup, an OPTIONS ping is generated, with the > same > From/To numbers as the INVITE, but with a different branch id. My > question > is should that branch-id be different on the OPTIONS ping out, or > should > that be the same as the INVITE? The service provider device is sending > the > 200/OK to the INVITE with the branch-id from the OPTIONS ping rather > than > the INVITE, which seems suspect. I've not been able to find a good lead > in > the RFCs yet. > > Any insights, thoughts, or leads are greatly appreciated. Thanks in > advance > for your time. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
