[reSIProcate] cseq issue with Dialog makeRequest

[Scott Godin]

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>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
> 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/9f6b2bda/attachment.htm>