Subject: [sipcore] SIP Push with SIP notifications [was: SIP Push: Pull Request based on Ben's AD review]

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Aug 2018 16:58:06 +0000

Hi,

I have changed the subject, because after having discussions with some people I have realized that this is actually a larger issue.

First, assuming the SIP UA has gone to sleep (and needs to be awaken) since it sent SUBSCRIBE, NOTIFY does *not* currently work with SIP Push. 

The reason is that the contact of the SUBSCRIBE does not contain the pn- parameters. The draft forbids that, due to privacy reasons. So, the NOTIFY will not contain the pn- parameters either, and the proxy will not be able to request a push notification.

We could of course change that, and allow the pn- parameters in the SUBSCRIBE, but then we would have the privacy issues.

One solution that has been discussed is that the proxy provides some kind of "registration identifier" to the SIP UA during registration - an arbitrary value without any user-sensitive informtaion that the proxy can map to a registration. The SIP UA can then include it in the contact of the SUBSCRIBE. Then, when the proxy receives the NOTIFY, it can map the identifier to the registration (and the associated pn- parameters), and request a push notification.

Second, having said that, when SIP NOTIFY have been discussed with operators etc, there doesn't seem to be an interest in using SIP notifications with SIP push notifications to begin with: using a push notification in order to receive a SIP notification is considered a little strange. 

Instead, people only want to use push notifications, and have been talking about some kind of "interworking" between SIP notifications and push notifications, since they do think that push UAs and non-push UAs should be able to use the same notification service. Perhaps that is something we should look into - in a separate draft?

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: 28 August 2018 01:05
To: Robert Sparks <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] SIP Push: Pull Request based on Ben's AD review

> On Aug 27, 2018, at 4:57 PM, Robert Sparks <[email-masked]> wrote:
> 
> 
> 
> On 8/27/18 3:33 PM, Ben Campbell wrote:
>> The pull request (is that a push-pull request :-) ) looks good to me.
>> 
>> I have one remaining question: I recall someone (I think it was Robert) asked about inbound mid-dialog requests, in particular, NOTIFY. Was that question resolved? I can imagine a client going to sleep during a long-lived dialog.
>> 
> Yes, but based on your followup question to me offline, there is text that needs to change in the document.
> 
> Christer - if you read what you currently have written, no mid-dialog request is accounted for (and by implication allowed). Ben, at least, read it to mean you can't _use_ push on mid-dialog requests. I don't think that's what you had in mind.
> 

To be clear, I didn't necessarily read it as _forbidding_  sending a push notification on a mid-dialog request. But it does not specify that you can, either.

Ben.

> I made a very quick attempt at an edit that would address this - let me know if I'm wrong about your intent.
> See <https://github.com/cdh4u/draft-sip-push/pull/21>
> 
> RjS
> 
> 
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> 
>>> On Aug 26, 2018, at 9:18 AM, Christer Holmberg <[email-masked]>
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Based on Ben’s AD review, I have created a pull request.
>>> 
>>> 
>>> https://github.com/cdh4u/draft-sip-push/pull/20
>>> 
>>> 
>>> The following clarifications/modifications have been done:
>>> 
>>> -          s/awake/wake
>>> -          Note that SIP UA vapid specific procedures are outside the scope of the document
>>> -          Note that proxy needs to be between UA and home proxy in order to be able to match the R-URI of SIP requests with a binding contact
>>> -          Clarification that R-URI matching is done against the contact in REGISTER request (but that the contact still need to be present in the REGISTER response)
>>> -          Clarification that if a SIP UA has multiple bindings associated with a push notification subscription, it needs to send a binding refresh REGISTER for each of them when receiving a push notification
>>> -          Clarification that the typical value of 2 seconds might be impacted by PNS- and network characteristics.
>>> -          Modification of requirement to secure the SIP signalling
>>> 
>>> The following issues are yet not addressed in the PR:
>>> 
>>> -          The 556 response code has not been removed
>>> -          The IANA policy is still Expert Review
>>> 
>>> The reason is because I still wait for some input from Ben in the e-mail thread.
>>> 
>>> In addition, I have not yet done any generic clean up/clarification.
>>> 
>>> Ben, please let me know if there is something I have forgotten :)
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>> 
>> 
>> _______________________________________________
>> sipcore mailing list
>> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Ben Campbell <[email-masked]>
Date: Tue, 28 Aug 2018 12:12:58 -0500

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

