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

[Paul Kyzivat <[e-mail]>]

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