Hi!
But there would be a connection after app will wake up.
Wake up -> REGISTER -> Connection.
And after this it's about a time to send to app any info on canceled or
already answered calls.
Regards,
Igor
On 10.03.2021 18:18, Jurijs Ivolga wrote:
Hi,
If you look into this:
https://developer.apple.com/documentation/pushkit/responding_to_voip_notifications_from_pushkit
<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
<igorolhovs...@gmail.com <mailto:igorolhovs...@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
<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
<igorolhovs...@gmail.com <mailto:igorolhovs...@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
<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
<igorolhovs...@gmail.com <mailto:igorolhovs...@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
<igorolhovs...@gmail.com
<mailto:igorolhovs...@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
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<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
