Subject: [sipcore] SIP PUSH

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 11:43:47 +0000

Hi,

There is a problem with iOS SIP/VoIP applications (I understand the same is coming to Android too): the application need to be “woken up” using the Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions an incoming request could wake up the application.

A solution has been discussed, where a SIP proxy (or some other network entity) informs the Apple Push Server when an incoming call  for Alice is coming, the Apple Push Server wakes up Alice's UA VoIP application, which is then able to receive the INVITE request.

In order to do this, the UA needs to provide some information (e.g., which push server is used, the Alice’s VoIP application specific push identifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that people are looking at a number of different proprietary solutions – which can cause a real mess in the long run. Therefor I think it would be VERY important to produce a standardised way of doing this.

There IS a draft on this:

https://tools.ietf.org/html/draft-ivanov-sipcore-pnsip-01

The draft uses URI parameters. We think that media feature tags should be used instead. Also, we think at least one additional parameter is needed. But, in general we think the draft provides a good solution.

I haven’t managed to contact the draft author, as my e-mails are rejected. But, if he is reading this, or if someone else is able to contact him, I’d like to get in contact with him :)

Regards,

Christer

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 25 Sep 2017 12:23:35 +0000

What is the advantage of this strategy v.s. Push Server communicating directly with the SIP Proxy/Registrar etc... through a non-SIP, e.g. REST API based, interface?

Thanks,
Tolga

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, September 25, 2017 7:44 AM
To: [email-masked]
Subject: [sipcore] SIP PUSH

Hi,

There is a problem with iOS SIP/VoIP applications (I understand the same is coming to Android too): the application need to be "woken up" using the Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions an incoming request could wake up the application.

In order to do this, the UA needs to provide some information (e.g., which push server is used, the Alice's VoIP application specific push identifier etc) to the SIP network during registration.

There is a real need for a solution in the market, and I know that people are looking at a number of different proprietary solutions - which can cause a real mess in the long run. Therefor I think it would be VERY important to produce a standardised way of doing this.

I haven't managed to contact the draft author, as my e-mails are rejected. But, if he is reading this, or if someone else is able to contact him, I'd like to get in contact with him :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 12:35:58 +0000

Hi,

>What is the advantage of this strategy v.s. Push Server communicating directly with the SIP Proxy/Registrar etc… through a non-SIP, e.g. REST API based, interface?

The Push Server DOES communicate with the SIP Proxy/Registrar using a non-SIP interface. Those interfaces are provided by Apple (or whoever provides the push server), and we don’t suggest to change those.

When the SIP UA registers itself with the Push Server, it receives a unique token. The SIP UA needs to inform the proxy about that token (and, inform the proxy that it is an Apple token), so that the proxy can provide it to the Push Server when the incoming call comes.

SO, what we need is a way for the SIP UA to provide the token to the proxy.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, September 25, 2017 7:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] SIP PUSH

Hi,

Regards,

Christer

---

From: Justin Hornosty <[email-masked]>
Date: Mon, 25 Sep 2017 10:47:58 -0400

> There is a problem with iOS SIP/VoIP applications (I understand the same is coming to Android too): the application need to be “woken up” using the Apple Push Mechanism, in order to e.g., be able t…

What is the situation with Android? Is the rational that Android and iOS
want to stop app developers from writing poor keep alive / background
services for the various messaging apps (that have the tendency to eat
battery life and bandwidth) or am I missing something?

-jjrh

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 25 Sep 2017 15:22:20 +0000

Why can't the AoR of the SIP UA -and a token if still necessary- be provided by the Push Server to the SIP Proxy directly (together with other information, e.g. what should trigger SIP Proxy to alert the Push Server)? All this information can be sent from SIP UA to the Push Server AFAICS.

Thanks,
Tolga

From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, September 25, 2017 8:36 AM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: Re: SIP PUSH

Hi,

