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

From: Yehoshua Gev <[email-masked]>
Date: Sun, 11 Oct 2020 18:07:23 +0300

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

---

From: Simon MORLAT <[email-masked]>
Date: Sun, 11 Oct 2020 22:43:29 +0200

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 <[email-masked]> a écrit :

> receiving VoIP push notifications *must report the call quickly to
> CallKit, so it can alert the user* to the presence of the incoming call."
>
> Now, for a reasonable user experience, the registration refresh pushes
> must not trigger the UI of incoming call.
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Yehoshua Gev <[email-masked]>
Date: Mon, 12 Oct 2020 17:40:28 +0300

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 <[email-masked]>
wrote:

> 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.
>
> 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:
>
> 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.
>
>> 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).
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Oct 2020 14:55:28 +0000

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 <[email-masked]> On Behalf Of Simon MORLAT
Sent: sunnuntai 11. lokakuuta 2020 23.43
To: Yehoshua Gev <[email-masked]>
Cc: sipcore <[email-masked]>
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.

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 <[email-masked]<mailto:[email-masked]>> a écrit :
Hi All,

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."

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).

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Yehoshua Gev <[email-masked]>
Date: Tue, 13 Oct 2020 13:17:47 +0300

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 <
[email-masked]> 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 <[email-masked]> *On Behalf Of *Simon MORLAT
> *Sent:* sunnuntai 11. lokakuuta 2020 23.43
> *To:* Yehoshua Gev <[email-masked]>
> *Cc:* sipcore <[email-masked]>
> *Subject:* Re: [sipcore] Push notifications with iOS 13 (RFC 8599)
>
>
>
> Hi Yehoshua,
>
>
>
> 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.
>
> <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>
>
>
>
> <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>
>
>
>

---

From: Simon MORLAT <[email-masked]>
Date: Sat, 17 Oct 2020 10:43:40 +0200

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 <[email-masked]> a écrit :

> 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
>> My company is developing the Linphone software (https://linphone.org),

---

From: Simon MORLAT <[email-masked]>
Date: Sat, 17 Oct 2020 10:51:10 +0200

Hi Christer,

>From our experience with Apple push notifications, they are reliable. They
can be postponed by a few minutes, but for refreshing a register that has a
typical expires of one hour, that's reasonable.
It is still possible to use long expires (24 hours for example), and have
the server continue to send background push notifications after the expiry
for a period of time in order to make sure that the app doesn't get lost if
for example it has temporarily no possible access to the network.

Best regards,

Simon

---

From: Yehoshua Gev <[email-masked]>
Date: Sun, 18 Oct 2020 12:38:17 +0300

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 <[email-masked]>
wrote:

>> In any case, I'm willing to help with work on a new RFC, but sadly I
>> don't have much time for it.
>>
>>> 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:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Oct 2020 14:42:50 +0000

Hi,

Whatever the solution is, it has to be backward compatible, in order to minimize the impacts on existing deployments.

Without having thought too much about it, one straight forward solution would be to define new pn- parameters for non-VoIP push notifications. I assume we would need new pn- parameters for pn-param and pn-prid.

Regards,

Christer

From: sipcore <[email-masked]> On Behalf Of Yehoshua Gev
Sent: sunnuntai 18. lokakuuta 2020 12.38
To: Simon MORLAT <[email-masked]>
Cc: sipcore <[email-masked]>
Subject: Re: [sipcore] Push notifications with iOS 13 (RFC 8599)

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yehoshua,

* 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 <[email-masked]<mailto:[email-masked]>> a écrit :
Hi Simon,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Yehoshua,

My company is developing the Linphone software (https://linphone.org<https://protect2.fireeye.com/v1/url?k=7f8ad100-212a1345-7f8a919b-8692dc8284cb-5a8c1a2833f5db51&q=1&e=eea69fa0-bdd8-4e64-be1e-fc992ce3c3b2&u=https%3A%2F%2Flinphone.org%2F>), an cross platform open-source SIP softphone and SDK.

https://wiki.linphone.org/xwiki/wiki/public/view/Lib/Getting%20started/iOS/#HUpdateContactURIparameters<https://protect2.fireeye.com/v1/url?k=434f8a76-1def4833-434fcaed-8692dc8284cb-995c031be5ab3584&q=1&e=eea69fa0-bdd8-4e64-be1e-fc992ce3c3b2&u=https%3A%2F%2Fwiki.linphone.org%2Fxwiki%2Fwiki%2Fpublic%2Fview%2FLib%2FGetting%2520started%2FiOS%2F%23HUpdateContactURIparameters>

Best regards,

Simon

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=c352f674-9df23431-c352b6ef-8692dc8284cb-84d24c839a3287cd&q=1&e=eea69fa0-bdd8-4e64-be1e-fc992ce3c3b2&u=https%3A%2F%2Fwww.linphone.org%2Fnews%2Fios-13-important-changes-voipim-apps>