comments inline... On Mon, Apr 2, 2012 at 10:28 PM, Paul Kyzivat <[email protected]> wrote:
> On 4/2/12 11:55 AM, Nataraju A.B wrote: > > 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). > > Not sure I understand, and if I do I disagree. [ABN] The received **responses** for the INVITE will always carry the same cseq as that of the original INVITE. Hence there is no issue, if we use that cseq for the cloned dialog. > > The cseq values sent in opposite directions on a dialog are > *independent* of one another. The starting value in each direction is > supposed to be a random number in range [0,2^31-1]. > > Of necessity these need to be managed independently for each dialog, > though the the initial value from the UAC will be the same for all > dialogs resulting from the forking of an initial dialog establishing > request. > [ABN] I second this statement. > > Thanks, > Paul > > > 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 > >> > > > > > > > > _______________________________________________ > 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
