I guess I didn't state my question correctly. Following call scenario: 1. UAC sends an INVITE with CSEQ 1. 2. UAS responds with 183 SESSION PROGRESS (CSEQ=1). 3. UAC creates a PRACK with CSEQ=2. 4. UAS responds with a 200 OK (for PRACK, CSEQ 2). 5. UAS sends another provisional response 180 RINGING (CSEQ = 1). 6. UAC creates another PRACK with CSEQ=3. 7. UAS acks the PRACK. 8. UAS sends a 200 OK (for INVITE, CSEQ=1). 9. UAC sends a ACK (for INVITE) completing the 3 way handshake. At some point one of them decide to hangup. A BYE is issued. What shd the CSEQ be ? Should be 4 (basically greater than the CSEQ of the last PRACK)? or can it be 2(basically greater than the CSEQ in the last INVITE)? The doc says that the CSEQ MUST be greater than the last completed transaction. In the above call flow, the INVITE is the last completed transaction and the CSEQ for the same was 1..... Thanks, Venkatesh -----Original Message----- From: Scott Happell [mailto:[EMAIL PROTECTED]] Sent: Monday, February 12, 2001 12:52 PM To: 'Venkatesh Venkataramanan' Cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] RE: [SIP] Question regarding CSEQ processi ng with PRACK... >From draft-ietf-sip-100rel-02.txt "Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. The Call-ID in this request MUST match that of the provisional response. The CSeq in this request MUST be larger than the last request (PRACK or otherwise) sent by this UAC for this call leg." I believe the Reliable Provisional Responses extension draft has since been added to the RFC 2543 bis drafts. -----Original Message----- From: Venkatesh Venkataramanan [mailto:[EMAIL PROTECTED]] Sent: Monday, February 12, 2001 2:33 PM To: Arunachalam Venkataman Cc: [EMAIL PROTECTED] Subject: [Sip-implementors] RE: [SIP] Question regarding CSEQ processing with PRACK... But isn't PRACK a transaction within a transaction? The last transaction that ended in the example below is the INVITE. So, when a subsequent BYE or reINVITE/REFER or what ever message is called, shouldn't the rules of CSEQ mean that all I need to worry about is that CSEQ should be greater than the one used in the INVITE (no matter how many PRACK's were sent out in between)? -----Original Message----- From: Arunachalam Venkataman [mailto:[EMAIL PROTECTED]] Sent: Monday, February 12, 2001 11:23 AM To: 'Venkatesh Venkataramanan' Cc: [EMAIL PROTECTED] Subject: RE: [SIP] Question regarding CSEQ processing with PRACK... I believe the CSEQ should increment for each request sent out. So if the PRACK in the example cited goes out with a CSEQ of 1, the BYE would be sent with a CSEQ of 2 (or higher). -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Venkatesh Venkataramanan Sent: Monday, February 12, 2001 12:31 PM To: Jonathan Rosenberg Cc: [EMAIL PROTECTED] Subject: [SIP] Question regarding CSEQ processing with PRACK... All: I needed some clarification on the usage of CSEQ with PRACK's. The draft says that the CSEQ number in PRACK MUST be higher than the last transaction CSEQ number (INVITE or otherwise). So, for example, say, an UAC sends out an INVITE with CSEQ 1, it receives a 180 ringing, it issues a PRACK with CSEQ 2. The question I had is should these CSEQ's be preserved after the INVITE transaction has ended? Meaning, in the above example, say the PRACK, generates a 200 OK by the UAS for the same, followed by an ACK for the INVITE(when the called party answers), the UAC issues an ACK with CSEQ 1 INVITE to complete the 3 way handshake. At a later point of time, say, the user hungup, which causes the UAC to issue a BYE, should the CSEQ field be constructed with a sequence number, higher than the last PRACK it sent out(or received in case of far end disconnects) or the last INVITE it sent out(or received)? Please elaborate. Thanks. Venkatesh _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to [EMAIL PROTECTED] with "subscribe sip-implementors" in the body. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
