> Sip server does not need to fix the magic cookie generation > I think. Each notify send by the sip server has the same > via branch parameter. This is correct because it belongs > to the same subscribe dialog. Only Cseq is changed by the > sip server.
The generation of via branch with magic cookie is invalid because it is not unique. It sounds like you might be misinterpreting the requirement. They must be unique (not the same). RFC 3261 section 8.1.1.7: "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." > -----Original Message----- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Sunday, February 23, 2014 6:04 PM > To: Evangelos Filippatos; sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] Handling new non-Invite request during > Completed state > > > I have read rfc 3261, which according to 17.2.3 the branch parameter > > in the topmost Via header field of the request should be examined to > > match requests to transactions. Cseq should only be checked if the > > branch parameter in the top Via header s not present. > > Yes; the magic cookie matching rule applies when Via branch present and > starts with magic cookie. > > However if server completely relies upon the magic cookie rule, you hit > the garbage-in garbage-out situation that you are experiencing. > > <snip> > > > Is our SIP stack correctly handles the transaction? > > Yes; however if memory constraints allow better validation, you might > want to do the extra validation (as though magic cookie not present) to > accommodate better interoperability with non compliant devices (even if > the extra validation is considered to be non compliant). > > > > Do you think it seems like a race condition where further > > considerations should take place? > > It sounds like the notifier device needs to fix their Via branch > generation algorithm. > > -- > > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. > If you are not the intended recipient and have received this email in > error, please notify BroadSoft, Inc. immediately by replying to this > message, and destroy all copies of this message, along with any > attachment, prior to reading, distributing or copying it. > > Legal Disclaimer: This e-mail communication (and any attachment/s) is > confidential and contains proprietary information, some or all of which > may be legally privileged. It is intended solely for the use of the > individual or entity to which it is addressed. Access to this email by > anyone else is unauthorized. If you are not the intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it, is prohibited and may be unlawful. > > Please consider the environment before printing this e-mail > -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
