Hi Obviously Option 2 is appropriate // The Reason : Every UA must increment the numeric part of the CSeq for each new request send by it except for ACK and CANCEL // As all the requests as shown are in a single direction the CSeq must be incremented by the UA //
With thanks Neeraj Chowdhury On 2/15/06, Parveen Jain <[EMAIL PROTECTED]> wrote: > > Hi Matthew, > The CSeq counter should increase for each successive transaction in a > particular direction. The PRACK transaction(s) are separate > transactions. they just happen to take place smack in the middle of the > INVITE transaction. > So the option2 should be correct. > For more clarification follow these links: > > http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-February/00 > 0440.html > http://lists.cs.columbia.edu/pipermail/sip-implementors/2005-September/0 > 10195.html > > Hope this helps. > > Regards, > Parveen > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matthew > Gardiner > Sent: Tuesday, February 14, 2006 4:32 PM > To: Sip-Implementors > Subject: [Sip-implementors] Local CSeq number after PRACK > > Hi all, > > I apologise if this question has already been asked in the > sip-implementors > group. If so, I have either lost or missed the relevant mails and I > would be > happy if someone could point out the relevant links to me. > > However, the question is as follows: When a PRACK is sent to acknowledge > a > provisional response should the caller's local CSeq assume the value of > the > "outer" INVITE transaction or that of the PRACK transaction, regarding > the > CSeq to be referred to in future requests by the caller. > > For example consider a simple call, with 100rel, which is setup and then > torn down by the caller. > > Option 1) Local CSeq retains value of CSeq in INVITE after dialog > establishment > > --> INVITE CSeq 1 > <-- 180 CSeq 1 > --> PRACK CSeq 2 > <-- 200 CSeq 2 PRACK > <-- 200 CSeq 1 INVITE > --> ACK CSeq 1 > > ... media ... (no intervening SIP messages) ... > > --> BYE CSeq 2 > <-- 200 CSeq 2 BYE > > Option 2) Local CSeq uses value of CSeq in the PRACK after dialog > establishment > > --> INVITE CSeq 1 > <-- 180 CSeq 1 > --> PRACK CSeq 2 > <-- 200 CSeq 2 PRACK > <-- 200 CSeq 1 INVITE > --> ACK CSeq 1 > > ... media ... (no intervening SIP messages) ... > > --> BYE CSeq 3 > <-- 200 CSeq 3 BYE > > Hence the CSeq published in the BYE in Option 2) is 1 more than that > used in > Option 1) as it comes from the PRACK's CSeq, which was itself > incremented > after the INVITE. > > My interpretation of RFC 3261 and 3262, suggest that Option 2), i.e. the > local CSeq is updated with the CSeq used in the PRACK is correct. > However my > experience of other vendor's equipment suggests that opinions vary. > > RFC 3262 states that the "PRACK is like any other non-INVITE request > within > a dialog" and hence the local CSeq should be incremented by 1. > > > All feedback welcome, > > Matthew Gardiner > Software Enginneer > Aculab > > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > ********************** Legal Disclaimer **************************** > "This email may contain confidential and privileged material for the sole > use of the intended recipient. Any unauthorized review, use or distribution > by others is strictly prohibited. If you have received the message in > error, please advise the sender by reply email and delete the message. Thank > you." > ********************************************************************** > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > -- With thanks Neeraj Chowdhury "To err is human, to find a bug, Devine." _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
