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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> [email protected] >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing >>> [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> [email protected] >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing >> [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > _______________________________________________ > Kamailio (SER) - Users Mailing > [email protected]https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