Can you describe the privacy issue? That is, what is the privacy issue with the PRID that doesn’t already exist in the remote contact? Would someone who got the PRID be able to insert push notifications? What is the typical lifetime of a PRID?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Aug 2018 17:31:50 +0000

Hi,

>> The reason is that the contact of the SUBSCRIBE does not contain the pn- parameters. The draft forbids that, due to privacy reasons. 
>> So, the NOTIFY will not contain the pn- parameters either, and the proxy will not be able to request a push notification.
>> 
> Can you describe the privacy issue? That is, what is the privacy issue with the PRID that doesn’t already exist in the remote contact? 

I would have to check the archive, but I think it was something we added just in case, without really discussing it :)

Of course, in many environments the SIP Notifier is considered trusted, so it would not be an issue if it receives the PRID.

> Would someone who got the PRID be able to insert push notifications?

I would have to double check that. You obviously need PNS credentials in order to request push notifications, but anyone can get those.

(If the PNS supports VAPID, it can be used to prevent others from inserting push notifications even if they have all the information needed to do it.)

> What is the typical lifetime of a PRID?

I would have to double check that too. It may change between PNSs, but I would assume it typically does not change until the client re-boots (and re-registers with the PNS).

When a client does re-boot/re-registers, my understanding is that a new PRID is always assigned.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Aug 2018 15:47:15 -0400

Hi,

On Tue, Aug 28, 2018 at 12:58 PM, Christer Holmberg <
[email-masked]> wrote:

> First, assuming the SIP UA has gone to sleep (and needs to be awaken)
> since it sent SUBSCRIBE, NOTIFY does *not* currently work with SIP Push.
>
> The reason is that the contact of the SUBSCRIBE does not contain the pn-
> parameters. The draft forbids that, due to privacy reasons. So, the NOTIFY
> will not contain the pn- parameters either, and the proxy will not be able
> to request a push notification.
>
> We could of course change that, and allow the pn- parameters in the
> SUBSCRIBE, but then we would have the privacy issues.
>
> One solution that has been discussed is that the proxy provides some kind
> of "registration identifier" to the SIP UA during registration - an
> arbitrary value without any user-sensitive informtaion that the proxy can
> map to a registration. The SIP UA can then include it in the contact of the
> SUBSCRIBE. Then, when the proxy receives the NOTIFY, it can map the
> identifier to the registration (and the associated pn- parameters), and
> request a push notification.
>

Are you re-inventing GRUU here? Contact for SUBSCRIBE should be GRUU
obtained from the Register server. Push enabled proxy can encode necessary
information in the GRUU or simply use GRUU to lookup this information.

I do agree that using SIP NOTIFY with Push notifications is a bit
excessive, but generally handling mid-dialog requests for a suspended
dialog can be solved using GRUU and Record-Route/Route headers which will
maintain relationship between the push notification parameters and SIP
messages.

Regards,
______________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Aug 2018 16:19:16 -0400

On 8/28/18 3:47 PM, Roman Shpount wrote:
> Hi,
> 
> On Tue, Aug 28, 2018 at 12:58 PM, Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     First, assuming the SIP UA has gone to sleep (and needs to be
>     awaken) since it sent SUBSCRIBE, NOTIFY does *not* currently work
>     with SIP Push.
> 
>     The reason is that the contact of the SUBSCRIBE does not contain the
>     pn- parameters. The draft forbids that, due to privacy reasons. So,
>     the NOTIFY will not contain the pn- parameters either, and the proxy
>     will not be able to request a push notification.
> 
>     One solution that has been discussed is that the proxy provides some
>     kind of "registration identifier" to the SIP UA during registration
>     - an arbitrary value without any user-sensitive informtaion that the
>     proxy can map to a registration. The SIP UA can then include it in
>     the contact of the SUBSCRIBE. Then, when the proxy receives the
>     NOTIFY, it can map the identifier to the registration (and the
>     associated pn- parameters), and request a push notification.
> 
> 
> obtained from the Register server. Push enabled proxy can encode 
> necessary information in the GRUU or simply use GRUU to lookup this 
> information.
> 
> dialog can be solved using GRUU and Record-Route/Route headers which 
> will maintain relationship between the push notification parameters and 
> SIP messages.

