Hi,

If you look into this:

https://developer.apple.com/documentation/pushkit/responding_to_voip_notifications_from_pushkit

Full quote:

After sending the initial push notification, don’t send additional push notifications to cancel the call or communicate new details to your app. Instead, communicate with the app directly over the network connection you established between it and your server. Using an existing network connection is generally faster than sending a push notification, and if network conditions are poor, APNs may be unable to deliver push notifications to the device anyway.

So based on my interpretation of what is written above, it seems they do not prohibit, but rather recommend it because of " Using an existing network connection is generally faster ". As far as we are discussing a case where there are no existing connections, I personally think this part of documentation is not relevant to that particular case.

Jurijs


On Wed, Mar 10, 2021 at 6:36 PM Igor Olhovskiy <igorolhovskiy@gmail.com> wrote:

Hi,

But Apple prohibits to use 2nd push for call cancel. That's not my decision.

https://developer.apple.com/documentation/pushkit/responding_to_voip_notifications_from_pushkit

After sending the initial push notification, don’t send additional push notifications to cancel the call or communicate new details to your app. Instead, communicate with the app directly over the network connection you established between it and your server.

Regards,
Igor
On 10.03.2021 15:18, Jurijs Ivolga wrote:
Hi,

My point is that you're referring to documentation where it is assumed that there is always connection between iOS app and Kamailio, but this might not be the case, like in the scenario that I described.

I think somebody who put this documentation is not really aware of all use cases and for this case it is better to use push for cancelling a call, IMHO.

Jurijs


On Wed, Mar 10, 2021 at 4:15 PM Igor Olhovskiy <igorolhovskiy@gmail.com> wrote:

Hi!

That is exactly my question. Now I have workaround for this (https://samael28.blogspot.com/2021/03/kamailio-and-delayed-cancel-on-ios.html) but maybe there is more efficient way, like "storing" dead transactions.

Regards,
Igor
On 10.03.2021 15:07, Jurijs Ivolga wrote:
Hi,

So if there is no connection between iOS app and Kamailio, what should we do? Lets imagine scenario: call arrives, app receives push notifications and then call is cancelled, even before connection is established.

Jurijs


On Wed, Mar 10, 2021 at 4:04 PM Igor Olhovskiy <igorolhovskiy@gmail.com> wrote:

Hello,

As I got, this is should be supported by app itself, not iOS.

And Apple docs says explicitly:

After sending the initial push notification, don’t send additional push notifications to cancel the call or communicate new details to your app. Instead, communicate with the app directly over the network connection you established between it and your server.

Regards,
Igor
On 10.03.2021 13:52, Ilie Soltanici wrote:
Hello, 

On Cancel we are sending just another Push Notification that indicates the call is cancelled, and the calling screen dissapear.

Regards,

On Wed 10 Mar 2021 at 12:28, Igor Olhovskiy <igorolhovskiy@gmail.com> wrote:
Hello!

Is there any way to "store" already finished transactions in tsilo? Idea
is to deliver, for example, canceled calls to the phone, when call
already was answered on other device, but push notification arrive
later? Major problem here, that there how it's working on iOS.

On iOS phone first show you calling screen, than - app is waking and
after app will register and receive invite with tsilo, it updates
calling screen with CallerID and other info. But if call was canceled
before, calling screen is shown, but app not receiving INVITE, so, call
screen is just there for some timeout (for Linphone, for ex, it's 20 sec).

Right now I've manage to do it via external SIPP call, that emulates
"fake missed call", but maybe there is other way to "store" already dead
transactions for some time?

PS: Unfortunately, can't solve this on mobile app level.

--
Regards,
Igor


_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users