> 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.
The receiver typically should not try enforcing the "increase by exactly 1" rule. I mention this because prior hops might have rejected a prior request. Thus the cseq gap might subsequently be larger than 1 when it reaches subsequent destinations. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
