I think you have got it wrong with the example in RFC 3665. The RE-INVITE with a CSEQ of 14 is generated from Bob's end while the original INVITE (CSEQ as 1) and BYE (CSEQ as 2) were generated from Alice's end. The INVITE and RE-INVITE are from different UAs each with it's own CSEQ number sequence.
You are right in your other reply to Sachin that CSEQ for ACK will always be the same as that of the INVITE being acknowledged. FWIW, there are various messages with-in a dialog which will increment the CSEQ - PRACK, INFO etc. So, the best way is to know if your call flow involves generating any such requests between the INVITE and RE-INVITE. I hope this helps. Regards, Gaurav _____ From: Divya Sachdeva [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 12:36 PM To: Gaurav Kheterpal Cc: kishore sowdi; [email protected] Subject: Re: [Sip-implementors] Re-Invite Cseq And in rfc 3665 Basic Call Scenarios In Section 3.7 "Session with re-INVITE (IP Address Change)" INvite has Cseq 1 And RE-Invite has Cseq of 14 And then the dialog is being terminated with BYE having CSeq 2 Could u please explain me this behaviour? On 11/16/06, Gaurav Kheterpal <[EMAIL PROTECTED] > wrote: A possibility is that there was a PRACK generated by UAC1 between the original INVITE and RE-INVITE. In that case, the PRACK would have an incremented CSEQ of 2 and the RE-INVITE will subsequently have a CSEQ value of 3. Draft-sip-100rel-02.txt mentions: "The PRACK request is like any other non-INVITE request sent within a call. The PRACK request contains the same Call-ID as the provisional response it is acknowledging. The CSeq number in the PRACK is higher than that of the request whose provisional response it acknowledges." Regards, Gaurav -----Original Message----- From: [EMAIL PROTECTED] [mailto: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] On Behalf Of Divya Sachdeva Sent: Thursday, November 16, 2006 11:22 AM To: kishore sowdi Cc: [email protected] Subject: Re: [Sip-implementors] Re-Invite Cseq Yeah But i think shd have got increased from 1 to 2 but not 3 On 11/16/06, kishore sowdi <[EMAIL PROTECTED] > wrote: > > Hi, > > Section 4 of rfc 3261 says - > "CSeq or Command Sequence contains an integer and a method name. The > CSeq number is incremented for each new request within a dialog and > is a traditional sequence number." > > Section 12.2.1.1 says - > "Requests within a dialog MUST contain strictly monotonically > increasing and contiguous CSeq sequence numbers (increasing-by-one) > in each direction (excepting ACK and CANCEL of course, whose numbers > equal the requests being acknowledged or cancelled)" > > So while sending re-invite , it has choosed running cseq number. > > regards, > kishore > > *Divya Sachdeva <[EMAIL PROTECTED]>* wrote: > > If a session is already established between 2 UAs > and the Cseq for the Invite was 1 then > If i now send a reInvite from UA1 to UA2 what will be the Cseq for this > Invite ..will it be incremented by 1 or again any arbitary number will be > chosen > As in my case wheni was implementing ,it got incremented from 1 to 3 .Can > anybody explain me this behaviour > _______________________________________________ > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
