Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward - The text using PRID

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Sep 2018 12:28:45 +0000

Hi,

I have put together initial text to support mid-dialog NOTIFY request.

I put everything in a dedicated section.

If people are ok with the approach, I will create a proper pull request.

----

X. Subscription Dialog Considerations

when a UA creates a subscription dialog [RFC6665], there may be a long period between mid-dialog SIP NOTIFY
request. During that time the UA might get suspended, and needs to be awaken in order to receive
such NOTIFY request. However, unlike an initial request for a dialog, the NOTIFY request will not contain
the pn- SIP URI parameters needed by the proxy to request a push notification towards the UA. Instead, the proxy
need to support a mechanism, where it stores the information needed to request a push notification towards the UA, 
and when the proxy receives the initial SUBSCRIBE request for the subscription dialog it needs to associate the 
subscription dialog with that information. This section describes the UA- and proxy procedures for such mechanism.

The procedures in this section are applied in addition to the generic procedures for the UA and the proxy.

X.1. SIP UA Beahvior

X.1.1. SUBSCRIBE

When the UA sends a SIP SUBSCRIBE request (initial or subscription refresh), if the UA wants to receive push notification 
requests when the proxy receives NOTIFY requests addressed towards the UA, the UA MUST include a '+sip.prid' Contact header 
field parameter in the SUBSCRIBE request. The UA MUST include the same parameter value that it included in the pn-prid SIP URI
parameter of the last REGISTER request.

X.2. SIP Proxy Behavior

X.2.1. REGISTER

When the UA receives a REGISTER request from the UA, the proxy MUST store the information (the pn- SIP URI parameters) 
needed to request push notifications associated with the registration towards the UA, and use the pn-prid SIP URI parameter 
value as key to access the data. The proxy MUST store the information until the registration expires. As describe in section 5.2, 
the proxy needs to be able to retrieve the registration state information from the registrar using some mechanism. 

X.2.2 SUBSCRIBE

When the proxy receives an initial SUBSCRIBE request for a subscription dialog from a UA, the request 
contains a '+sip.prid' Contact header field parameters, and the proxy has stored the information needed 
in order to request push notifications towards the UA [ref-to-reg-section], the proxy MUST store the 
subscription dialog information, including the '+sip.prid' Contact header field parameter value. In addition,
the proxy MUST add a Record-Route header field to the request and add itself to the dialog route [RFC3261]
before forwarding the request.

If the proxy receives a mid-dialog SUBSCRIBE subscription refresh request from the UA, and the request contains
a '+sip.prid' Contact header field parameter with an updated parameter value, the proxy MUST update the value
in the stored dialog information.

X.2.3. NOTIFY

When the proxy receives a mid-dialog NOTIFY request addressed towards the UA, the proxy has stored the associated
dialog information [ref-to-sub-section], and the proxy is able to retrieve the stored information needed to request
a push notification towards the UA [ref-to-reg-equest], the proxy MUST request a push notification towards the UA.
Once the proxy has received the triggered REGISTER request, and the associated successful response, the proxy can
forward the NOTIFY request towards the UA.

Otherwise the proxy MUST reject the NOTIFY request and send a 480 (Temporarily Unavailable) error response.

As described in [section 5.3.2], while waiting for the push notification request to
succeed, and the associated REGISTER request to arrive from the SIP UA, the proxy needs 
to take into consideration that the transaction associated with the NOTIFY request will 
eventually time out at the sender of the request (UAC), and the sender will consider the
transaction a failure.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2018 11:03:25 -0400

Christer,

> If people are ok with the approach, I will create a proper pull request.

I have one concern about this:

The doc says that the PRID must be unique. But it doesn't state the 
scope of uniqueness. It looks to me that until now the PRID only had to 
be unique among PRID values issued by the same PNS. (At least if we 
assume that a given UA only uses one PNS.) But the new text for 
subscription dialogs expands the requirement. Now the PRID must be 
unique among all dialogs managed by the push proxy. These might involve 
multiple PNSs.

It is hard to ensure uniqueness of PRID values across multiple PNSs 
since the format is left entirely up to the PNS. I think this needs more 
consideration.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Sep 2018 19:05:23 +0000

Hi,

> The doc says that the PRID must be unique. But it doesn't state the scope of uniqueness. It 
> looks to me that until now the PRID only had to be unique among PRID values issued by the 
> same PNS. (At least if we assume that a given UA only uses one PNS.) But the new text for 
> subscription dialogs expands the requirement. Now the PRID must be unique among all dialogs 
> managed by the push proxy. These might involve multiple PNSs.
>
> It is hard to ensure uniqueness of PRID values across multiple PNSs since the format is left entirely up 
> to the PNS. I think this needs more consideration.

We can include more information in the SUBSCRIBE, if needed.

Regards,

Christer

> when a UA creates a subscription dialog [RFC6665], there may be a long 
> period between mid-dialog SIP NOTIFY request. During that time the UA 
> might get suspended, and needs to be awaken in order to receive such 
> NOTIFY request. However, unlike an initial request for a dialog, the 
> NOTIFY request will not contain the pn- SIP URI parameters needed by 
> the proxy to request a push notification towards the UA. Instead, the 
> proxy need to support a mechanism, where it stores the information needed to request a push notification towards the UA, and when the proxy receives the initial SUBSCRIBE request for the subscription dialog it needs to associate the subscription dialog with that information. This section describes the UA- and proxy procedures for such mechanism.
> 
> When the UA sends a SIP SUBSCRIBE request (initial or subscription 
> refresh), if the UA wants to receive push notification requests when 
> the proxy receives NOTIFY requests addressed towards the UA, the UA 
> MUST include a '+sip.prid' Contact header field parameter in the SUBSCRIBE request. The UA MUST include the same parameter value that it included in the pn-prid SIP URI parameter of the last REGISTER request.
> 
> X.2. SIP Proxy Behavior
> 
> X.2.1. REGISTER
> 
> When the UA receives a REGISTER request from the UA, the proxy MUST 
> store the information (the pn- SIP URI parameters) needed to request 
> push notifications associated with the registration towards the UA, 
> and use the pn-prid SIP URI parameter value as key to access the data. The proxy MUST store the information until the registration expires. As describe in section 5.2, the proxy needs to be able to retrieve the registration state information from the registrar using some mechanism.
> 
> X.2.2 SUBSCRIBE
> 
> When the proxy receives an initial SUBSCRIBE request for a 
> subscription dialog from a UA, the request contains a '+sip.prid' 
> Contact header field parameters, and the proxy has stored the 
> information needed in order to request push notifications towards the 
> UA [ref-to-reg-section], the proxy MUST store the subscription dialog 
> information, including the '+sip.prid' Contact header field parameter value. In addition, the proxy MUST add a Record-Route header field to the request and add itself to the dialog route [RFC3261] before forwarding the request.
> 
> If the proxy receives a mid-dialog SUBSCRIBE subscription refresh 
> request from the UA, and the request contains a '+sip.prid' Contact 
> header field parameter with an updated parameter value, the proxy MUST update the value in the stored dialog information.
> 
> X.2.3. NOTIFY
> 
> When the proxy receives a mid-dialog NOTIFY request addressed towards 
> the UA, the proxy has stored the associated dialog information 
> [ref-to-sub-section], and the proxy is able to retrieve the stored information needed to request a push notification towards the UA [ref-to-reg-equest], the proxy MUST request a push notification towards the UA.
> Once the proxy has received the triggered REGISTER request, and the 
> associated successful response, the proxy can forward the NOTIFY request towards the UA.
> 
> As described in [section 5.3.2], while waiting for the push 
> notification request to succeed, and the associated REGISTER request 
> to arrive from the SIP UA, the proxy needs to take into consideration 
> that the transaction associated with the NOTIFY request will 
> eventually time out at the sender of the request (UAC), and the sender will consider the transaction a failure.
> 
> 
> 
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 17 Sep 2018 15:11:22 -0400

Christer,

It also looks like  '+sip.prid' contact header parameter will remain in the
contact header and will be visible to the remote party receiving the
subscription. This means it can be used for fingerprinting and client
tracking which can have privacy implications.

I think the right solution here is to unbundle long duration dialog
support. Push proxy should allocate an additional ID during the
registration process, not related to PRID, which is unique for the push
notification proxy and allocated in a way that preserve client privacy,
such as a cryptographically random function (analogous to private GRUU).
This ID should uniquely identify the push notification parameters and can
be used to associate SUBSCRIBE dialog with these parameters. The presence
of this ID in registration response would indicate that proxy supports long
duration dialogs where UA can suspend itself. If this ID is not present,
suspending UA during long duration dialogs, such as SUBSCRIBE is not
supported.

Regards,

_____________
Roman Shpount

On Mon, Sep 17, 2018 at 11:03 AM, Paul Kyzivat <[email-masked]>
wrote:

> The doc says that the PRID must be unique. But it doesn't state the scope
> of uniqueness. It looks to me that until now the PRID only had to be unique
> among PRID values issued by the same PNS. (At least if we assume that a
> given UA only uses one PNS.) But the new text for subscription dialogs
> expands the requirement. Now the PRID must be unique among all dialogs
> It is hard to ensure uniqueness of PRID values across multiple PNSs since
> the format is left entirely up to the PNS. I think this needs more
> consideration.
>
>         Thanks,
>         Paul
>
>
> ----
>>
>> period between mid-dialog SIP NOTIFY
>> the pn- SIP URI parameters needed by the proxy to request a push
>> notification towards the UA. Instead, the proxy
>> need to support a mechanism, where it stores the information needed to
>> request a push notification towards the UA,
>> and when the proxy receives the initial SUBSCRIBE request for the
>> subscription dialog it needs to associate the
>> refresh), if the UA wants to receive push notification
>> requests when the proxy receives NOTIFY requests addressed towards the
>> UA, the UA MUST include a '+sip.prid' Contact header
>> field parameter in the SUBSCRIBE request. The UA MUST include the same
>> parameter value that it included in the pn-prid SIP URI
>> When the UA receives a REGISTER request from the UA, the proxy MUST store
>> the information (the pn- SIP URI parameters)
>> needed to request push notifications associated with the registration
>> towards the UA, and use the pn-prid SIP URI parameter
>> value as key to access the data. The proxy MUST store the information
>> until the registration expires. As describe in section 5.2,
>> in order to request push notifications towards the UA
>> [ref-to-reg-section], the proxy MUST store the
>> dialog information [ref-to-sub-section], and the proxy is able to
>> retrieve the stored information needed to request
>> a push notification towards the UA [ref-to-reg-equest], the proxy MUST
>> request a push notification towards the UA.
>> associated successful response, the proxy can
>> Otherwise the proxy MUST reject the NOTIFY request and send a 480
>> (Temporarily Unavailable) error response.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2018 15:50:02 -0400

> We can include more information in the SUBSCRIBE, if needed.

Certainly more info there is needed. But I also think more needs to be 
said up front and first specification of PRID, that global uniqueness is 
required, across *all* PNSs. But beyond that, I don't see how it can be 
left to each individual PNS to specify how it is going to guarantee that 
its values are unique from those of other PNSs. Seems like each PNS 
needs to have a distinct namespace somehow.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Sep 2018 19:54:06 +0000

Hi,

> It also looks like  '+sip.prid' contact header parameter will remain in the contact header and will be visible to the 
> remote party receiving the subscription. This means it can be used for fingerprinting and client tracking which can 
> have privacy implications.

In the pull request the text says that the proxy must remove it.

> I think the right solution here is to unbundle long duration dialog support. Push proxy should allocate an additional ID 
> during the registration process, not related to PRID, which is unique for the push notification proxy and allocated in a 
> way that preserve client privacy, such as a cryptographically random function (analogous to private GRUU). This ID should 
> uniquely identify the push notification parameters and can be used to associate SUBSCRIBE dialog with these parameters. 
> The presence of this ID in registration response would indicate that proxy supports long duration dialogs where UA can 
> suspend itself. If this ID is not present, suspending UA during long duration dialogs, such as SUBSCRIBE is not supported.

I agree. That was more or less my original idea with the proxy generating a GRUU, but it was commented that it would not have the properties of a GRUU. 

But, we can could it something else. And, it only needs to be unique within the proxy, and it does not need to have any "globally reachable" properties.

And, if it's just a random value, without any privacy issues, perhaps we could even include it in the Contact of the SUBSCRIBE, meaning it would be present in the mid-dialog NOTIFY requests?

Regards,

Christer

On Mon, Sep 17, 2018 at 11:03 AM, Paul Kyzivat <[email-masked]> wrote:
Christer,

The doc says that the PRID must be unique. But it doesn't state the scope of uniqueness. It looks to me that until now the PRID only had to be unique among PRID values issued by the same PNS. (At least if we assume that a given UA only uses one PNS.) But the new text for subscription dialogs expands the requirement. Now the PRID must be unique among all dialogs managed by the push proxy. These might involve multiple PNSs.

It is hard to ensure uniqueness of PRID values across multiple PNSs since the format is left entirely up to the PNS. I think this needs more consideration.

        Thanks,
        Paul

----

X.1. SIP UA Beahvior

X.1.1. SUBSCRIBE

X.2. SIP Proxy Behavior

X.2.1. REGISTER

X.2.2 SUBSCRIBE

X.2.3. NOTIFY

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Sep 2018 19:58:16 +0000

Hi,

>>> scope of uniqueness. It looks to me that until now the PRID only had 
>>> to be unique among PRID values issued by the same PNS. (At least if 
>>> we assume that a given UA only uses one PNS.) But the new text for 
>>> subscription dialogs expands the requirement. Now the PRID must be unique 
>>> among all dialogs managed by the push proxy. These might involve multiple PNSs.
>>>
>>> since the format is left entirely up to the PNS. I think this needs more consideration.
>> 
> Certainly more info there is needed. But I also think more needs to be said up front and first specification of PRID, 
> that global uniqueness is required, across *all* PNSs. But beyond that, I don't see how it can be left to each individual 
> PNS to specify how it is going to guarantee that its values are unique from those of other PNSs. Seems like each PNS needs 
> to have a distinct namespace somehow.

Even though I think that PRIDs will be globally unique in reality, we can't mandate in the speciation. But, for normal push cases that is not a problem, since there are additional pn- parameters.

Anyway, if people are ok with Roman's suggestion of the proxy generating a random value (not a gruu) I think that would probably be a better solution. 

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 17 Sep 2018 16:01:38 -0400

On Mon, Sep 17, 2018 at 3:58 PM, Christer Holmberg <
[email-masked]> wrote:

> unique
> said up front and first specification of PRID,
> > that global uniqueness is required, across *all* PNSs. But beyond that,
> I don't see how it can be left to each individual
> > PNS to specify how it is going to guarantee that its values are unique
> from those of other PNSs. Seems like each PNS needs
> Even though I think that PRIDs will be globally unique in reality, we
> can't mandate in the speciation. But, for normal push cases that is not a
> problem, since there are additional pn- parameters.
>
> Anyway, if people are ok with Roman's suggestion of the proxy generating a
> random value (not a gruu) I think that would probably be a better solution.
>

I am definitely ok with it.

Also, as you mentioned earlier, since the new id carries no personally
identifiable information, it can be left in the SUBSCRIBE dialog contact,
which removes the need to for extra parameters in Record-Route. It also has
an additional benefit that makes long dialog support optional on the proxy
side.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Sep 2018 20:29:08 -0400

> Anyway, if people are ok with Roman's suggestion of the proxy generating a random value (not a gruu) I think that would probably be a better solution.

Yes, I agree it is a better solution.

	Thanks,
	Paul