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

[OKUMURA Shinji <[e-mail]>]

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?

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