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

The NOTIFY would only be sent in the out-of-dialog case. For in-dialog there is no need for the NOTIFY.

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

Correct, when I think about it...

Regards,

Christer

> 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