First, please keep in mind that in general you can't assume that the 
home proxy for a UA is on the path for in-dialog requests. If not, that 
could cause problems for using Push.

OTOH, if the UA is using a registrar-assigned GRUU as its contact for 
the dialog, then that is probably the home proxy or at least is in 
cooperation with the registrar, hence fixing the problem.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Aug 2018 20:21:26 +0000

Hi,

>> The reason is that the contact of the SUBSCRIBE does not contain the pn- parameters. The draft forbids 
>> that, due to privacy reasons. So, the NOTIFY will not contain the pn- parameters either, and the proxy will 
>> not be able to request a push notification.
>>
>> One solution that has been discussed is that the proxy provides some kind of "registration identifier" to 
>> the SIP UA during registration - an arbitrary value without any user-sensitive information that the proxy can 
>> map to a registration. The SIP UA can then include it in the contact of the SUBSCRIBE. Then, when the proxy 
>> receives the NOTIFY, it can map the identifier to the registration (and the associated pn- parameters), and 
> Are you re-inventing GRUU here? 

No. I presented the option on a functional level. Didn't want to go into the protocol details :)

Regards,

Christer

---

From: Richard Shockey <[email-masked]>
Date: Tue, 28 Aug 2018 18:32:42 -0400

OK guys I have a more fundamental question.  What is all of this fuss about...really!

What is the use case for PUSH?  I'm totally confused, certainly ignorant.

What are you folks trying to do ..is this some 3GPP thing?  I'm legitimately confused and befuddled.

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 8/28/18, 4:21 PM, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    Regards,
    
    Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Aug 2018 20:50:39 -0400

Hi Richard,

On certain fruit themed mobile devices, application cannot wake up on timer
or on network packet. The only way to wake up the application is to send a
push notification using proprietary vendor-approved push protocol. VoIP
clients on such devices typically register for push notifications when
doing SIP registration. When call needs to be placed to such device, push
notification is sent first to wake up the device. When device wakes up, it
re-registers which triggers SIP INVITE being sent to the device over the
connection established using REGISTER. Nothing to do with 3GPP. There are
multiple hacked together implementations of this on the market. Christer
decided that a draft describing how to implement such signaling scenario is
needed.

If you want, I can get on the call and describe in more details.

Regards,

_____________
Roman Shpount

On Tue, Aug 28, 2018 at 6:32 PM, Richard Shockey <[email-masked]> wrote:

> On 8/28/18, 4:21 PM, "sipcore on behalf of Christer Holmberg" <
> [email-masked] on behalf of [email-masked]>
> wrote:
>
>     Hi,
>
> awaken) since it sent SUBSCRIBE, NOTIFY
>     >> does *not* currently work with SIP Push.
>     >>
>     >> that, due to privacy reasons. So, the NOTIFY will not contain the
> pn- parameters either, and the proxy will
>     >> One solution that has been discussed is that the proxy provides
> some kind of "registration identifier" to
>     >> the SIP UA during registration - an arbitrary value without any
> user-sensitive information that the proxy can
>     >> map to a registration. The SIP UA can then include it in the
> contact of the SUBSCRIBE. Then, when the proxy

---

From: Roman Shpount <[email-masked]>
Date: Tue, 28 Aug 2018 21:00:36 -0400

On Tue, Aug 28, 2018 at 4:19 PM, Paul Kyzivat <[email-masked]> wrote:

