reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] why reject redirect on in-dialog NOTIFY?

Redirection of _any_ mid-dialog request is not well specified. The dialog-usage draft talks about this a little bit. 
Here's a taste of some of the issues:

What do you do if you accept the redirect?
    A) Issue a new request that may form its own dialog.
What happens to the old dialog? Is it implicitly terminated? What about the other usages in that dialog? 
    B) Move the dialog to the new place.
What's the impact on the dialog's route set? Are you only manipulating the hop after the last route element? Are all the usages moving? Or is it just this subscribe usage?
There are more that are more subtle, but this, I hope, begins to shine the light on why you're not finding what you might have expected in the code. 

There are bugs against 3261 for this. See bugs.sipit.net, bug 40, 758.

There need to be more bugs there about this too...

RjS

On Apr 25, 2007, at 1:42 PM, Bruce Lowekamp wrote:


ServerSubscription.cxx has code to explicitly reject any 3xx class
response to an in-dialog NOTIFY, with a comment that it's bizarre:

         //in dialog NOTIFY got redirected? Bizarre...
         handler->onError(getHandle(), msg);
         handler->onTerminated(getHandle());
         delete this;

I am willing to believe that it's bizarre, but isn't it legal to do
this?  My reading of 12.2.1.2 of 3261 makes me believe that it's
perfectly legal to do:
The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a 
   dialog.  This behavior is described in Section 8.1.3.4.

I can't find anywhere that this behavior is overridden in 3265.  Is
there a reason not to accept the redirect?

I also found a comment in DialogSet.cxx that seemed relevant:
//!dcm! -- need to protect against 3xx highjacking a dialogset which //has a fully established dialog. also could case strange behaviour 
         //by sending 401/407 at the wrong time.
         if (mDum.mRedirectManager.get() && mState != Established)  //
!slg! for now don't handle redirect in established dialogs -
alternatively we could treat as a target referesh (using 1st Contact)
and reissue request

although I'm not sure what would need to be changed (other than the
test for != Established) to support the redirect.

Thanks,
Bruce
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel