As stated at the end of the 4th paragraph of section 10.20 of bis03:
"Furthermore, the CSeq numbering space is unique in each direction. That is,
the CSeq values in requests from A to B are independent of the values in
requests from B to A."
So it is perfectly legal for B to use CSeq number of 2 in your example since
it is the first request it sends to A in this call leg.
Alex C.
-----Original Message-----
From: Dvir Oren [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 31, 2001 7:35 AM
To: Jonathan Rosenberg
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] CSeq number
Jonathan Rosenberg writes ("RE: [Sip-implementors] CSeq number"):
> I think you are concerned about the case where the server sees two
> consecutive requests that differ with a CSeq of more than one. This is now
> addressed in bis-03:
Actually, the solution to that is simple, as you said: accept higher
cseqs. My problem is that the 'client' might receive a LOWER cseq:
A: INVITE B Cseq: 1
B: OK Cseq: 1
A: ACK Cseq: 1
...rtp...
A: INVITE B (e.g., on hold) Cseq: 2
...retranmissions (B doesn't receive)...
A: INVITE B (e.g., on hold 2) Cseq: 3
...retransmission (B doesn't receive)...
B: INVITE A (e.g., on hold) Cseq: 2
Now, A receives an INVITE from B with a LOWER cseq than the last sent
CSeq. Should A through this INVITE, or accept it? If A should accept
it, then what is the meaning of the CSeq number? Basically, all UAs
should accept any transactions with whatever cseq number.
A similar situation might occur if B receives the INVITEs, but
discards them since they are malformed (or B is allready in the middle
of a transactions). In these cases B cannot update the CSeq number.
--
Dvir Oren <[EMAIL PROTECTED]>
Lucid Voice Ltd. <http://www.lucidvoice.com>
5 Jabotinski St., Ramat-Gan, 52520 Israel
Tel: 972 3 5757488 Fax: 972 3 5757499
_______________________________________________
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