>What is the advantage of this strategy v.s. Push Server communicating directly with the SIP Proxy/Registrar etc... through a non-SIP, e.g. REST API based, interface?

The Push Server DOES communicate with the SIP Proxy/Registrar using a non-SIP interface. Those interfaces are provided by Apple (or whoever provides the push server), and we don't suggest to change those.

Regards,

Christer

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 16:14:57 +0000

Hi,

> Why can't the AoR of the SIP UA -and a token if still necessary- be provided by the Push Server to the SIP Proxy
> directly (together with other information, e.g. what should trigger SIP Proxy to alert the Push Server)?

I don't know if the push server can distribute the information to proxies.

And, even if the proxy can distribute the information, it does not know which proxies each user is going to use. It would have to distribute the information of each user to each proxy.

The idea is that the proxy that the user uses will have the token, and that proxy will then send the token to the push server and ask it to wake up the user associated with the token.

>All this information can be sent from SIP UA to the Push Server AFAICS.

I don't know how much additional information you can send to the Push Servers. And, if you start sending AoRs etc you may end up with privacy issues. The idea is that the push server doesn't have any SIP user information - it only knows to which device a token-id belongs.

The suggested solution is very simple - the user simply provides the token in the REGISTER request, and the proxy will store it. That should work for all push servers.

Regards,

Christer

From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, September 25, 2017 8:36 AM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: SIP PUSH

Hi,

Regards,

Christer

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 16:20:50 +0000

Hi,

>> There is a problem with iOS SIP/VoIP applications (I understand the same is coming to Android too): the application need to be “woken up” using 
>> the Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE requests. In earlier iOS versions an incoming request could wake up the application.
>
> What is the situation with Android? 

I don't know - I'd have to look that up. Currently the problem in the field seems to be mostly with iOS.

> Is the rational that Android and iOS want to stop app developers from writing poor keep alive / background services
> for the various messaging apps (that have the tendency to eat battery life and bandwidth) or am I missing something?

I will leave speculations to others (and, if you google the discussion forums, there are many people who are upset by this), but the official reason can be read here:

https://developer.apple.com/library/content/qa/qa1938/_index.html#//apple_ref/doc/uid/DTS40017564

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Sep 2017 12:54:23 -0400

> battery life and bandwidth) or am I missing something?
Android is more flexible, but recommended solution is
https://firebase.google.com/products/cloud-messaging/

The main justification is extending battery life by reducing the number of
applications running in the background.

My question regarding this draft, would be, why would you write a SIP
softphone for mobile operating system? You would generally be much better
of writing a solution around a proprietary protocol such as Google Firebase
or Apple Push. If you look at popular messaging applications (Whatsup,
Slack, Facetime, etc), none of them used SIP and built something
proprietary.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Sep 2017 12:01:38 -0500

On 9/25/17 11:54 AM, Roman Shpount wrote:
> softphone for mobile operating system? You would generally be much 
> better of writing a solution around a proprietary protocol such as 
> Google Firebase or Apple Push. If you look at popular messaging 
> applications (Whatsup, Slack, Facetime, etc), none of them used SIP 
> and built something proprietary.

Because some people still want to do things in a way that interoperates 
among various implementations rather than locking the ecosystem up into 
a series of mutually non-interoperatble, privately-controlled, 
vertically-integrated applications.

I mean, this is kind of the reason the IETF exists.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 17:05:07 +0000

Hi,

> Android is more flexible, but recommended solution is https://firebase.google.com/products/cloud-messaging/
>
> The main justification is extending battery life by reducing the number of applications running in the background.
>
> My question regarding this draft, would be, why would you write a SIP softphone for mobile operating system? You 
> would generally be much better of writing a solution around a proprietary protocol such as Google Firebase or Apple Push. 
> If you look at popular messaging applications (Whatsup, Slack, Facetime, etc), none of them used SIP and built something 
> proprietary.

What matters is that there are SIP-based applications out there, and if there is a problem to be fixed I think it would be very weird for us to "fix it" by telling people to use something else instead... We should be glad that people want to use SIP, and try to help when there is a problem. 

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Sep 2017 13:22:08 -0400

On Mon, Sep 25, 2017 at 1:01 PM, Adam Roach <[email-masked]> wrote:

> among various implementations rather than locking the ecosystem up into a
> series of mutually non-interoperatble, privately-controlled,

The reason I am asking is two fold:

1. We are trying to build a signaling solution which is intended to work
with proprietary push solutions which show no intent of becoming
standardized. Whatever is designed, the client will continue to
be proprietary unless standard PUSH protocol is designed and used.

2. There are serious scalability issues with current secure SIP
implementations, which require client to maintain a persistent TLS
connection to two independent proxies and send keep-alive messages on both
connections. There was quite a bit of discussion of these issues but no
interest to develop a solution.

I have built several solutions which integrated SIP soft client with Apple
Push and Android Firebase notifications. I would not build one now and use
WebRTC client with proprietary signaling to the web application server
instead. I would only use SIP for service interconnect with other providers
or other back-end system components.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 18:07:42 +0000

Hi,

…

> I have built several solutions which integrated SIP soft client with Apple Push and Android Firebase notifications. 
> I would not build one now and use WebRTC client with proprietary signaling to the web application server instead. 
> I would only use SIP for service interconnect with other providers or other back-end system components.

And while others make other choices, nobody prevents you from doing that :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Sep 2017 16:25:41 -0400

The referenced draft only describes how the sip client communicates the 
push configuration to its proxy. But what happens after that? Presumably 
the proxy, when it receives certain incoming requests destined for the 
UA is expected to use the push configuration to cause the UA to receive 
a push notification. But how does that interact with processing of the 
incoming request by the proxy? Must the proxy defer forwarding the 
request until it gets some indication that the push has been 
acknowledged? How does that happen, and what is the time budget for it? 
(You can't buffer the request for very long.)

ISTM that some of those mechanics need to be part and parcel of the 
mechanism.

	Thanks,
	Paul

On 9/25/17 7:43 AM, Christer Holmberg wrote:
> Hi,
> 
> There is a problem with iOS SIP/VoIP applications (I understand the same 
> is coming to Android too): the application need to be “woken up” using 
> the Apple Push Mechanism, in order to e.g., be able to accept incoming 
> INVITE requests. In earlier iOS versions an incoming request could wake 
> up the application.
> 
> A solution has been discussed, where a SIP proxy (or some other network 
> entity) informs the Apple Push Server when an incoming call  for Alice 
> is coming, the Apple Push Server wakes up Alice's UA VoIP application, 
> which is then able to receive the INVITE request.
> 
> In order to do this, the UA needs to provide some information (e.g., 
> which push server is used, the Alice’s VoIP application specific push 
> identifier etc) to the SIP network during registration.
> 
> There is a real need for a solution in the market, and I know that 
> people are looking at a number of different proprietary solutions – 
> which can cause a real mess in the long run. Therefor I think it would 
> be VERY important to produce a standardised way of doing this.
> 
> The draft uses URI parameters. We think that media feature tags should 
> be used instead. Also, we think at least one additional parameter is 
> needed. But, in general we think the draft provides a good solution.
> 
> I haven’t managed to contact the draft author, as my e-mails are 
> rejected. But, if he is reading this, or if someone else is able to 
> contact him, I’d like to get in contact with him :)
> 
> Regards,
> 
> Christer
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Sep 2017 20:43:41 +0000

Hi,

>The referenced draft only describes how the sip client communicates the push configuration to its proxy. But what happens after that? Presumably the proxy, when it >receives certain incoming requests destined for the UA is expected to use the push configuration to cause the UA to receive a push notification. But how does that interact >with processing of the incoming request by the proxy? Must the proxy defer forwarding the request until it gets some indication that the push has been acknowledged? >How does that happen, and what is the time budget for it? 

