Ravi, I partially agree with your comments. If you consider the following scenario, it is better to select the local sequence based on the cseq of the received response than from one of the dialogs (d1 / d2).
Also there is no requirement (from 3261) to clone/copy the local sequence number from the existing dialog set. If we go according to your theory, then we have search through all the existing dialoigs and select the one with highest cseq's (may not be worth doing). Instead if we select the local seq based on the cseq of the received response (OR one with matching half dialog), then it would be simple and all of the entities (proxies / UA's) would work without any issue with cseq value INVITE (cseq:1)----> <--- 180 (100rel), cseq:1 Tag-1 PRACK (cseq:2) ---> Tag-1 <--- 200 -PRACK, cseq:2, Tag-1 <--- 183 (100rel), cseq:1 Tag-1 PRACK (cseq:3) ---> Tag-1 <--- 200 -PRACK, cseq:3, Tag-1 <--- 180 (100rel), cseq:1 Tag-2 PRACK (cseq:2) ---> Tag-2 <--- 200 -PRACK, Tag-2 <--- 180 (100rel), cseq:1 Tag-3 PRACK (cseq:2) ---> Tag-3 *** here cseq should be 3 or 4 ???? **** <--- 200 -PRACK, (cseq:2), Tag-3 Cseq:4 would not create problem for any entity, but is it worth searching across all dialogs to find the highest cseq number for an outgoing request. Even this may not be a problem with CSF (Call Stateful proxies) since each request is handled within the purview of a dialog, NOT session. Typical contents of a dialog include dialog creating method (INV / UPD / SUB) - SAME for all dialogs, hence can be copied from other dialogs Call-ID - SAME for all dialogs, hence can be copied from other dialogs Local tag - SAME for all dialogs, hence can be copied from other dialogs Local seq num - differ from dialog to dialog depends on the state and time of the dialog, hence **should not** clone from other dialogs remote tag - Always differ from dialog to dialog, hence should not clone from other dialogs remote seq - Always differ from dialog to dialog, hence should not clone from other dialogs My 2 cents.... Thanks, Nataraju A B On Tue, Mar 27, 2012 at 11:10 AM, Ravi Kumar <[email protected]> wrote: > 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 > -- Thanks, Nataraju A.B. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
