Subject: Re: [sipcore] I-D Action: draft-sparks-sipcore-refer-explicit-subscription-00.txt

From: Brett Tate <[email-masked]>
Date: Thu, 2 Oct 2014 09:36:41 -0400

> I just come up with another approach.
>
> A referrer send REFER within an existing dialog.
> And a notifier(referee) send NOTIFY within new dialog.
> Of course Request URI of NOTIFY is a GRUU of a referrer.
>
> It seems to be a simple solution for an avoidance of dialog-reuse.
>
> I think this option(Required: subscription-newdialog?) is available
> for not only REFER but also SUBSCRIBE.

One of the obstacles to this approach is that it would likely require an
update to RFC 6665.  The NOTIFY is not really a dialog-creating method.
RFC 6665 also significantly restricted what could create a subscription;
I'm not sure that this approach would satisfy the RFC 6665 restriction.

-brett

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 03 Oct 2014 18:35:41 +0900

Hi, Brett.

Thanks for your reply.

>update to RFC 6665.  The NOTIFY is not really a dialog-creating method.

RFC 6665 seems to say that a NOTIFY create a dialog, but
a SUBSCRIBE does not create a dialog.

Is my understanding wrong?

>I'm not sure that this approach would satisfy the RFC 6665 restriction.

Yes, my approach could be contrary to something else.
(i.e. section 4.4.1)

Regards,
Shinji

---

From: Brett Tate <[email-masked]>
Date: Fri, 3 Oct 2014 08:13:04 -0400

> >One of the obstacles to this approach is that it would likely require
> >an update to RFC 6665.  The NOTIFY is not really a dialog-creating
method.
>
> RFC 6665 seems to say that a NOTIFY create a dialog, but a SUBSCRIBE
does
> not create a dialog.

Section 4.1.2.1 indicates "SUBSCRIBE is a dialog-creating method, as
described in [RFC3261]".

The NOTIFY contains a To tag which is one of the items that allow it be
matched to the SUBSCRIBE or REFER.

Section 4.4.1:

"NOTIFY requests are matched to such SUBSCRIBE requests if they
  contain the same "Call-ID", a "To" header field "tag" parameter that
  matches the "From" header field "tag" parameter of the SUBSCRIBE
  request, and the same "Event" header field."

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 06 Oct 2014 15:24:55 +0900

Hi Brett,

>> >an update to RFC 6665.  The NOTIFY is not really a dialog-creating method.
>>
>> RFC 6665 seems to say that a NOTIFY create a dialog, but a SUBSCRIBE does
>> not create a dialog.
>>

But then,
Appendix B.  Changes from RFC 3265
B.22.  Rationalize Dialog Creation
   Section 4.4.1 has been updated to specify that dialogs should be
   created when the NOTIFY arrives.  Previously, the dialog was
   established by the SUBSCRIBE 200 or by the NOTIFY transaction.  This
   was unnecessarily complicated; the newer rules are easier to
   implement (and result in effectively the same behavior on the wire).

For me, these descriptions are considerably ambiguous.

Regards,
Shinji

---

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

Hi,

in the below sequence,

    subscriber                              notifier
        |                                       |
        |   SUBSCRIBE in dialog                 |
        |-------------------------------------->| dialog1
        |   callid:1, fromtag:a, totag:b        |
        |                                       |
        |   200 OK(SUBSCRIBE)                   |
        |<--------------------------------------| dialog1
        |                                       |
        |   NOTIFY                              |
        |<--------------------------------------| dialog2
        |   callid:1, fromtag:c, totag:a        |
        |                                       |

This NOTIFY seems to satisfy the RFC 6665 restriction(section 4.4.1).
Does this NOTIFY act against accepted wisdom for SIP?

---

From: Brett Tate <[email-masked]>
Date: Tue, 7 Oct 2014 06:29:36 -0400

> Does this NOTIFY act against accepted wisdom for SIP?

RFC 6665 section 4.2.1.2:

"Upon successfully accepting or refreshing a subscription, notifiers
  MUST send a NOTIFY request immediately to communicate the current
  resource state to the subscriber.  This NOTIFY request is sent on the
  same dialog as created by the SUBSCRIBE response."

RFC 6665 section 4.4.3:

"Upon receipt of this SUBSCRIBE request, the notifier (or notifiers,
  if the SUBSCRIBE request was forked) will send a NOTIFY request
  containing resource state in the same dialog."