Subject: [sipcore] draft-arnold-push-notification-gateway-00

From: Mickey Arnold <[email-masked]>
Date: Mon, 20 Nov 2017 16:58:37 +0000

Dear all,

We've recently been working on a mechanism of using push notification services (such as Apple's APNs) to ensure the core network is able to reliably contact a SIP User Agent. We've noticed that a draft specification covering a similar mechanism has been published in the last few months here: https://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02.

Although our solution is similar to the one above there's a few differences, with ours involving a more fully-featured network element that we've branded the Push Notification Gateway (PNG). The driver behind the PNG was to allow interoperation with SIP UAs running on devices with limited or forbidden, background or scheduled processing. Rather than give a detailed rundown of the differences in this mailing list I've uploaded an internet draft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-gateway-00.txt outlining our solution.

As a very brief intro:
The SIP UA must always re-register with the network when it receives a push notification. The PNG takes on responsibility for storing inbound messages that would be routed to such a UA, generating a push notification to the UA, waiting for the UA to reregister with the network (which must be via the PNG) and then rerouting the original message to the UA if the access network topology has changed since the last registration. This allows a high probability of delivery for UAs that may not be able to notify the core network of changes in its access network and doesn't rely on re-opening previously closed NAT pinholes. The PNG generating a push notification can also be used as a reliable mechanism to ensure that a UA that is unable to schedule its own reregistration prompts is able to regularly register with the core network.

I hope this is a useful addition to the conversation on how best to leverage push notification services to improve the reliability of SIP user agents and I'm looking forward to working with you all to agree a standard approach to solving this problem. I'm happy to answer any questions you may have.

Thanks very much,

Michael Arnold

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Nov 2017 17:40:43 +0000

Hi Mickey,

While re-registration is currently not described in the holmberg draft, I did talk about that during my presentation in IETF last week. So, the mechanism can also be used for re-registrations, and the intention is to describe that in the next version of the draft.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Mickey Arnold
Sent: 20 November 2017 18:59
To: [email-masked]
Subject: [sipcore] draft-arnold-push-notification-gateway-00

Dear all,

As a very brief intro:

Thanks very much,

Michael Arnold

---

From: Mickey Arnold <[email-masked]>
Date: Tue, 21 Nov 2017 13:42:10 +0000

Hi Christer,

Thanks a lot for getting back to me. I'd be interested to see your presentation, is it recorded anywhere? (Sorry if that's a stupid question, I'm new to contributing here!)
In any case I look forward to reading your next draft version, are you proposing a mechanism whereby a push notification always requires a re-register or something else?

I'd also be interested in your thoughts on holding up inbound SIP messages and then re-routing them after the UA has re-registered, I think that's the main remaining difference between our drafts. Apologies if I've misunderstood your proposal, but by the proxy sending the SIP message straight through isn't there a problem if there has been a change in the UA's access network? For example if a new NAT pinhole is opened or the mobile device has moved then sending the SIP message to the original IP/port is unlikely to reach the UA even once it has been woken up by the notification.

Looking forward to hearing back from you.

Thanks very much,
Michael Arnold

From: Christer Holmberg [mailto:[email-masked]]
Sent: 20 November 2017 17:41
To: Mickey Arnold <[email-masked]>; [email-masked]
Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00

Hi Mickey,

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Mickey Arnold
Sent: 20 November 2017 18:59
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] draft-arnold-push-notification-gateway-00

Dear all,

As a very brief intro:

Thanks very much,

Michael Arnold

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Nov 2017 14:00:11 +0000

Hi Mickey,

> Thanks a lot for getting back to me. I’d be interested to see your presentation, is it recorded anywhere? (Sorry if that’s a stupid question, I’m new to contributing here!)

https://play.conf.meetecho.com/Playout/?session=IETF100-SIPCORE-20171113-1740

> In any case I look forward to reading your next draft version, are you proposing a mechanism whereby a push notification always requires a re-register or something else?

Personally I’d be fine to always require a re-register.

> I’d also be interested in your thoughts on holding up inbound SIP messages and then re-routing them after the UA has re-registered, I think that’s the main remaining difference between our drafts.

The draft currently doesn’t say much regarding exactly when the SIP message is forwarded, but it was commented at the meeting that we need text regarding that.

So, if we know there will be a re-register, the proxy can wait for it before forwarding the SIP message.

Of course, as an optimisation, the proxy can try to forward the SIP message even before it receives the re-register, but we don’t need to mandate such behaviour.

> Apologies if I’ve misunderstood your proposal, but by the proxy sending the SIP message straight through isn’t there a problem if there has been a change in the UA’s access network?
> For example if a new NAT pinhole is opened or the mobile device has moved then sending the SIP message to the original IP/port is unlikely to reach the UA even once it has been woken up by the notification.

Correct. And, all of that should be solved with sending re-register :)

The reason I didn’t include that in the draft so far was because I first wanted to know whether the community has an interest to work on this to begin with.

Regards,

Christer

From: Christer Holmberg [mailto:[email-masked]]
Sent: 20 November 2017 17:41
To: Mickey Arnold <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sipcore] draft-arnold-push-notification-gateway-00

Hi Mickey,

Regards,

Christer

Dear all,

We’ve recently been working on a mechanism of using push notification services (such as Apple’s APNs) to ensure the core network is able to reliably contact a SIP User Agent. We’ve noticed that a draft specification covering a similar mechanism has been published in the last few months here: https://tools.ietf.org/html/draft-holmberg-sipcore-sip-push-02.

Although our solution is similar to the one above there’s a few differences, with ours involving a more fully-featured network element that we’ve branded the Push Notification Gateway (PNG). The driver behind the PNG was to allow interoperation with SIP UAs running on devices with limited or forbidden, background or scheduled processing. Rather than give a detailed rundown of the differences in this mailing list I’ve uploaded an internet draft here https://datatracker.ietf.org/doc/draft-arnold-sipcore-push-notification-gateway-00.txt outlining our solution.

As a very brief intro:
The SIP UA must always re-register with the network when it receives a push notification. The PNG takes on responsibility for storing inbound messages that would be routed to such a UA, generating a push notification to the UA, waiting for the UA to reregister with the network (which must be via the PNG) and then rerouting the original message to the UA if the access network topology has changed since the last registration. This allows a high probability of delivery for UAs that may not be able to notify the core network of changes in its access network and doesn’t rely on re-opening previously closed NAT pinholes. The PNG generating a push notification can also be used as a reliable mechanism to ensure that a UA that is unable to schedule its own reregistration prompts is able to regularly register with the core network.

I hope this is a useful addition to the conversation on how best to leverage push notification services to improve the reliability of SIP user agents and I’m looking forward to working with you all to agree a standard approach to solving this problem. I’m happy to answer any questions you may have.

Thanks very much,

Michael Arnold

---

From: Mickey Arnold <[email-masked]>
Date: Tue, 21 Nov 2017 17:02:23 +0000

Hi Christer,

Thanks a lot for your responses and the link to the recording, they've cleared up a lot of my concerns. Looking forward to seeing your next draft!

Thanks very much,
Michael Arnold

From: Christer Holmberg [mailto:[email-masked]]
Sent: 21 November 2017 14:00
To: Mickey Arnold <[email-masked]>; [email-masked]
Subject: Re: [sipcore] draft-arnold-push-notification-gateway-00

Hi Mickey,

> In any case I look forward to reading your next draft version, are you proposing a mechanism whereby a push notification always requires a re-register or something else?

Personally I'd be fine to always require a re-register.

> I'd also be interested in your thoughts on holding up inbound SIP messages and then re-routing them after the UA has re-registered, I think that's the main remaining difference between our drafts.

The draft currently doesn't say much regarding exactly when the SIP message is forwarded, but it was commented at the meeting that we need text regarding that.

Of course, as an optimisation, the proxy can try to forward the SIP message even before it receives the re-register, but we don't need to mandate such behaviour.

> Apologies if I've misunderstood your proposal, but by the proxy sending the SIP message straight through isn't there a problem if there has been a change in the UA's access network?

The reason I didn't include that in the draft so far was because I first wanted to know whether the community has an interest to work on this to begin with.

Regards,

Christer

Hi Mickey,

Regards,

Christer

Dear all,

As a very brief intro:

Thanks very much,

Michael Arnold