[reSIProcate] cseq issue with Dialog makeRequest

[Jeremy Geras]

Hi Scott,

Works well in my testing, thanks!

Jeremy

________________________________
From: slgodin at gmail.com [slgodin at gmail.com] on behalf of Scott Godin [sgodin at sipspectrum.com]
Sent: Thursday, May 31, 2012 8:52 AM
To: Jeremy Geras
Cc: resiprocate-devel at resiprocate.org
Subject: Re: [reSIProcate] cseq issue with Dialog makeRequest

Hi Jeremy,

This is a good find.  Looks like you are running into the case where you receive the first NOTIFY before you receive the 200/SUB.  When you receive the 200/SUB first then the Dialog is created using the 200 response and the CSeq is set appropriately in the Dialog.  When the dialog is created due to a NOTIFY request, the local CSeq starts at one.  This is not correct.  I'll commit a fix for this main:

Dialog::Dialog  -> near end of isRequest code block:

      mRemoteCSeq = request.header(h_CSeq).sequence();

      // This may actually be a UAC dialogset - ie. the case where the first NOTIFY creates the
      // SUBSCRIPTION dialog, instead of the 200/SUB.  If so, then we need to make sure the local
      // CSeq is correct - it's value may be greator than 1, if the original request (SUBSCRIBE)
      // got digest challenged.
      BaseCreator* creator = mDialogSet.getCreator();
      if(creator)
      {
         mLocalCSeq = creator->getLastRequest()->header(h_CSeq).sequence();
      }
      else
      {
         mLocalCSeq = 1;
      }


Regards,
Scott

On Wed, May 30, 2012 at 3:32 PM, Jeremy Geras <jgeras at counterpath.com<mailto:jgeras at counterpath.com>> wrote:
Hi,

This is concerning the following, where we are the UAC sending the SUBSCRIBEs:

SUBSCRIBE (CSeq: 1)
407/SUBSCRIBE (CSeq: 1)
SUBSCRIBE (CSeq: 2)
NOTIFY
200/SUBSCRIBE (CSeq: 2)
200/NOTIFY
(one hour goes by, and our subscription refresh timer fires)
SUBSCRIBE (CSeq: 2)  <---  issue

It looks to me like:

 - DialogSet invokes the ClientAuthManager to get the SUBSCRIBE w/CSeq: 2 to happen; the mLastRequest in BaseCreator gets updated to CSeq: 2 at this point
 - Dialog never gets updated with CSeq: 2; so when the subscription refresh goes out (formed using Dialog::makeRequest), it has CSeq: 2 (should be 3)

Am I missing something, or does this look like a legit issue?

(In our case it manifests itself in our not including Route headers on a re-SUBSCRIBE because we happen to get a 200/SUBSCRIBE response that doesn't include Record-Route headers -- and, because of the CSeq issue, we reset the route set based on that 200/SUBSCRIBE [the code thinks it was the "first 200 OK response", but it was obviously not]).

Thanks,
Jeremy

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org<mailto: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/20120531/3561bbe7/attachment.htm>