In theory you can buffer it as long as you would allow you to re-transmit the request before the transaction is considered failed.

But, from what I've heard, the push mechanism is very fast, and my understanding is that people would buffer for a very short time - or not buffer at all. After all, re-transmitting the request before the device can handle it won't break anything - the package will most likely simply be dropped. It also depends on which proxy contacts the push server, and how far the proxy is from the device.

Regards,

Christer

On 9/25/17 7:43 AM, Christer Holmberg wrote:
> Hi,
> 
> There is a problem with iOS SIP/VoIP applications (I understand the 
> same is coming to Android too): the application need to be "woken up" 
> using the Apple Push Mechanism, in order to e.g., be able to accept 
> incoming INVITE requests. In earlier iOS versions an incoming request 
> could wake up the application.
> 
> which push server is used, the Alice's VoIP application specific push 
> people are looking at a number of different proprietary solutions - 
> I haven't managed to contact the draft author, as my e-mails are 
> contact him, I'd like to get in contact with him :)
> 
> Regards,
> 
> Christer
> 
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Sep 2017 17:03:48 -0400

On Mon, Sep 25, 2017 at 4:43 PM, Christer Holmberg <
[email-masked]> wrote:

> the proxy, when it >receives certain incoming requests destined for the UA
> is expected to use the push configuration to cause the UA to receive a push
> notification. But how does that interact >with processing of the incoming
> request by the proxy? Must the proxy defer forwarding the request until it
> gets some indication that the push has been acknowledged? >How does that
> happen, and what is the time budget for it?
> In theory you can buffer it as long as you would allow you to re-transmit
> the request before the transaction is considered failed.
>
> But, from what I've heard, the push mechanism is very fast, and my
> understanding is that people would buffer for a very short time - or not
> buffer at all. After all, re-transmitting the request before the device can
> handle it won't break anything - the package will most likely simply be
> dropped. It also depends on which proxy contacts the push server, and how
> far the proxy is from the device.
>

In the SIP/PUSH based solution that we have built, client registration was
done through an HTTPS REST API call, which also performed other functions,
such as loaded branding, feature, and account information for the mobile
client. Incoming calls were received by B2BUA. B2BUA would periodically
send 180 ringing to the origination party to keep the call active. It would
also send the PUSH notification to the client with generated unique SIP
URL. Client will receive PUSH notification and place a call to the
generated unique SIP URL. B2BUA will receive the call (which, by the way
was done with only ICE UDP and TCP host candidates to facilitate faster
call setup) and bridge media between the two inbound calls. Once the call
was established, call might get re-connected. If the call came from PSTN,
it will continue with the media bridge. If the call came from another
client, B2BUA would issue an offerless re-INVITE to the client, which will
cause it to collect complete list of ICE candidates and go through a
complete ICE renegotiation between two clients taking B2BUA media bridge
out of the call path. During further optimization, SIP was replaced with
proprietary call setup protocol, in which offer from B2BUA was sent in the
PUSH notification.

As you can see, large portions of this flow were proprietary, but I wanted
to provide it for your reference.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 25 Sep 2017 22:00:14 -0400

Christer Holmberg <[email-masked]> writes:
> people are looking at a number of different proprietary solutions --

A fine sentiment, but isn't this *already* a gross, incompatible
proprietary situation?  The standardized way of "waking up" a SIP user
agent is to ... *sent it an INVITE*.

If the OS wants to restrict the number of applications that run in the
background, it should provide a way for the application to tell it,
"Monitor UDP port XXX and if something comes in on it, wake me up."
(Actually, that's usually called "a recv() call to the ABI".)

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Sep 2017 04:22:08 +0000

Hi,

> A fine sentiment, but isn't this *already* a gross, incompatible proprietary situation?  The standardized way of "waking up" a 
> SIP user agent is to ... *sent it an INVITE*.
>
> If the OS wants to restrict the number of applications that run in the background, it should provide a way for the application 
> to tell it, "Monitor UDP port XXX and if something comes in on it, wake me up." (Actually, that's usually called "a recv() call to the ABI".)

Unfortunately, there is nothing we can do about that.

Regards,

Christer

---

From: Alberto Llamas <[email-masked]>
Date: Tue, 26 Sep 2017 04:54:34 +0000

I have seen approaches like maintaining a dummy call to the proxy server
without having to use all the resources of the mobile client. During this
call, a dummy RTP packet is sent as a keep-alive that is previously
negotiated with the proxy server. This approach has been implemented under
an IMS and Push to Talk service scenario.

I think it could be taken as a source of inspiration and achieve
standardization of a mechanism 100% SIP that allows us the desired goal.

Regards,

On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmberg <
[email-masked]> wrote:

> is coming to Android too): the application need to be “woken up” using the
> Apple Push Mechanism, in order to e.g., be able to accept incoming INVITE
> requests. In earlier iOS versions an incoming request could wake up the
> application.
>
> entity) informs the Apple Push Server when an incoming call  for Alice is
> coming, the Apple Push Server wakes up Alice's UA VoIP application, which
> is then able to receive the INVITE request.
>
> In order to do this, the UA needs to provide some information (e.g., which
> push server is used, the Alice’s VoIP application specific push identifier
> etc) to the SIP network during registration.
>
> There is a real need for a solution in the market, and I know that people
> are looking at a number of different proprietary solutions – which can
> cause a real mess in the long run. Therefor I think it would be VERY
> important to produce a standardised way of doing this.
>
> The draft uses URI parameters. We think that media feature tags should be
> used instead. Also, we think at least one additional parameter is needed.
> But, in general we think the draft provides a good solution.
>
> I haven’t managed to contact the draft author, as my e-mails are rejected.
> But, if he is reading this, or if someone else is able to contact him, I’d
> like to get in contact with him :)
>
> Regards,
>
> Christer
>
>

-- 
Alberto Llamas
Telecommunications Engineer
dCAP | KPAC | SSCA

*"Internet is all about share"*

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Sep 2017 06:09:20 +0000

Hi,

> I have seen approaches like maintaining a dummy call to the proxy server without having to use all the resources of the mobile client. During this call, a dummy RTP packet is
> sent as a keep-alive that is previously negotiated with the proxy server. This approach has been implemented under an IMS and Push to Talk service scenario.
>
> I think it could be taken as a source of inspiration and achieve standardization of a mechanism 100% SIP that allows us the desired goal.

I have heard about solutions like to one above also. Personally, I don’t think it’s sustainable. Even “idle” sessions consume resources (device, radio, core network etc), and assuming there is a valid reason for Apple mandating push, I see no reason why we should try to go around it.

Also, it might affect charging, and you would have to move such sessions in mobile use-cases, you may have to define new functions to distinguish these kind of sessions from “normal” sessions that just happen to be idle, etc etc etc. Also, not all SIP-based applications even use RTP.

I think a push based mechanism is much more simple, with much less impact on the networks.

Regards,

Christer

On Mon, Sep 25, 2017 at 11:43 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

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

"Internet is all about share"

---

From: David Viamonte <[email-masked]>
Date: Tue, 26 Sep 2017 13:49:26 +0200

I fully agree the problem exists.

However my question is: is this the type of issue IETF should address? One
can think that dealing with SIP interconnection with previous industry
standards such as ISDN or ongoing standardization work (e.g.: 3GPP IMS and
their corresponding evolution) are a matter of SDO standardization work
(which BTW does not always occur in IETF).

However we are talking in this case about a push mechanism developed by one
specific company.

IMHO IETF does not generally define how B2BUAs or SBCs *should* be
internally built but rather what a standard IETF implementation expects
from such entities (e.g.: RFC5853 or RFC7206).

To me, such "black box" dont-you-worry-I-will-take-care-of-everything
approach based on such push services represent a number of concerns, not
only from privacy but also from scalability, availability and transparency
perspective: in the end, when you deploy a system where the actual
"delivery" of information relies in an uncontrolled third party, there is
little you can commit on the system you are actually trying to build.

So to me even though such a problem certainly exists, I am not sure it is
the type of problem IETF *should* address. At least, the way of addressing
the problem should not promote the adoption of proprietary push
architectures, but rather the development of a more open approach to the
problem, IMHO.

My two cents,

David

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Libre
de virus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Sep 26, 2017 at 8:09 AM, Christer Holmberg <
[email-masked]> wrote:

> call, a dummy RTP packet is
> > sent as a keep-alive that is previously negotiated with the proxy
> server. This approach has been implemented under an IMS and Push to Talk
> service scenario.
> >
> I have heard about solutions like to one above also. Personally, I don’t
> think it’s sustainable. Even “idle” sessions consume resources (device,
> radio, core network etc), and assuming there is a valid reason for Apple
> mandating push, I see no reason why we should try to go around it.
>
> Also, it might affect charging, and you would have to move such sessions
> in mobile use-cases, you may have to define new functions to distinguish
> these kind of sessions from “normal” sessions that just happen to be idle,
> etc etc etc. Also, not all SIP-based applications even use RTP.
>
>> rejected. But, if he is reading this, or if someone else is able to contact
>> him, I’d like to get in contact with him :)
>>
>> Regards,
>>
>> Christer
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Sep 2017 12:28:43 +0000

Hi,

> However my question is: is this the type of issue IETF should address? One can think that dealing with SIP interconnection with previous industry standards such as ISDN or ongoing standardization
> work (e.g.: 3GPP IMS and their corresponding evolution) are a matter of SDO standardization work (which BTW does not always occur in IETF).

For sure this could be done elsewhere. But, while this is related to a specific mobile OS, it is NOT related to a specific SIP network/architecture, which is why I thought people might be interested to do it in IETF.

> However we are talking in this case about a push mechanism developed by one specific company.
>
> IMHO IETF does not generally define how B2BUAs or SBCs *should* be internally built but rather what a standard IETF implementation expects from such entities (e.g.: RFC5853 or RFC7206).

The suggested mechanism doesn’t require a B2BUAs or SBC. The push can be triggered by a normal SIP proxy.

> To me, such "black box" dont-you-worry-I-will-take-care-of-everything approach based on such push services represent a number of concerns, not only from privacy but also from scalability, availability
> and transparency perspective: in the end, when you deploy a system where the actual "delivery" of information relies in an uncontrolled third party, there is little you can commit on the system you are actually trying to build.

Well, if people have issues with that, they shouldn’t use iOS to begin with, because there are many types of applications that use the push mechanism. Note that I am NOT suggesting that non-iOS applications would have to use the push mechanism.

And, privacy is the main reason why we suggest that the only information sent to the push server by the proxy is the token id (which the push server has generated). The only thing the push server knows is that it needs to, for some reason, wake up the user associated with the token id.

> So to me even though such a problem certainly exists, I am not sure it is the type of problem IETF *should* address. At least, the way of addressing the problem should not promote
> the adoption of proprietary push architectures, but rather the development of a more open approach to the problem, IMHO.

I am not promoting adoption of the push architecture – I am promoting a mechanism which would allow people to continue using SIP-based applications in an environment that requires usage of the push architecture :)

Regards,

Christer

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>  Libre de virus. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>

On Tue, Sep 26, 2017 at 8:09 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 26 Sep 2017 20:57:50 -0400

> be VERY important to produce a standardised way of doing this.

I know I'm being cranky about this, but MHO is that the market needs to
be told -- loudly -- that what Apple has done is a Bad Idea.  Yes,
people will develop a variety of proprietary solutions, but that will
increase the cost and inconvenience of interoperating with Apple's
mistaken architecture.  The goal is to get Apple to abandon this idea
and implement something much closer to how Internet applications are
supposed to work.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Sep 2017 11:03:22 +1000

> But, in general we think the draft provides a good solution.

I don't think that this is the right plan.  I would prefer to see
something that is compatible with web push.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Sep 2017 05:02:49 +0000

Hi Martin,

>> be used instead. Also, we think at least one additional parameter is needed.
>I don't think that this is the right plan.  I would prefer to see something that is compatible >with web push.

Why wouldn't you be able to use this with web push?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Sep 2017 05:08:30 +0000

Hi,

> I know I'm being cranky about this, but MHO is that the market needs to be told -- loudly -- that what Apple has done is a Bad Idea.  
> Yes, people will develop a variety of proprietary solutions, but that will increase the cost and inconvenience of interoperating with 
> Apple's mistaken architecture.  The goal is to get Apple to abandon this idea and implement something much closer to how Internet 
> applications are supposed to work.

Note that, while the Apples push service may be proprietary, IETF has published a web notification mechanism itself, so I assume it is ok for Internet applications to use it...

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Sep 2017 16:03:22 +1000

> Why wouldn't you be able to use this with web push?

The basics are almost right, but I think that you might want to
consider draft-ietf-webpush-encryption.  Having a pn-type is the bit
that I didn't like.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Sep 2017 07:04:06 +0000

Hi Martin,

>consider draft-ietf-webpush-encryption.  Having a pn-type is the bit

pn-type is only an identifier used to inform which push service is used.
But, if the information can be retrieved from elsewhere, e.g., from
pn-uri, then pn-type may not be needed.

Regarding draft-ietf-webpush-encryption, I see no reason to prevent it. If
we need some additional parameter(s) to support it we can add it to the
draft. But, I understand the information can also be included in the
subscription URI (pn-uri).

Note, though, that the SIP push proposal doesn¹t mandate any payload in
the push message. The proposal only uses the push service to wake up the
application - the data is still sent in the SIP request.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Sep 2017 21:19:59 +1000

> pn-uri, then pn-type may not be needed.

I don't see a use for it.  Assuming that you use RFC 8030 that is.

> subscription URI (pn-uri).

It cannot.  The URI is sent to the push service and the encryption
parameters contain information that needs to be kept from the push
service.

> application - the data is still sent in the SIP request.

That is not at all clear from the draft.  It seems like you could send
the message in the push message, but those are typically space
constrained and INVITES are rarely small, so a wakeup prod is probably
the best and easiest solution.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Sep 2017 12:13:14 +0000

Hi,

Well, Apple doesn’t use RFC 8030 (AFAIK), but it seems like their URIs also contain “apple.com”, or something similar.

But, as URIs may change over time, I thought that a “static” pn-type would be useful. It would be optional. And, if only one push service is used to begin with, it could be configured in the proxy sending the push messages.

I assume the application would have to remove the information before using the URI.

draft-ietf-webpush-encryption does say:

"2.1. Key and Secret Distribution

   The application using the subscription distributes the subscription
   public key and authentication secret to an authorized application
   server. This could be sent along with other subscription information
   that is provided by the user agent, such as the push subscription
   URI."

But, again, we can add pn- parameters for distributing the information. I guess we could have something like pn-enckey and pn-encsec.

That is not at all clear from the draft.

I agree.

Some other changes/additions are also needed. I wanted to give the original author of the draft a chance to do it, but I haven’t been able to contact him. So, if I don’t hear from him, the idea would be that I submit my own version of the draft.

It seems like you could send
the message in the push message, but those are typically space
constrained and INVITES are rarely small, so a wakeup prod is probably
the best and easiest solution.

Correct.

I have heard ideas where the INVITE request would be sent in the push message, and the associated responses would then be sent using SIP transport – which means that proxies could receive responses to requests they are not aware of. Really ugly.

One of the reason I think it would be important for us to standardise a mechanism is to (hopefully) discourage people from doing such kind of hacks, without any kind of interoperability.

Regards,

Christer