Hi, Thanks for reply. So for better interoperability (with proxies for which RFC is not clear about CSeq for forked leg) if UAC send request with higher CSeq (in below mention scenario CSeq 3) then call be always successful.
Please share your opinion. Regards, Ravi Kumar ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Worley, Dale R (Dale) [mailto:[email protected]] Sent: Monday, March 26, 2012 9:56 PM To: Ravi Kumar; 'harbhanu sahai'; 'Vinay V'; [email protected] Subject: RE: [Sip-implementors] Clarification regarding the Cseq to be used in mid dialog req on cloned leg. > From: Ravi Kumar [[email protected]] > > But in my opinion it should send request with CSeq 3. Because if some node > in network use CSeq of dialog on which clone response is received then above > implementation will be more flexible. > UAS will not have any impact because as per RFC 3261 this is not error > condition. True, a UAC (request sender) can choose to use a higher CSeq. But a UAS (request receiver) must not *require* that. However, I believe that your complaint is based on a conceptual error: Forking is an *inherent* part of SIP, and all devices (especially proxies and other "middle boxes") must be prepared to see multiple forks of a single request and must handle them correctly. Once you assume that all SIP elements will handle forked requests properly, then there is no need to worry about behavior that is "more flexible". Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
