[reSIProcate] Bug in error handling / reSUBSCRIBE case for ClientSubscription

[aron_rosenberg at logitech.com]

Ok, my initial hunch was correct. The NameAddr h_To contains the To tag
from the last dialog and is being blindly copied/accepted by
makeSubscription. So my question is this: What is the best way to fix this?
I see a few possible ways:

1. In ClientSubscription.cxx, do something like this everyplace we are
calling makeSubscription

	NameAddr cleanTo(mLastRequest->header(h_To));
	cleanTo.remove(p_tag);
	makeSubscription(cleanTo .... );

2. In ClientSubscription.cxx, do something like this everyplace we are
calling makeSubscription - This will remove all params, not just To Tag

	NameAddr cleanTo(mLastRequest->header(h_To));
	cleanTo.removeParametersExcept();
	makeSubscription(cleanTo .... );

3. Fix all the makeSubscription / makePublication / any function which
takes a NameAddr to not use a Tag tag if passed in


-Aron


Aron Rosenberg
Sr. Director, Engineering
Phone: +1 (510) 713-5801
Logitech Inc, (SightSpeed Group)

__________________

In a number of places in ClientSubscription.cxx, the class will
automatically invoke dum.makeSubscription to create a new subscription if
the current one is failed. One such place is

   else if (!mEnded &&
            msg.header(h_StatusLine).statusCode() == 481 &&
            msg.exists(h_Expires) && msg.header(h_Expires).value() > 0)
   {
      InfoLog (<< "Received 481 to SUBSCRIBE, reSUBSCRIBEing (presence
server probably restarted) "
               << mLastRequest->header(h_To));

      SharedPtr<SipMessage> sub = mDum.makeSubscription(mLastRequest->
header(h_To), getUserProfile(), getEventType(), getAppDialogSet()->reuse
());
      mDum.send(sub);

      delete this;
      return;
   }

This is the 481 dialog doesn't exist case. In this case, dum is properly
building a new SUBSCRIBE message, but the new SUBSCRIBE message/dialog
starts out with a populated ToTag. The presence server then rejects this
new dialog since a ToTag must start empty. The new request has a different
Call-Id, from tag, branch tag/via, but the ToTag is the same as the
previous failed request

My hunch is that passing in h_To is causing the old ToTag to get copied to
the new request, but I am not sure what the proper fix is... I already
tried removing the getAppDialogSet()->reuse() param but it didn't have any
affect.

I have a test case setup for this with our presence server so I can try
various patches.

-Aron

Aron Rosenberg
Logitech Inc, (SightSpeed Group)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20100916/f9b646d7/attachment.htm>