[SR-Users] iOS CallKit and tsilo
Igor Olhovskiy
igorolhovskiy at gmail.com
Wed Mar 10 19:12:18 CET 2021
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
> <igorolhovskiy at gmail.com <mailto:igorolhovskiy at 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
>> <igorolhovskiy at gmail.com <mailto:igorolhovskiy at 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
>>> <igorolhovskiy at gmail.com <mailto:igorolhovskiy at 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 at gmail.com
>>>> <mailto:igorolhovskiy at 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 at lists.kamailio.org
>>>> <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org
>>> <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210310/a6dd4ddc/attachment.htm>
More information about the sr-users
mailing list