Hi, The Cseq is used for identifying new requests/transactions within the dialog. For new transactions within dialog, this number is always incremented whereas for non register requests outside the dialog, this number can be chosen arbitrarily.
Since the purpose of CANCEL is used to terminate the initiated transaction, the cseq number is copied from the transaction/request it is meant to cancel. Hence the CSEQ number part is kept similar to INVITE header field. refer 12.2.1.1 which clearly states that for any transactions which refer to earlier transactions, should keep the same cseq number. i.e ACK and CANCEL whose numbers equal the requests being acknowledged or cancelled. Regards Sameer -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of truename Sent: Friday, November 24, 2006 4:32 PM To: [email protected] Subject: [Sip-implementors] Question about Cseq in CANCEL request Hi all: There is a question confused me. In a session lanched by INVITE request, before replied a final status response, we can cancel this by a CANCEL request followed. Callid、FromTag、ToTag and Request-Url are enough to separate which INVITE request that the CANCEL request cancel. Why copy the number part of Cseq headfield? What is that surppose to? Here comes a example inferred by rfc3665: ----------------------------Callflow Start-------------------------------------------------------- Alice Proxy 1 | | | INVITE | |--------------->| | 100 | |<---------------| | 180 | |<---------------| | CANCEL | |--------------->| ----------------------------Callflow End------------------------------------------------------------ ----------------------------INVITE Message Start---------------------------------------------- INVITE sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 Route: <sip:ss1.atlanta.example.com;lr> From: Alice <sip:[EMAIL PROTECTED]>;tag=9fxced76sl To: Bob <sip:[EMAIL PROTECTED]> Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE Contact: <sip:[EMAIL PROTECTED]> Proxy-Authorization: Digest username="alice", realm="atlanta.example.com", nonce="ze7k1ee88df84f1cec431ae6cbe5a359", opaque="", uri="sip:[EMAIL PROTECTED]", response="b00b416324679d7e243f55708d44be7b" Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ----------------------------INVITE Message End---------------------------------------------------- ----------------------------CANCEL Message Start------------------------------------------------- CANCEL sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:[EMAIL PROTECTED]>;tag=9fxced76sl To: Bob <sip:[EMAIL PROTECTED]> Route: <sip:ss1.atlanta.example.com;lr> Call-ID: [EMAIL PROTECTED] CSeq: 1 CANCEL Content-Length: 0 ----------------------------CANCEL Message End-------------------------------------------------- _______________________________________________ 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
