[reSIProcate] CSeq value of terminated NOTIFY

[Scott Godin]

Nice catch - even if its legal, it definitely wasn't intentional!
 I've committed a fix for this to SVN main.

Thanks,
Scott

On Wed, May 26, 2010 at 4:04 PM, Francis Joanis <francis.joanis at gmail.com>wrote:

> Hi again :)
>
> When calling ClientSubscription::end(), the corresponding
> ServerSubscription object has to send a final NOTIFY indicating that
> the subscription state is terminated.
>
> However, the CSeq sequence of that last NOTIFY is always +2 from the
> last one and not only +1.
>
> The code in ServerSubscription::dispatch ends up calling:
>
> ...
> if(mExpires == 0)
> ...
> makeNotifyExpires();
> handler->onExpiredByClient(getHandle(), msg, *mLastRequest);
>
> mDialog.makeResponse(*mLastResponse, mLastSubscribe, 200);
> mLastResponse->header(h_Expires).value() = mExpires;
> send(mLastResponse);
> end(Timeout);
> ...
>
> The first call to makeNotifyExpires will create a new NOTIFY request
> and will increment the CSeq. Nothing seems to be actually done with
> that request (besides giving it to onExpiredByClient). The NOTIFY that
> will eventually get sent is actually constructed by calling
> end(Timeout), which overwrites the request constructed by
> makeNotifyExpires and which also increments the CSeq (again).
>
> Do you think the CSeq +2 could be considered a potential problem? I
> had a quick look at the RFCs but couldn't find anything.
>
> Thanks,
> Francis
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100526/b2110940/attachment.htm>