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

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 03 Oct 2014 17:40:53 +0900

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?

Regards,
Shinji

>-------- Forwarded Message -------- Subject: New Version Notification for 
>draft-sparks-sipcore-refer-explicit-subscription-01.txt
> Date: Mon, 08 Sep 2014 13:31:32 -0700
> From: [a:mailto:[email-masked]][email-masked]
> To: Robert Sparks [a:mailto:[email-masked]]<[email-masked]>, 
>Robert Sparks [a:mailto:[email-masked]]<[email-masked]>
>
>
>A new version of I-D, draft-sparks-sipcore-refer-explicit-subscription-01.txt
>has been successfully submitted by Robert Sparks and posted to the
>IETF repository.
>
>Name:		draft-sparks-sipcore-refer-explicit-subscription
>Revision:	01
>Title:		Explicit Subscriptions for the REFER Method
>Document date:	2014-09-08
>Group:		Individual Submission
>Pages:		11
>URL:            [a:http://www.ietf.org/internet-drafts/draft-sparks-sipcore-
>refer-explicit-subscription-01.txt]http://www.ietf.org/internet-drafts/draft-
>sparks-sipcore-refer-explicit-subscription-01.txt
>Status:         [a:https://datatracker.ietf.org/doc/draft-sparks-sipcore-
>refer-explicit-subscription/]https://datatracker.ietf.org/doc/draft-sparks-
>sipcore-refer-explicit-subscription/
>Htmlized:       [a:http://tools.ietf.org/html/draft-sparks-sipcore-refer-
>explicit-subscription-01]http://tools.ietf.org/html/draft-sparks-sipcore-
>refer-explicit-subscription-01
>Diff:           [a:http://www.ietf.org/rfcdiff?url2=draft-sparks-sipcore-
>refer-explicit-subscription-01]http://www.ietf.org/rfcdiff?url2=draft-sparks-
>sipcore-refer-explicit-subscription-01
>
>Abstract:
>   The SIP REFER request, as defined by RFC3515, triggers an implicit
>   SIP-Specific Event Notification framework subscription.  Conflating
>   the start of the subscription with handling the REFER request makes
>   negotiating SUBSCRIBE extensions impossible, and complicates avoiding
>   SIP dialog sharing.  This document defines an extension to REFER to
>   remove the implicit subscription and replace it with an explicit one.
>
>                                                                               
>   
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

---

From: Robert Sparks <[email-masked]>
Date: Fri, 03 Oct 2014 10:47:50 +0200

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

With the typical use of REFER specified to date (transfer), the refer 
will have
a Target-Dialog header field and will likely be accepted at only one of the
places it might have forked to.

RjS

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 06 Oct 2014 14:44:52 +0900

Hello Robert,

>the REFER was accepted on that branch, including its own Refer-Events-At

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.

Regards,
Shinji

---

From: Robert Sparks <[email-masked]>
Date: Mon, 06 Oct 2014 09:25:57 -0500

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Oct 2014 14:59:29 +0000

Hi,

This of course does not apply to in-dialog REFERs, where forking does not occur.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Robert Sparks<mailto:[email-masked]>
Sent: ‎06/‎10/‎2014 17:26
To: OKUMURA Shinji<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01

>> places it might have forked to.

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Oct 2014 17:49:52 +0000

Hi,

>>> 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.
> immediate NOTIFY in SIP Events exists.
>

One option would to still send the immediate NOTIFY, but with the "Subscription-State" header field value set to "terminated".

(But, as said earlier, for in-dialog REFERs such NOTIFY would not be needed, as there is no forking.)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Oct 2014 15:00:11 -0400

On 10/6/14 10:25 AM, Robert Sparks wrote:
>>> whether

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Oct 2014 20:01:17 +0000

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:[email-masked]>
Sent: ‎06/‎10/‎2014 22:00
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] New Version Notification for draft-sparks-sipcore-refer-explicit-subscription-01

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Oct 2014 19:00:57 -0400

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

> ------------------------------------------------------------------------
> From: Paul Kyzivat <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Subject: Re: [sipcore] New Version Notification for
> draft-sparks-sipcore-refer-explicit-subscription-01
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 07 Oct 2014 15:29:49 +0900

Hi,

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

Correct me if I'm wrong, would the NOTIFY transport a Refer-Events-At header?

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Oct 2014 10:56:12 +0000

Hi,

> 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: Christer Holmberg <[email-masked]>
Date: Tue, 7 Oct 2014 11:06:54 +0000

Hi,

>Wow (slaps forehead) - very good catch. That's the whole reason the immediate NOTIFY in SIP Events exists.
>

I was checking RFC 4488, because you have the same issue there if the immediate NOTIFY is not sent.

RFC 4488 "solves" the problem with the following statement:

	"The "Refer-Sub" header field set to "false" MAY be used by the REFER-
   	Issuer only when the REFER-Issuer can be certain that the REFER
   	request will not be forked."

So, perhaps we could do the same.

Regards.

Christer