Our sip client does the via branch validation. And it finds that valid. However, it does not look for the Cseq because it is a non-invite transaction. 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 issue, as I described before is that the new Notify, which has same branch parameter but increased Cseq, is send before our Timer J expires. So, our client does not check the Cseq, as the standard denotes for non-Invite transactions, and therefore thinks it is a retransmission replying with a 200OK having wrong CSeq. The Cseq of the first Notify and not the increased one. Best regards, _____________________________________________________________ Evangelos Filipppatos Software Engineer Direct Dial: +30 2610 390952 | Mobile: +30 6948306662 | Fax: +30 2610 390941 evangelos.filippa...@diasemi.com | www.diasemi.com Dialog Semiconductor, Kalavriton 54-56, 26 335, Patras, Greece _______________________________________________________________________ -----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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
