Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01

Hi,

I don't think we shall assume support in forking proxy (why didn't we define a Forking-Proxy-Require header field back in the days...).

I suggested to use
NOTIFY which indicates terminated. If that doesn't work, perhaps we should disallow the mechanism in out-of-dialog REFERs. After all, the need for the mechanism comes from in-dialog usage of REFER...

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:pkyzivat@alum.mit.edu>
Sent: ‎06/‎10/‎2014 22:00
To: sipcore@ietf.org<mailto:sipcore@ietf.org>
Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01

On 10/6/14 10:25 AM, Robert Sparks wrote:
>
> On 10/6/14 12:44 AM, OKUMURA Shinji wrote:
>> Hello Robert,
>>
>>> On 10/3/14 10:40 AM, OKUMURA Shinji wrote:
>>>> Hi,
>>>>
>>>> As a general rule, REFER request may fork.
>>>> But a referrer receives only one response(i.e. Refer-Events-At).
>>>> Does this draft disallow a REFER request to be forked?
>>> No.
>>>
>>> If the REFER forks, it will get responses from each branch of the fork.
>>> The response from each branch will have its own information about
>>> whether
>>> the REFER was accepted on that branch, including its own Refer-Events-At
>>> URI.
>> In accordance with the following, a successful response for REFER
>> request is only one.
>>
>> RFC3261
>> 17.1.2.1 Overview of the non-INVITE Transaction
>>
>>     Unlike an INVITE transaction, a non-INVITE transaction has no special
>>     handling for the 2xx response.  The result is that only a single 2xx
>>     response to a non-INVITE is ever delivered to a UAC.
> Wow (slaps forehead) - very good catch. That's the whole reason the
> immediate NOTIFY
> in SIP Events exists.
>
> The consequences of that are going to require some time to think through.

One way to handle this is to:

- allow multiple Refer-Events-At header fields in the response
- make it the responsibility of the forking proxy to gather the
responses from each fork and consolidate them into a single response.

This isn't ideal. It requires the proxy to support the feature. And it
means it must special case forking of REFER, since normally it can
simply forward the first 2xx response it gets to a forked request.

OTOH, I'll guess there is very little current use of out-of-dialog
REFER. So there may not be many backward compatibility issues with that.

        Thanks,
        Paul

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore