< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index |
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)