Re: [sipcore] Push notifications with iOS 13 (RFC 8599)

[Yehoshua Gev <[e-mail]>]

For triggering discussion (not rejecting Simon's proposal), I've thought of
another way for passing several "pn-*"-groups.
Let's start with an example of the contact header URI parameters:
    pn-prid[call]=00fc13adff78512;
    pn-param[call]=DEF123GHIJ.org.linphone.phone.voip;
    pn-provider[call]=apns;
    pn-methods[call]=INVITE;
    pn-prid[im]=c11292f7b74733d;
    pn-param[im]=DEF123GHIJ.org.linphone.phone.remote;
    pn-provider[im]=apns;
    pn-methods[im]=MESSAGE

This is of course not compatible with RFC 8599, as it uses other
(non-constant) parameter names.
The idea is grouping the parameters according to user-defined strings,
given in brackets.
The Proxy will choose the correct group by matching the request method that
triggers the push notification to the pn-methods parameter.
I also suggest that for push notification that is used for triggering
registration refresh, the method REGISTER will be used (although it is not
really an incoming REGISTER request).

I've not yet seen a usage of non-constant parameter names in SIP URI, so I
would like to know if someone has any saying about it :-)
This syntax doesn't contradict the SIP URI ABNF of RFC 3261, but seems to
work against the notion of IANA registration of URI parameters by name (RFC
3969)...

Another way is numbering the parameters with a sequence number (like done
for "param" parameter in RFC 4240):
    pn-prid-1=00fc13adff78512;
    pn-param-1=DEF123GHIJ.org.linphone.phone.voip;
    pn-provider-1=apns;
    pn-methods-1=INVITE;
    pn-prid-2=c11292f7b74733d;
    pn-param-2=DEF123GHIJ.org.linphone.phone.remote;
    pn-provider-2=apns;
    pn-methods-2=MESSAGE

I think this is less intuitive, but better conforms to the current
practices of URI parameters (and maybe also be easier to implement on the
Proxy side).

Best,
Yehoshua





On Mon, Oct 12, 2020 at 5:55 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> As you suggest, one solution is to use a different (non-VoIP) push
> notification in order to trigger re-registrations.
>
>
>
> The only issue with those, AFAIK, is that there is no guarantee when/if
> they will actually wake up the application. It depends on a number of
> factors, e.g., energy mode, how often the app is used, etc etc. However, I
> don’t have any data regarding that.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* sipcore <[e-mail]> *On Behalf Of *Simon MORLAT
> *Sent:* sunnuntai 11. lokakuuta 2020 23.43
> *To:* Yehoshua Gev <[e-mail]>
> *Cc:* sipcore <[e-mail]>
> *Subject:* Re: [sipcore] Push notifications with iOS 13 (RFC 8599)
>
>
>
> Hi Yehoshua,
>
>
>
> Thank you for starting this discussion.
>
> My company is developing the Linphone software (https://linphone.org
> <https://protect2.fireeye.com/v1/url?k=10c8d06e-4e6830fa-10c890f5-86d2114eab2f-d8cadb53839f1f91&q=1&e=5b0ee252-62e3-4113-9072-c4697431936c&u=https%3A%2F%2Flinphone.org%2F>),
> an cross platform open-source SIP softphone and SDK.
>
> The last version we published was for adding compatibility for iOS 13. I
> admit it was a nightmare to comply with the new restrictions.
>
> For push notifications, we based our work on RFC 8599 , but indeed we had
> to somewhat extend the RFC in order to transmit 2 different push
> notification tokens:
>
> - the one for calls (PushKit kind of notifications)
>
> - the one for IMs (using Remote push notification service).
>
>
>
> To answer your question: the "remote push notification" token could
> apparently also be used for "Background push notifications" (
> https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app?language=objc
> ), which are the push notifications we need to refresh a REGISTER that is
> about to expire (or expired). So yes you need two different push services
> and tokens.
>
>
>
> As of today, the Linphone app doesn't use push notifications for
> triggering REGISTER refreshes: we use a very long expire time (one year)
> instead. However we would prefer to switch to push-triggered REGISTER
> refresh as soon as possible.
>
>
>
> The syntax extension we made to RFC8599 is described in our wiki:
>
>
>
>
> https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/iOS/#HUpdateContactURIparameters
> <https://protect2.fireeye.com/v1/url?k=ad9b335e-f33bd3ca-ad9b73c5-86d2114eab2f-81e0945f1c7861ec&q=1&e=5b0ee252-62e3-4113-9072-c4697431936c&u=https%3A%2F%2Fwiki.linphone.org%2Fxwiki%2Fwiki%2Fpublic%2Fview%2FLib%2FGetting%2520started%2FiOS%2F%23HUpdateContactURIparameters>
>
>
>
> We designed this syntax to be compatible with RFC8599 syntax. To
> summarize, here is a quick example to understand how we convey push tokens
> for an app that needs to advertise calls and IMs:
>
>
>
>
> pn-prid=00fc13adff78512:voip&c11292f7b74733d:remote;pn-param=DEF123GHIJ.org.linphone.phone.voip&remote;pn-provider=apns
>
>
>
> Notice the ":voip" and ":remote" token suffixes, and the "&".
>
> We decided not to go with a multiple contact headers approach, each
> contact uri bearing a pn-prid for either voip or remote service: the
> forking by a proxy that is unaware of push notifications could result in
> INVITEs to be duplicated.
>
>
>
> We had to go fast otherwise our app would stop working, but from the
> beginning we have in mind that this issue should be raised and hopefully
> resolved here at IETF, with or without our proposed syntax extension.
>
>
>
> Today due to Apple's recent changes, it looks like RFC8599 cannot be used
> "as is" to make a SIP app for iOS. The risk that Google does the same in
> near future exists.
> Are there people interested here in collaborating to an RFC8599 update to
> address this iOS platform evolution ? In other words, we need to solve how
> to convey multiple pn-prid and pn-param for a same user-agent instance.
>
> Best regards,
>
> Simon
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Le dim. 11 oct. 2020 à 17:07, Yehoshua Gev <[e-mail]> a écrit :
>
> Hi All,
>
>
>
> I hope it is ok to post this here and not on sip-implementors...
>
>
>
> We are trying to implement RFC 8599 for performing push notifications for
> Apple devices.
>
>
>
> Starting with iOS 13, there is a restriction on VoIP pushes [1]: "Apps
> receiving VoIP push notifications *must report the call quickly to
> CallKit, so it can alert the user* to the presence of the incoming call."
>
>
>
> According to RFC 8599, pushes are used for (at least) two different goals:
>
>   1) Initiating registration refreshes (section 5.5)
>
>   2) Notifying of incoming calls (section 5.6.2)
>
>
>
> Now, for a reasonable user experience, the registration refresh pushes
> must not trigger the UI of incoming call.
>
> However, when an INVITE is received, the UA must be awoken immediately,
> which is the purpose of VoIP push.
>
>
>
> Does it make sense to make a different push type for registration refresh
> and for incoming calls?
>
>
>
> I'm not sure this is possible with the current RFC (and it is also against
> the spirit of the RFC), but I can't think of another way around it (besides
> using regular pushes instead of VoIP pushes, which might introduce delays,
> or having a registration with infinite expiration that will not require
> refreshes, which might leave many zomby registrations).
>
>
>
> See some discussion here: [2], [3].
>
>
>
> Thanks,
>
> Yehoshua
>
>
>
> [1]
> https://developer.apple.com/documentation/pushkit/pkpushtype/1614481-voip
>
> [2] https://developer.apple.com/forums/thread/117939
>
> [3] https://www.linphone.org/news/ios-13-important-changes-voipim-apps
> <https://protect2.fireeye.com/v1/url?k=3b41d605-65e13691-3b41969e-86d2114eab2f-a70c1febdc656b21&q=1&e=5b0ee252-62e3-4113-9072-c4697431936c&u=https%3A%2F%2Fwww.linphone.org%2Fnews%2Fios-13-important-changes-voipim-apps>
>
>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>