Re: [reSIProcate] cseq issue with Dialog makeRequest

[Jeremy Geras <jgeras@xxxxxxxxxxxxxxx>]

Hi Scott,

Works well in my testing, thanks!

Jeremy

---

From: slgodin@xxxxxxxxx [slgodin@xxxxxxxxx] on behalf of Scott Godin [sgodin@xxxxxxxxxxxxxxx]
Sent: Thursday, May 31, 2012 8:52 AM
To: Jeremy Geras
Cc: resiprocate-devel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel