Subject: [sipcore] SIP Push with SIP notifications: Way forward

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 07:30:43 +0000

Hi,

In order to be able to move the SIP Push draft forward, I see two
alternatives for addressing the NOTIFY issue raised by Ben and Robert.

Alternative 1:
--------------

We allow the pn- parameters in dialogs where there is a chance that the
SIP UA may be asleep when inbound requests (e.g., NOTIFY) arrive, assuming
that:

- the pn- parameters alone cannot be used to trigger push notifications;
and/or
- the remote peer (the notifier in case of SUB/NOT) is considered trusted.

Other cases would not be supported by the draft.

This alternative could be implemented in the current draft.

Alternative 2:
--------------

We want to do something else in order to support NOTIFY.

This alternative should be implemented in a separate draft.

I am ok adding text for Alternative 1, but I would not want to hold the
current draft if we decided to go for Alternative 2.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Aug 2018 09:50:59 -0500

Option 1, and I don't understand "other cases would not be supported".

You've decided to try to solve this problem at the SIP layer, and it 
needs to work with SIP. All of it - there needn't be anything special 
about MESSAGE or NOTIFY - you need to be able to deal with any SIP 
request. I think you're pretty close.

RjS

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Aug 2018 10:00:13 -0500

Hi Christer,

I’m skeptical about Alternative 2. If the solution for mid-dialog is more complicated than just “leave the push parameters in the contact URI”, then it could be hard to retrofit a mid-dialog solution in after the fact.

For alternative 1, I think we need some clearer thought around the privacy implications behind sharing the push parameters.

Ben.

> On Aug 30, 2018, at 2:30 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 15:35:27 +0000

Hi Robert,

>You've decided to try to solve this problem at the SIP layer, and it needs to work with SIP. All >of it - there needn't be anything special about MESSAGE or NOTIFY - you need to be able to >deal with any SIP request. I think you're pretty close.

MESSAGE is an out-of-dialog request, so it works with the current version of the draft.

Regards,

Christer

On 8/30/18 2:30 AM, Christer Holmberg wrote:
> We allow the pn- parameters in dialogs where there is a chance that 
> the SIP UA may be asleep when inbound requests (e.g., NOTIFY) arrive, 
> assuming
> that:
>
> - the pn- parameters alone cannot be used to trigger push 
> notifications; and/or
> I am ok adding text for Alternative 1, but I would not want to hold 
> the current draft if we decided to go for Alternative 2.
>
>
> Regards,
>
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 15:40:26 +0000

Hi,

Alternative 3 would be for the push proxy to return some random value to the UA in the REGISTER response, that is then included in the contact of the SUBSCRIBE. Then, when the NOTIFY arrives, the push proxy can map that to the registration and  request a push notification. There would be no impacts on the home proxy, and it does not require the home proxy to be in the path of the dialog.

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 30 August 2018 18:00
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]; [email-masked]; Robert Sparks <[email-masked]>
Subject: Re: SIP Push with SIP notifications: Way forward

Hi Christer,

Ben.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Aug 2018 11:24:48 -0500

Inline

Sent from my iPhone

> On Aug 30, 2018, at 10:35 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Robert,
> 

That was an odd comment to make in response to what I said. I understand your sentence in isolation, but I cant figure out how it applies to my comment.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 16:32:55 +0000

Hi,

>>> You've decided to try to solve this problem at the SIP layer, and it needs to work with SIP. All of it - there needn't be anything special 
>>> about MESSAGE or NOTIFY - you need to be able to >deal with any SIP request. I think you're pretty close.
>> 

You said that there needn't be anything special about MESSAGE, so I just wanted to clarify that there isn't anything special about MESSAGE. I am sorry if I misunderstood your comment.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Aug 2018 12:35:10 -0400

On Thu, Aug 30, 2018 at 11:40 AM, Christer Holmberg <
[email-masked]> wrote:

> Alternative 3 would be for the push proxy to return some random value to
> the UA in the REGISTER response, that is then included in the contact of
> the SUBSCRIBE. Then, when the NOTIFY arrives, the push proxy can map that
> to the registration and  request a push notification. There would be no
> impacts on the home proxy, and it does not require the home proxy to be in
> the path of the dialog.
>

Once again -- we are reinventing GRUU here. I think, the best solution is
to require that GRUU is used when a long duration dialog needs to be
supported. This way, when UA sends a SUBSCRIBE, it will include GRUU in the
Contact, which can be used to match the registration. Push proxy can use
this information to associate SUBSCRIBE dialog with Registration and push
notification settings.

Furthermore, GRUU is kind of required for long duration dialogs anyway,
since client IP has a tendency to change when client goes to sleep. GRUU
allows UA to recover the dialog when UA address changes when it wakes up.

Regards,
_____________
Roman Shpount

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Aug 2018 11:42:31 -0500

Sent from my iPhone

> On Aug 30, 2018, at 11:32 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

To clarify, there shouldnt be anything special about NOTIFY, INFO, or any other existing or potential future SIP request, in or out of dialog. 

There _is_ something special about MESSAGE if it works and other requests do not. 

RjS

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Aug 2018 13:18:07 -0400

On Thu, Aug 30, 2018 at 12:42 PM, Robert Sparks <[email-masked]>
wrote:

>
> To clarify, there shouldnt be anything special about NOTIFY, INFO, or any
> other existing or potential future SIP request, in or out of dialog.
>

There is nothing special about MESSAGE, but in and out of dialog requests
are different. Out of dialog requests are sent to AOR. In dialog requests
are sent to dialog contact. Based on the SIP Push draft, AOR has push
notification settings associated with it during registration. This means
any out of dialog requests sent to AOR have access to push notification and
can wake up the UA. In dialog requests, in generic case are sent directly
to the UA bypassing the proxies and have no access to push notification
settings. Because of this, if UA is suspended when this message is sent, it
will not receive it. During call dialog UA is normally awake since it is
receiving and sending media, so messages in call related dialogs should
operate normally. During SUBSCRIBE dialog UA is generally suspended.
Because of this, any messages in a dialog where client can be suspended
must be sent through a push proxy and must be associated with the
registration so that push notification settings can be retrieved. You can
design million ways to do this, but the standard compliant way is to
require UA to use GRUU when starting long duration dialog where UA can be
suspended. Push proxy must add itself to the Record-Route set of the dialog
so all the subsequent messages in this dialog go through it. When it
receives the message in such long duration dialog, it pulls the
registration information based on GRUU and issues push notification to wake
up the client.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 18:15:52 +0000

Hi,

>> Alternative 3 would be for the push proxy to return some random value to the UA in the REGISTER response, that is 
>> then included in the contact of the SUBSCRIBE. Then, when the NOTIFY arrives, the push proxy can map that to the 
>> registration and  request a push notification. There would be no impacts on the home proxy, and it does not require 
>> the home proxy to be in the path of the dialog.
>
> Once again -- we are reinventing GRUU here. I think, the best solution is to require that GRUU is used when a long 
> duration dialog needs to be supported. This way, when UA sends a SUBSCRIBE, it will include GRUU in the Contact, 
> which can be used to match the registration. Push proxy can use this information to associate SUBSCRIBE dialog with 
> Registration and push notification settings.
>
> Furthermore, GRUU is kind of required for long duration dialogs anyway, since client IP has a tendency to change when 
> client goes to sleep. GRUU allows UA to recover the dialog when UA address changes when it wakes up.

If operators support GRUU, they can use it. But, I don't think we shall mandate people to implement GRUU in order to make SIP Push work. 

And, the "random value" does not need to have the properties of a GRUU: it does not have to be globally unique, and it does not have to globally routable - it only needs to be unique within the push proxy, so it can be mapped to a registration.

Regards

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 18:18:32 +0000

Hi,

>>>>> You've decided to try to solve this problem at the SIP layer, and 
>>>>> it needs to work with SIP. All of it - there needn't be anything special about MESSAGE or NOTIFY - you 
>>>>> need to be able to >deal with any SIP request. I think you're pretty close.
>>>> 
>>> That was an odd comment to make in response to what I said. I understand your sentence in 
>>> isolation, but I cant figure out how it applies to my comment. 
>> 
>> You said that there needn't be anything special about MESSAGE, so I just wanted to clarify that 
>> there isn't anything special about MESSAGE. I am sorry if I misunderstood your comment.
>

I would say there is something special about NOTIFY, because the is what we are having a problem with :)

Anyway, there is no idea spending time arguing about that. Let's instead see how/if we can make NOTIFY work.

Regards,

Christer

>>> the SIP UA may be asleep when inbound requests (e.g., NOTIFY) 
>>> arrive, assuming
>>> that:
>>>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 30 Aug 2018 13:20:35 -0500

> Anyway, there is no idea spending time arguing about that. Let's instead see how/if we can make NOTIFY work.
Do you see issues with proceeding with Roman's suggestions? They seem to 
be going the right direction to me.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 18:31:04 +0000

Hi,

>>>>>>> it needs to work with SIP. All of it - there needn't be anything 
>>>>>>> special about MESSAGE or NOTIFY - you need to be able to >deal with any SIP request. I think you're pretty close.
>>>>> That was an odd comment to make in response to what I said. I 
>>>>> understand your sentence in isolation, but I cant figure out how it applies to my comment.
>>>> You said that there needn't be anything special about MESSAGE, so I 
>>>> just wanted to clarify that there isn't anything special about MESSAGE. I am sorry if I misunderstood your comment.
>Do you see issues with proceeding with Roman's suggestions? They seem to be going the right direction to me.

If operators already support GRUU, I think it could be used. 

But, I don't think we should mandate operators to implement GRUU just for this. Instead I think the push proxy could just return a random value to the UA, that is then included in the SUBSCRIBE, and can be used by the push proxy to map an in-dialog requests (e.g., NOTIFY) to a registration (in the same way the push proxy would use a GRUU).

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Aug 2018 14:31:49 -0400

On Thu, Aug 30, 2018 at 2:15 PM, Christer Holmberg <
[email-masked]> wrote:

> If operators support GRUU, they can use it. But, I don't think we shall
> mandate people to implement GRUU in order to make SIP Push work.
>
> And, the "random value" does not need to have the properties of a GRUU: it
> does not have to be globally unique, and it does not have to globally
> routable - it only needs to be unique within the push proxy, so it can be
> mapped to a registration.
>

GRUU is something returned from the registration server which UA needs to
put in the contact. Your proposed random value is something that UA needs
to add to the contact. As far as UA is concerned, this is the same amount
of work. As far as server implementation is concerned, GRUU can be
implemented as AOR with your random string added as a parameter. This gets
you all the GRUU properties you need, so server implementation wise it is
the same. As far as specification or implementation support is concerned,
GRUU is better since it already well defined, solves a number of other
existing problems, and deals with privacy and fingerprinting issues.

To summarize, I do not think we need yet another unique registration ID for
push.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2018 18:44:47 +0000

Hi,

>> If operators support GRUU, they can use it. But, I don't think we shall mandate people to 
>> implement GRUU in order to make SIP Push work. 
>>
>> And, the "random value" does not need to have the properties of a GRUU: it does not 
>> have to be globally unique, and it does not have to globally routable - it only needs to be 
>> unique within the push proxy, so it can be mapped to a registration.
>
> GRUU is something returned from the registration server which UA needs to put in the contact. 
> Your proposed random value is something that UA needs to add to the contact. As far as UA is concerned, 
> this is the same amount of work.

Yes, but it does not impact the registrar. 

> As far as server implementation is concerned, GRUU can be implemented as AOR with your random 
> string added as a parameter. This gets you all the GRUU properties you need, so server implementation 
> wise it is the same. As far as specification or implementation support is concerned, GRUU is better since 
> it already well defined, solves a number of other existing problems, and deals with privacy and fingerprinting issues.

And if operators need a solution to those problems they may implement GRUU. It is not up to us to decide.

As I said in the beginning of this work, in order to make a standardized solution a success, I strongly believe that we should avoid impacting the registrar, or the home proxy. Updating those are big and long-lasting projects in most cases.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Aug 2018 14:07:39 -0400

Christer,

On Fri, Aug 31, 2018 at 2:03 PM, Christer Holmberg <
[email-masked]> wrote:

> I was thinking that, in the case where the registrar does not support
> GRUU, the proposed "random value" returned to the UA by the push proxy
> could be considered a locally constructed GRUU. Then, when the UA sends a
> request for a dialog (e.g., SUBSCRIBE), it would always include the GRUU in
> the Contact of the request , and when the push proxy receives an inbound
> mid-dialog request (e.g., NOTIFY), it would always look for the GRUU in
> order to map the request to the registration.
>

Yes, this is exactly what I thought. If registrar does not support GRUU,
push proxy can generate a local GRUU which includes the extra parameters it
needs. If UA supports GRUU it will use the push proxy generated GRUU. This
way GRUU support is only needed on the client, which I assume is new since
it needs to support new push draft.

What do you think?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Aug 2018 18:03:16 +0000

Hi,

I was thinking that, in the case where the registrar does not support GRUU, the proposed "random value" returned to the UA by the push proxy could be considered a locally constructed GRUU. Then, when the UA sends a request for a dialog (e.g., SUBSCRIBE), it would always include the GRUU in the Contact of the request , and when the push proxy receives an inbound mid-dialog request (e.g., NOTIFY), it would always look for the GRUU in order to map the request to the registration.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30 August 2018 21:45
To: Roman Shpount <[email-masked]>
Cc: Ben Campbell <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward

Hi,

>> If operators support GRUU, they can use it. But, I don't think we 
>> shall mandate people to implement GRUU in order to make SIP Push work.
>>
>> And, the "random value" does not need to have the properties of a 
>> GRUU: it does not have to be globally unique, and it does not have to 
>> globally routable - it only needs to be unique within the push proxy, so it can be mapped to a registration.
>
> Your proposed random value is something that UA needs to add to the 
> contact. As far as UA is concerned, this is the same amount of work.

> As far as server implementation is concerned, GRUU can be implemented 
> as AOR with your random string added as a parameter. This gets you all 
> the GRUU properties you need, so server implementation wise it is the 
> same. As far as specification or implementation support is concerned, GRUU is better since it already well defined, solves a number of other existing problems, and deals with privacy and fingerprinting issues.

Regards,

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Aug 2018 14:51:22 -0400

On 8/31/18 2:07 PM, Roman Shpount wrote:
> Christer,
> 
> On Fri, Aug 31, 2018 at 2:03 PM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     I was thinking that, in the case where the registrar does not
>     support GRUU, the proposed "random value" returned to the UA by the
>     push proxy could be considered a locally constructed GRUU. Then,
>     when the UA sends a request for a dialog (e.g., SUBSCRIBE), it would
>     always include the GRUU in the Contact of the request , and when the
>     push proxy receives an inbound mid-dialog request (e.g., NOTIFY), it
>     would always look for the GRUU in order to map the request to the
>     registration.
> 
> 
> push proxy can generate a local GRUU which includes the extra parameters 
> it needs. If UA supports GRUU it will use the push proxy generated GRUU. 
> This way GRUU support is only needed on the client, which I assume is 
> new since it needs to support new push draft.
> 
> What do you think?

I think this requires some careful thought!

By doing this, the push "proxy" becomes a B2BUA.

Also, would this be a temp gruu or permanent gruu. There are rules about 
the lifetimes of each.

And do recall that the "gr" in gruu means "globally routable". Will the 
resulting URL actually have that property?

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Aug 2018 19:18:16 +0000

Hi,

>> Yes, this is exactly what I thought. If registrar does not support 
>> GRUU, push proxy can generate a local GRUU which includes the extra 
>> parameters it needs. If UA supports GRUU it will use the push proxy generated GRUU.

Why do you think that? The push proxy would not modify the contact.

>Also, would this be a temp gruu or permanent gruu. There are rules about the lifetimes of each.
>
>And do recall that the "gr" in gruu means "globally routable". Will the resulting URL actually have that property?

I think it would be as routable as a locally constructed GRUU.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Aug 2018 15:56:42 -0400

> By doing this, the push "proxy" becomes a B2BUA.

You are correct. Proxy cannot modify Contact when it is passed through in
any direction without becoming B2BUA. Essentially, what we are missing
functionality to set UA Record-Route header set based on REGISTER 2XX
response. All we can do now is to set contact using GRUU. Unless I am
mistaken, since none of the headers proxy adds to REGISTER request get back
to UA, and since push proxy cannot add any headers to REGISTER response, in
order to pass any information from push proxy to UA, push proxy needs to
become B2BUA, .

> the lifetimes of each.

This would probably be a permanent GRUU, since it would not be updated on
every refresh. Ideally we would like to keep it when client suspends and
resumes, each of which will generate a new Registration refresh.

> resulting URL actually have that property?

Provided the push proxy has a public URI, which it needs to receive NOTIFY
message directly, this URI will be globally routable.

After thinking about this a bit more, I have a more general question: What
about UA initiated dialogs which occur from UA which are not registered? In
general case, UA can issue a SUBSCRIBE without doing a registration first.
How would messages to UA work in this case? One option is to insert pn-
parameters in the Contact header of such dialog creating request. Apart
from obvious privacy concerns, this should work.

Alternatively, what needs to happen is essentially double registration,
where UA needs to send pn- parameters to the push proxy and obtain the URI
which is pointed to the push proxy (sort of push version of GRUU). SIP UA
will use this new URI instead of its normal contact as a registration
contact or contact for any dialog creating requests it sends out. This way
you do not need Path or GRUU support on the registrar/home proxy.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Aug 2018 20:12:29 +0000

Hi,

I don’t think the proxy needs to modify the Contact. The proxy can provide a local GRUU e.g., using a media feature tag. That is my idea for providing the “random value” (no matter whether it is a GRUU or not).

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 31 August 2018 22:57
To: Paul Kyzivat <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] SIP Push with SIP notifications: Way forward

On Fri, Aug 31, 2018 at 2:51 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Yes, this is exactly what I thought. If registrar does not support GRUU, push proxy can generate a local GRUU which includes the extra parameters it needs. If UA supports GRUU it will use the push proxy generated GRUU. This way GRUU support is only needed on the client, which I assume is new since it needs to support new push draft.

You are correct. Proxy cannot modify Contact when it is passed through in any direction without becoming B2BUA. Essentially, what we are missing functionality to set UA Record-Route header set based on REGISTER 2XX response. All we can do now is to set contact using GRUU. Unless I am mistaken, since none of the headers proxy adds to REGISTER request get back to UA, and since push proxy cannot add any headers to REGISTER response, in order to pass any information from push proxy to UA, push proxy needs to become B2BUA, .

This would probably be a permanent GRUU, since it would not be updated on every refresh. Ideally we would like to keep it when client suspends and resumes, each of which will generate a new Registration refresh.

Provided the push proxy has a public URI, which it needs to receive NOTIFY message directly, this URI will be globally routable.

After thinking about this a bit more, I have a more general question: What about UA initiated dialogs which occur from UA which are not registered? In general case, UA can issue a SUBSCRIBE without doing a registration first. How would messages to UA work in this case? One option is to insert pn- parameters in the Contact header of such dialog creating request. Apart from obvious privacy concerns, this should work.

Alternatively, what needs to happen is essentially double registration, where UA needs to send pn- parameters to the push proxy and obtain the URI which is pointed to the push proxy (sort of push version of GRUU). SIP UA will use this new URI instead of its normal contact as a registration contact or contact for any dialog creating requests it sends out. This way you do not need Path or GRUU support on the registrar/home proxy.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Aug 2018 16:37:26 -0400

On Fri, Aug 31, 2018 at 4:12 PM, Christer Holmberg <
[email-masked]> wrote:

>
> I don’t think the proxy needs to modify the Contact. The proxy can provide
> a local GRUU e.g., using a media feature tag. That is my idea for providing
> the “random value” (no matter whether it is a GRUU or not).
>
>
>
Ok, we can define a new media feature tag that proxy can add to response
which will be used similar to permanent GRUU. The push enabled UA will use
value of this field as a contact for all dialog creating requests it will
send.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Aug 2018 16:52:04 -0400

On 8/31/18 4:37 PM, Roman Shpount wrote:
> On Fri, Aug 31, 2018 at 4:12 PM, Christer Holmberg 
>     I don’t think the proxy needs to modify the Contact. The proxy can
>     provide a local GRUU e.g., using a media feature tag. That is my
>     idea for providing the “random value” (no matter whether it is a
>     GRUU or not).____
> 
> 
> 
> which will be used similar to permanent GRUU. The push enabled UA will 
> use value of this field as a contact for all dialog creating requests it 
> will send.

Just be careful about calling it a gruu unless it actually has gruu 
properties.

	Thanks,
	Paul