Re: [reSIProcate] why reject redirect on in-dialog NOTIFY?
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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel