Thanks people, Matthew Gardiner -----Original Message----- From: Neeraj Chowdhury [mailto:[EMAIL PROTECTED] Sent: 15 February 2006 07:06 To: [EMAIL PROTECTED] Cc: Sip-Implementors Subject: Re: [Sip-implementors] Local CSeq number after PRACK
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] <mailto:[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 <http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-February/00> 0440.html http://lists.cs.columbia.edu/pipermail/sip-implementors/2005-September/0 <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]> [mailto: [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] <mailto:[email protected]> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors <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] <mailto:[email protected]> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors <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
