10 Mar
2021
10 Mar
'21
6:18 p.m.
Hi,
If you look into this:
https://developer.apple.com/documentation/pushkit/responding_to_voip_notifi…
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(a)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_notifi…
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(a)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.ht…)
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(a)gmail.com>
wrote:
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(a)gmail.com>
wrote:
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users