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.
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
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 mailto: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 <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
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 Listsr-users@lists.kamailio.orghttps://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
Hi!
That is exactly my question. Now I have workaround for this (https://samael28.blogspot.com/2021/03/kamailio-and-delayed-cancel-on-ios.htm...) 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 mailto: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 <mailto: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 <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
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.htm...) 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 Listsr-users@lists.kamailio.orghttps://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 Listsr-users@lists.kamailio.orghttps://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
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_notific...
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 mailto: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 <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 <mailto: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 <mailto: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 <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
Hi,
If you look into this:
https://developer.apple.com/documentation/pushkit/responding_to_voip_notific...
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_notific...
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.htm...) 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 Listsr-users@lists.kamailio.orghttps://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 Listsr-users@lists.kamailio.orghttps://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 Listsr-users@lists.kamailio.orghttps://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
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_notific... 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 mailto: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 <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 <mailto: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 <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 <mailto: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 <mailto: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 <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
Hi Igor - Are you following the example from Frederico? We have implemented his idea for our iOS and Android apps... Make sure to send over the SIP CallID in the push notification. That way if a CANCEL does get sent (on JOIN/RESUME) the app can react to it correctly.
https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-...
Hello!
Yes, that's 100% correct. We're using same approach.
But if call was canceled before device is registered, and push notification is sent already?
You may actually test it with iOS, just call and cancel immediately to iOS > 13 device involving push.
Regards, Igor
On 13.03.2021 18:43, Jeremy McNamara wrote:
Hi Igor - Are you following the example from Frederico? We have implemented his idea for our iOS and Android apps... Make sure to send over the SIP CallID in the push notification. That way if a CANCEL does get sent (on JOIN/RESUME) the app can react to it correctly. https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-... https://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Igor Olhovskiy -
Ilie Soltanici -
Jeremy McNamara -
Jurijs Ivolga