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

[Bruce Lowekamp]

In our case the situation was much simpler, but I can see that in the
general case, the problem explodes.  I'll find another way to deal
with it.

Thanks,
Bruce


On 4/25/07, Robert Sparks <rjsparks at nostrum.com> wrote:
> 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 at list.resiprocate.org
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>