> First, please keep in mind that in general you can't assume that the home
> proxy for a UA is on the path for in-dialog requests. If not, that could
> cause problems for using Push.
>
> OTOH, if the UA is using a registrar-assigned GRUU as its contact for the
> dialog, then that is probably the home proxy or at least is in cooperation
> with the registrar, hence fixing the problem.
>

If separate Home Proxy is used, Registrar must support registration path
extension (RFC 3327) or things will break.

In general, if a complete standard compliant solution is needed, we should
have taken RFC 5626 and RFC 5627 and updated it to use push. Christer
thought this would be an overkill and opted for a simpler solution. This
resulted in some scenarios being unsupported or under-specified. Since
current draft covers the use cases Christer is currently interested in,
other scenarios can be covered in other drafts or subsequent versions of
this draft.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 06:16:55 +0000

Hi,

> In general, if a complete standard compliant solution is needed, we
>should have taken RFC 5626 and RFC 5627 and updated it to use push.
>Christer thought this would be an overkill and opted for a
> simpler solution. This resulted in some scenarios being unsupported or
>under-specified. Since current draft covers the use cases Christer is
>currently interested in, other scenarios can be covered in other drafts or
> subsequent versions of this draft.

Correct.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 13:57:43 +0000

Hi,

Maybe I am missing something, but we do the home proxy need to be in the path of mid-dialog requests in order for push to work?

The draft currently doesn’t define any push-specific procedures for the home proxy.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 29 August 2018 04:01
To: Paul Kyzivat <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] SIP Push with SIP notifications [was: SIP Push: Pull Request based on Ben's AD review]

On Tue, Aug 28, 2018 at 4:19 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
First, please keep in mind that in general you can't assume that the home proxy for a UA is on the path for in-dialog requests. If not, that could cause problems for using Push.

OTOH, if the UA is using a registrar-assigned GRUU as its contact for the dialog, then that is probably the home proxy or at least is in cooperation with the registrar, hence fixing the problem.

If separate Home Proxy is used, Registrar must support registration path extension (RFC 3327) or things will break.

In general, if a complete standard compliant solution is needed, we should have taken RFC 5626 and RFC 5627 and updated it to use push. Christer thought this would be an overkill and opted for a simpler solution. This resulted in some scenarios being unsupported or under-specified. Since current draft covers the use cases Christer is currently interested in, other scenarios can be covered in other drafts or subsequent versions of this draft.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Aug 2018 11:42:53 -0400

On 8/29/18 9:57 AM, Christer Holmberg wrote:
> Hi,
> 
> Maybe I am missing something, but we do the home proxy need to be in the 
> path of mid-dialog requests in order for push to work?
> 

I haven't been following this closely, but isn't the home proxy the one 
that triggers the push?

At least *something* needs to be on that path to do it. For 
registrations we know the registrar is on the path. But for this 
mid-dialog case there is no guarantee that there is *anything* between 
the the two UAs that have the dialog. (I know the situation is different 
in IMS.)

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Roman 
> Shpount
> *Sent:* 29 August 2018 04:01
> *To:* Paul Kyzivat <[email-masked]>
> *Cc:* SIPCORE <[email-masked]>
> *Subject:* Re: [sipcore] SIP Push with SIP notifications [was: SIP Push: 
> Pull Request based on Ben's AD review]
> 
>     home proxy for a UA is on the path for in-dialog requests. If not,
>     that could cause problems for using Push.
> 
>     OTOH, if the UA is using a registrar-assigned GRUU as its contact
>     for the dialog, then that is probably the home proxy or at least is
>     in cooperation with the registrar, hence fixing the problem.
> 
> Christer thought this would be an overkill and opted for a simpler 
> solution. This resulted in some scenarios being unsupported or 
> currently interested in, other scenarios can be covered in other drafts 
> or subsequent versions of this draft.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 16:38:46 +0000

Hi,

>> Maybe I am missing something, but we do the home proxy need to be in 
>> the path of mid-dialog requests in order for push to work?
>> 
>I haven't been following this closely, but isn't the home proxy the one that triggers the push?
>
>At least *something* needs to be on that path to do it. For registrations we know the registrar is on the path. 
>But for this mid-dialog case there is no guarantee that there is *anything* between the the two UAs that have the 
>dialog. (I know the situation is different in IMS.)

If we don't consider the NOTIFY case (where a push notification would need to be requested), from a SIP push perspective (not considering NAT traversal etc) in my opinion there doesn't have to be anything  between the UAs - including the push proxy.

If we do consider the NOTIFY case (where a push notification do need to be requested), the push proxy obviously needs to be on the path. But, based on the solution proposals we've discussed so far I see no requirement for anything else to be in the path between the UAs.

Regards,

Christer

> If separate Home Proxy is used, Registrar must support registration 
> path extension (RFC 3327) or things will break.
> 
> currently interested in, other scenarios can be covered in other 
> drafts or subsequent versions of this draft.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 Aug 2018 12:45:34 -0400

> path of mid-dialog requests in order for push to work?

Short answer is that if UA is expected to stay awake during the dialog,
home proxy does not need to be on the path of mid-dialog requests. So no
need for call dialogs, but will be needed for SUBSCRIBE notifications, if
supported by this draft (they are not so far). In our case, we had to
implement this for SUBSCRIBE to support voice mail status notifications.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 17:10:19 +0000

Hi,

> Short answer is that if UA is expected to stay awake during the dialog, home proxy does not need to be on the path of mid-dialog requests.

Too short answer, because you don't explain WHY the home proxy needs to be on the path :)

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 Aug 2018 13:41:34 -0400

On Wed, Aug 29, 2018 at 1:10 PM, Christer Holmberg <
[email-masked]> wrote:

> home proxy does not need to be on the path of mid-dialog requests.
>

Actually, most of the UA that will require SIP Push are located on NATed
networks. If you are doing server side NAT traversal or sip outbound, SIP
requests should be sent over the same transport/address/port 5-tuple as the
one used to receive REGISTER messages. Because of this, home proxy would
need to stay on request path even for the mid-dialog requests, which is
typically accomplished by home proxy adding Record-Route when SIP dialog is
created. This being said, in some cases (full cone NAT) or UA on public IP,
SIP requests can be sent to UA from any origination address and port, so
that if UA is still awake to receive the message, this message can bypass
the home proxy. However this cannot be relied upon, thus home proxy is
typically left on the request path.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 17:49:25 +0000

Hi,

> Actually, most of the UA that will require SIP Push are located on NATed networks. If you are doing server 
> side NAT traversal or sip outbound, SIP requests should be sent over the same transport/address/port 5-tuple 
> as the one used to receive REGISTER messages. Because of this, home proxy would need to stay on request path 
> even for the mid-dialog requests, which is typically accomplished by home proxy adding Record-Route when 
> SIP dialog is created. This being said, in some cases (full cone NAT) or UA on public IP, SIP requests can be sent to 
> UA from any origination address and port, so that if UA is still awake to receive the message, this message can bypass 
> the home proxy. However this cannot be relied upon, thus home proxy is typically left on the request path.

In case of NAT traversal, where the SIP requests needs to use the REGISTER 5-tuple, the "edge proxy" (using Outbound terminology) needs to be on the path. I still don't understand why the home proxy needs to (unless the home proxy is also the edge proxy, of course).

In any case, I would like to know whether there is a SIP push specific reason for the home proxy to be on the path.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 Aug 2018 14:08:01 -0400

On Wed, Aug 29, 2018 at 1:49 PM, Christer Holmberg <
[email-masked]> wrote:

> networks. If you are doing server
> > SIP dialog is created. This being said, in some cases (full cone NAT) or
> UA on public IP, SIP requests can be sent to
> > UA from any origination address and port, so that if UA is still awake
> to receive the message, this message can bypass
> In case of NAT traversal, where the SIP requests needs to use the REGISTER
> 5-tuple, the "edge proxy" (using Outbound terminology) needs to be on the
> path. I still don't understand why the home proxy needs to (unless the home
> proxy is also the edge proxy, of course).
>
> In any case, I would like to know whether there is a SIP push specific
> reason for the home proxy to be on the path.
>
>
In our implementation home and edge proxy where the same so I thought of
them as the same thing. We used Keep-Alive messages from the client to edge
proxy to monitor if connection was active and client was awake. We sent SIP
push notification when registration needed to be refreshed or when message
needed to be sent to the UA and no active connection from the client was
present. This was done for both in-dialog and out-of-dialog requests, so it
worked well for both cases when client was already awake when new dialog
was started or when we had a long dialog during which client went to sleep
(SUBSCRIBE for VM status).

Your implementation is somewhat different, so that if home and edge proxy
are separate, then there is no need for home proxy to stay on the path. The
only downside from push notification point of view, if these two proxies
are separate, there is no way for home proxy to check if client is already
awake and SIP push is needed, but this is not described in your draft
anyway.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 18:31:35 +0000

Hi,

>> In case of NAT traversal, where the SIP requests needs to use the REGISTER 5-tuple, the "edge proxy" (using Outbound 
>> terminology) needs to be on the path. I still don't understand why the home proxy needs to (unless the home proxy is 
>> also the edge proxy, of course).
>>
> In our implementation home and edge proxy where the same so I thought of them as the same thing. We used Keep-Alive 
> messages from the client to edge proxy to monitor if connection was active and client was awake. We sent SIP push notification 
> when registration needed to be refreshed or when message needed to be sent to the UA and no active connection from the 
> client was present. This was done for both in-dialog and out-of-dialog requests, so it worked well for both cases when client 
> was already awake when new dialog was started or when we had a long dialog during which client went to sleep 
> Your implementation is somewhat different, so that if home and edge proxy are separate, then there is no need for 
> home proxy to stay on the path. The only downside from push notification point of view, if these two proxies are separate, 
> there is no way for home proxy to check if client is already awake and SIP push is needed, but this is not described in your draft anyway.

We should not talk in implementation terms. We should talk about the "home proxy" and "push proxy" as FUNCTIONAL entities:

Home proxy = proxy that re-targets the R-URI, by replacing the AOR with the registered contact
Push proxy = the proxy that requests push notifications 

They may, or may not, be implemented together.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 29 Aug 2018 15:05:25 -0400

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

> We should not talk in implementation terms. We should talk about the "home
> proxy" and "push proxy" as FUNCTIONAL entities:
>

In this case, one implementation alternative is that push proxy only needs
to be on the path of requests that need to wake up the client.

As far as I can see the following requests can require client to wake up:
1. New dialog creating requests, in cases when UA is expected to stay awake
during the dialog, such as calls
2. Non-dialog requests, such as REFER with replaces during blind transfer
3. Requests in dialog where UA is expected to suspend during the dialog,
such as dialog created by SUBSCRIBE

In-dialog requests that are sent during the dialog when client is expected
to be awake (calls) can bypass the push notification proxy.

Another implementation alternative would be send all requests through push
proxy, which will only issue push notification when request receives 430
(Flow Failed) response from the edge proxy (described in
https://tools.ietf.org/html/rfc5626#section-11.5).

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2018 19:17:20 +0000

Hi,

> In this case, one implementation alternative is that push proxy only needs to be on the path of requests that need to wake up the client.

Correct. That is what I indicated earlier.

>1. New dialog creating requests, in cases when UA is expected to stay awake during the dialog, such as calls

Correct. And the draft currently covers that.

>2. Non-dialog requests, such as REFER with replaces during blind transfer

Correct. And the draft currently covers that (eventhough it uses MESSAGE as an example for a non-dialog request).

>3. Requests in dialog where UA is expected to suspend during the dialog, such as dialog created by SUBSCRIBE 

Correct. And THAT is the use-case that was raised by Ben and Robert.

The easiest solution would be to include the pn- parameters in the contact of the SUBSCRIBE, so that the proxy will get them in the associated NOTIFY.

Regards,

Christer