Re: [reSIProcate] CSeq value of terminated NOTIFY
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel