Subject: [sipcore] Draft new version: SIP Push (-15)

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2018 09:45:17 +0000

Hi,

I have submitted a new version (-15) of SIP Push.

The draft now contains a new section (6.  Support Of Longlived SIP Dialogs), that describes a generic (not specific to NOTIFY) mechanism for mid-dialog SIP requests triggering push notifications.

The mechanism is based on the push proxy generating a unique value, provided to the UA during registration. The UA can then use the value when establishing dialogs, which will allow the push proxy to retrieve the push parameters when receiving a mid-dialog request.

Thanks to everyone who provided input and feedback!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2018 10:45:01 -0400

Christer,

The new changes seem workable.

There is one case that I think is not currently covered: when a UA that 
requires push support is the recipient of a dialog establishing request. 
It doesn't appear that the purk mechanism covers this case.

	Thanks,
	Paul

On 9/26/18 5:45 AM, Christer Holmberg wrote:
> The draft now contains a new section (6.  Support Of Longlived SIP 
> Dialogs), that describes a generic (not specific to NOTIFY) mechanism 
> for mid-dialog SIP requests triggering push notifications.
> 
> The mechanism is based on the push proxy generating a unique value, 
> provided to the UA during registration. The UA can then use the value 
> when establishing dialogs, which will allow the push proxy to retrieve 
> the push parameters when receiving a mid-dialog request.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 20:31:49 +0000

Hi,

> There is one case that I think is not currently covered: when a UA that requires push support 
> is the recipient of a dialog establishing request. 

The second paragraph of section 6.2.2 describes the proxy behaviour for that case.

Regards,

Christer

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Sep 2018 13:48:53 -0400

> The second paragraph of section 6.2.2 describes the proxy behaviour for that case.

Maybe I am not understanding, but I don't think this covers my case. I 
think 6.2.2 is talking about the case where a UA sends a request through 
the push proxy that supports it. I'm talking about the request coming 
the other way.

For instance:

1) Alice registers with her registrar and sets up all the push mechanism

2) Bob sends an INVITE to Alice.

3) Alice receives the INVITE, and decides it is a case where it might go 
to sleep mid-session and will need push notifications to wake up.

4) What does Alice to do get that set up ???

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Sep 2018 18:22:56 +0000

Hi,

>>> There is one case that I think is not currently covered: when a UA
>>> that requires push support is the recipient of a dialog establishing request.
> Maybe I am not understanding, but I don't think this covers my case. I think 6.2.2 is
> talking about the case where a UA sends a request through the push proxy that supports it.
>I'm talking about the request coming the other way.

The 1st paragraph talks about the proxy receiving an initial request sent by the UA. The 2nd paragraph talks about the proxy receiving an initial request addressed towards the UA.

>3) Alice receives the INVITE, and decides it is a case where it might go to sleep mid-session and will need push notifications to wake up.
>

That is covered in the first sentence of section 6.1.1.:

   "When the UA sends in initial request for a dialog, or a 2xx response
   to such requests, if the UA is willing to receive push notifications
   triggered by incoming mid-dialog requests, the UA MUST include a 'pn-
   purr' SIP URI parameter in the Contact header of the request or
   response."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Sep 2018 15:51:18 -0400

Christer,

On 9/29/18 2:22 PM, Christer Holmberg wrote:
> The 1st paragraph talks about the proxy receiving an initial request 
> sent by the UA. The 2nd paragraph talks about the proxy receiving an 
> initial request addressed towards the UA.
>>For instance:
>>
>     "When the UA sends in initial request for a dialog, *or a 2xx response*
> *   to such requests*, if the UA is willing to receive push notifications

Sorry - I have not been reading and thinking this through carefully enough.

I agree that the sections you have pointed to cover my case. This 
depends on the incoming INVITE having been addressed to the receiving 
UA's AOR, thus being translated to the registered contact that contains 
the pn params, and then traversing the push proxy that can use those pn 
params to locate the purr value. That does cover a lot of cases, but not 
all.

Consider another case:

2) Alice calls Bob (session C1) using purr to establish push notifications.

3) Bob send an INVITE/Replaces request to Alice using the Alice's 
contact address from C1.

The goal of introducing purr was to avoid having to disclose the pn 
params to other UAs. So the contact address won't have those pn 
parameters. But it will have the purr parameter. That should be enough, 
but I guess it may require more text to over an out of dialog request 
with a purr param.

The bigger problem is that this request may well not traverse the push 
proxy. That is a problem. This is one of the things that GRUUs were 
designed for. So it may be that this case is going to require a GRUU, 
which is exactly what we were trying to avoid with purr.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Sep 2018 20:05:06 +0000

Hi,

>>> Maybe I am not understanding, but I don't think this covers my case. 
>>>I think 6.2.2 is  talking about the case where a UA sends a request through the push proxy that supports it.
>>     "When the UA sends in initial request for a dialog, *or a 2xx 
>>      response** to such requests*, if the UA is willing to receive push 
>>      notifications triggered by incoming mid-dialog requests, the UA MUST include a 
>>      'pn-purr' SIP URI parameter in the Contact header of the request or
>>      response."
>
> I agree that the sections you have pointed to cover my case. This depends on the incoming INVITE having been 
> addressed to the receiving UA's AOR, thus being translated to the registered contact that contains the pn params, 
> and then traversing the push proxy that can use those pn params to locate the purr value. That does cover a lot 
> of cases, but not all.
>
> Consider another case:
>
> 3) Bob send an INVITE/Replaces request to Alice using the Alice's contact address from C1.
>
> The goal of introducing purr was to avoid having to disclose the pn params to other UAs. So 
> the contact address won't have those pn parameters. But it will have the purr parameter. That 
> should be enough, but I guess it may require more text to over an out of dialog request with a 
> purr param.
>
>The bigger problem is that this request may well not traverse the push proxy. That is a problem. 
>This is one of the things that GRUUs were designed for. So it may be that this case is going to 
>require a GRUU, which is exactly what we were trying to avoid with purr.

The draft doesn't specify HOW the purr is generated (as long as it is unique), and nothing prevents the proxy from giving "gruu-alike" properties to the purr.

Either that, or the operator will have to configure the network to ensure that such requests will traverse the proxy.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 Sep 2018 16:31:21 -0400

> Either that, or the operator will have to configure the network to ensure that such requests will traverse the proxy.

Then there are some strong constraints on URIs that Alice may use as the 
contact address in C1:

1) out of dialog requests addressed to it must traverse Alice's push 
proxy, and also preserve the purr param when it traverses that proxy;

2) or it must itself have GRUU properties, in that requests to it must 
traverse Alice's home proxy and then be translated to Alice's registered 
contact;

3) else out of dialog requests won't result in dialogs with push support.

Achieving (1) is very similar to implementing GRUU. It isn't easy to 
achieve.

ISTM it is necessary to at least explain all this, or else define a 
mechanism that guarantees this property. And I'm dubious that is 
appropriate to just leave it with a disclaimer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Sep 2018 21:44:37 +0000

Hi,

...

>>> parameters. But it will have the purr parameter. That should be 
>>> enough, but I guess it may require more text to over an out of dialog request with a purr param.
>>>
>>> This is one of the things that GRUUs were designed for. So it may be 
>>> that this case is going to require a GRUU, which is exactly what we were trying to avoid with purr.
>> 
>> The draft doesn't specify HOW the purr is generated (as long as it is unique), and nothing prevents 
>> the proxy from giving "gruu-alike" properties to the purr.
>> 
> Then there are some strong constraints on URIs that Alice may use as the contact address in C1:
>
> 1) out of dialog requests addressed to it must traverse Alice's push proxy, and also preserve the purr param when it traverses that proxy;
>
> 2) or it must itself have GRUU properties, in that requests to it must traverse Alice's home proxy and then be translated to Alice's registered contact;
>
> Achieving (1) is very similar to implementing GRUU. It isn't easy to achieve.
>
> ISTM it is necessary to at least explain all this, or else define a mechanism that guarantees this property. 
> And I'm dubious that is appropriate to just leave it with a disclaimer.

This is not push specific. There are other cases (e.g., related to NAT traversal) where you need to make sure requests traverse a specific proxy.

But, I will think of some text.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sun, 30 Sep 2018 23:19:16 -0400

On Sun, Sep 30, 2018 at 5:44 PM Christer Holmberg <
[email-masked]> wrote:

> This is not push specific. There are other cases (e.g., related to NAT
> traversal) where you need to make sure requests traverse a specific proxy.
>
>
And the only way to solve all of them is GRUU. Everything else breaks down
at some point. For instance INVITE with Replaces is very hard to get to
work right without GRUU.

One thing that worked for us when something like this was required (i.e.
server for hosted NAT traversal and push) was to use B2BUA for registration
instead of proxy. What this means is UA registers with B2BUA, B2BUA
modifies registration contact to its own generated URL and registers with
normal Register server. When response is received, B2BUA modifies the
contact back to client actual contact and adds GRUU (which points to a URI
on B2BUA server).  All requests to AOR for this client or requests in or
out of the dialog (GRUU) are guaranteed to got though this B2BUA which can
then do its NAT/Push magic.

This is how a lot of SBC work. This is what likely is going to be
implemented but not what is going to be standardized. For this SBC to work
you might need a standard mechanism to pass push notification parameters
from the UA to SBC, which this draft already provides. The rest that we are
inventing here is an excise to see if complete standard proxy based
solution is possible (which is unlikely), but it is unlikely this proxy
based solution will ever be used.

So, can we limit the scope to what is needed (passing push parameters in
registration) and move on?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Oct 2018 04:53:26 +0000

Hi,

There will be proxy based solutions deployed.

Operators need to configure their network so that routing is done correctly.

So, while I’m happy to add some text about the Replaces case, I do agree that we should move on.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 01 October 2018 06:19
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] Draft new version: SIP Push (-15)

On Sun, Sep 30, 2018 at 5:44 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
This is not push specific. There are other cases (e.g., related to NAT traversal) where you need to make sure requests traverse a specific proxy.

And the only way to solve all of them is GRUU. Everything else breaks down at some point. For instance INVITE with Replaces is very hard to get to work right without GRUU.

One thing that worked for us when something like this was required (i.e. server for hosted NAT traversal and push) was to use B2BUA for registration instead of proxy. What this means is UA registers with B2BUA, B2BUA modifies registration contact to its own generated URL and registers with normal Register server. When response is received, B2BUA modifies the contact back to client actual contact and adds GRUU (which points to a URI on B2BUA server).  All requests to AOR for this client or requests in or out of the dialog (GRUU) are guaranteed to got though this B2BUA which can then do its NAT/Push magic.

This is how a lot of SBC work. This is what likely is going to be implemented but not what is going to be standardized. For this SBC to work you might need a standard mechanism to pass push notification parameters from the UA to SBC, which this draft already provides. The rest that we are inventing here is an excise to see if complete standard proxy based solution is possible (which is unlikely), but it is unlikely this proxy based solution will ever be used.

So, can we limit the scope to what is needed (passing push parameters in registration) and move on?

Regards,
_____________
Roman Shpount