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

On 10/6/14 4:01 PM, Christer Holmberg wrote:
> 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.

For an in-dialog refer, would that NOTIFY be in the existing dialog? In 
3265 there is a new dialog usage for that, but a goal is to avoid that. 
So if it was in the dialog, then it would have to be in the INVITE 
dialog-usage, which would be a change.

And for out-of-dialog refer, there is no dialog for the notify to travel 
in. Would that NOTIFY be out-of-dialog but non-dialog-establishing? That 
would be a bit weird.

> 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...

Perhaps that is possible.

	Thanks,
	Paul

> 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