[reSIProcate] CSeq is incorrect in NOTIFY generated by DUM on SUBSCRIBE

[Robert Sparks]

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 at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel