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

[Yehoshua Gev <[e-mail]>]

Thanks.

So what should be the inputs to the logic that decides which push type to
use?
Would method + media types (of the SDP m= line) suffice?
Or maybe just pre-defined types (voice, voice+video?, message and register)
with pre-defined proxy logic for choosing between them?

Do you think we could come up with a format that will be general and not
Apple-specific?
Is there interest in the group for this?

Yehoshua

On Sat, Oct 17, 2020 at 11:44 AM Simon MORLAT <[e-mail]>
wrote:

> Hi Yehoshua,
>
> Let me answer your questions.
>
> * The pn-param is used by the proxy to know the application ID, which is
> necessary to know which credentials or TLS client certificate to connect to
> the Apple push server. The voip&remote advertise that the app understands
> both voip and remote push notifications, and as such two
> certificates/credentials should be available to the server for this.
>
> 1. Yes. I saw your other suggestion, which is indeed more readable, but
> breaks compatibility with RFC8599 .
>
> 2. The proxy has forcibly some platform specific logic to handle push
> notifications. It cannot be unaware that for Apple platform, the "voip"
> type must only be used for calls. Note that it is not a question of SIP
> method, because SIP INVITE can be used to establish chat sessions with MSRP
> protocol for example, and in this case a "voip" type notification must not
> be used.
>
> 3. It could indeed, however it discloses information to push notification
> servers. In linphone, we do not pass it for this reason. Instead, the
> CallKit view is subsequently updated to display the caller-id once the
> INVITE has arrived (which usually takes no more than a few seconds).
>
> The background updates push notifications (
> https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app?language=objc)
> are reliable. They are indeed rate limited (3 per hour) which makes them
> unsuitable to advertise calls or incoming messages. But in order to trigger
> a REGISTER request it's good enough, and they do not require to show
> something to the user: the work silently.
> To make the system reliable, I imagine the registrar could send a
> background push notification at 80 % of expire time, and then once a day
> during a guard period of XX days in order to give additional chances for
> apps that temporarily have no longer access to the network to finally
> refresh their registration.
>
> Best regards,
>
> Simon
>
>
> Le lun. 12 oct. 2020 à 16:40, Yehoshua Gev <[e-mail]> a écrit :
>
>> Hi Simon,
>>
>> Thanks for your detailed explanation of the behavior you have implemented.
>>
>> One Q: How is the "pn-param=DEF123GHIJ.org.linphone.phone.voip&remote"
>> used?
>> Does the server really make use of the "&remote" suffix or it can be used
>> like "DEF123GHIJ.org.linphone.phone.*" with the "*" being always replaced
>> with the service?
>>
>> In any case, I'm willing to help with work on a new RFC, but sadly I
>> don't have much time for it.
>>
>> Regarding the scope of the updated RFC, I think there are several issues
>> that should be addressed:
>>
>> 1. How the UA passes several "pn-*"-sets for a single registration. The
>> solution you've done on Linphone seems like a good approach if backward
>> compatibility with RFC 8599 is required.
>>
>> 2. How would the proxy decide which pn-*-values-set to use for a specific
>> push notification? For example, a naive approach is to pre-define a mapping
>> between "pr-*"-set and SIP methods (i.e., INVITE will use a "voip" params).
>>
>> 3. (maybe unrelated) For good user experience, the caller-id should be
>> passed along with the voip push notification so the UI of incoming calls
>> can display it immediately.
>>
>> BTW, regarding triggering of registration refreshes, our iOS developers
>> say that in order for a push notification to work reliably (i.e., assured
>> to be processed by the application even if it is terminated), it must have
>> some UI notification. This means that the user will be informed of each
>> registration refresh. If this is true, then the expiry time must be kept
>> very long (weeks/months) in any case. Is this also your understanding?
>>
>>
>> Yehoshua
>>
>>
>> On Sun, Oct 11, 2020 at 11:43 PM Simon MORLAT <[e-mail]>
>> wrote:
>>
>>> Hi Yehoshua,
>>>
>>> Thank you for starting this discussion.
>>> My company is developing the Linphone software (https://linphone.org),
>>> 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
>>>
>>> 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
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>