Re: [reSIProcate] CSeq is incorrect in NOTIFY generated by DUM on SUBSCRIBE
Volodymyr -
Each side of the dialog maintains its own CSeq sequence.
The NOTIFYs are coming from the other end, so the CSeq numbers in them
have ->absolutely nothing<- in relation with the CSeq numbers in the
SUBSCRIBE.
It would be perfectly valid to see a dialog containing these messages
for instance:
SUBSCRIBE
CSeq: 38220
|------------------->|
NOTIFY
CSeq: 15
|<--------------------|
NOTIFY
CSeq: 16
|<--------------------|
SUBSCRIBE
CSeq: 38221
|------------------->|
Also, be very careful with what you do in code with that "contiguous"
requirement.
Elements are required to send contiguously, but because messages might
be terminated by proxies, it is wrong to react to gaps in the CSeq at
the receiving element.
(Essentially, that renders the requirement to send contiguously
pointless).
RjS
On Feb 24, 2009, at 9:13 AM, Volodymyr Tarasenko wrote:
Hi Adam,
In terms of the local CSeq: According to RFC 3261, The CSeq
number space is unique in each direction. In other words,
the CSeq in the NOTIFY is completely unrelated to the CSeq
in the SUBSCRIBE. The original code is correct.
Maybe you are right, but according to RFC 3261 CSeq header must
contain strictly monotonically increasing and contiguous numbers,
and in case of subscription, NOTIFY is generated inside dialog so
from my point of view its CSeq should be greater than in original
SUBSCRIBE
Regards,
Volodymyr!
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel