Hi,
When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings:
modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3)
I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL.
You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application.
Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask.
Thanks!
-- Alex
Interestingly, we are dealing with the same issue right now. The "solution" we have found thus far has been to limit the push notification expiration using the field apns-expiration and setting it to a relatively low value of epoch+(timer). For our scenarios, setting epoch+30s has been good enough,
Jeff
On Tue, Mar 11, 2025 at 2:05 PM Alex Balashov via sr-users < sr-users@lists.kamailio.org> wrote:
Hi,
When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings:
modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3)
I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL.
You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application.
Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask.
Thanks!
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi Jeff,
That's interesting. I wasn't aware of that field.
However, a 30s lifetime isn't going to work here; these endpoints are, unfortunately (from my perspective), in ring groups where another device answers, and some of them get quite a lot of calls this way. We really need to revoke any impression of an incoming call ASAP.
We considered sending another push notification with a payload that intimates an aborted call. This has attractive symmetry; if the incoming call experience wasn't prompted via any actual SIP, but by APN, then it should be cancelled by APN. However, Apple's guidance specifically advises against consecutive APNs for this type of purpose, and we've stuck to that so far.
-- Alex
On Mar 11, 2025, at 2:09 PM, Jeff Bilyk jbilyk@gmail.com wrote:
Interestingly, we are dealing with the same issue right now. The "solution" we have found thus far has been to limit the push notification expiration using the field apns-expiration and setting it to a relatively low value of epoch+(timer). For our scenarios, setting epoch+30s has been good enough,
Jeff
On Tue, Mar 11, 2025 at 2:05 PM Alex Balashov via sr-users sr-users@lists.kamailio.org wrote: Hi,
When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings:
modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3)
I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL.
You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application.
Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask.
Thanks!
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Jeff
Alex,
Usual issue https://blog.provoip.org/2021/03/kamailio-and-delayed-cancel-on-ios.html
Le mar. 11 mars 2025 à 19:35, Alex Balashov via sr-users < sr-users@lists.kamailio.org> a écrit :
Hi Jeff,
That's interesting. I wasn't aware of that field.
However, a 30s lifetime isn't going to work here; these endpoints are, unfortunately (from my perspective), in ring groups where another device answers, and some of them get quite a lot of calls this way. We really need to revoke any impression of an incoming call ASAP.
We considered sending another push notification with a payload that intimates an aborted call. This has attractive symmetry; if the incoming call experience wasn't prompted via any actual SIP, but by APN, then it should be cancelled by APN. However, Apple's guidance specifically advises against consecutive APNs for this type of purpose, and we've stuck to that so far.
-- Alex
On Mar 11, 2025, at 2:09 PM, Jeff Bilyk jbilyk@gmail.com wrote:
Interestingly, we are dealing with the same issue right now. The
"solution" we have found thus far has been to limit the push notification expiration using the field apns-expiration and setting it to a relatively low value of epoch+(timer). For our scenarios, setting epoch+30s has been good enough,
Jeff
On Tue, Mar 11, 2025 at 2:05 PM Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:
Hi,
When a CANCEL is received and matches a known INVITE transaction, it is
forked to all existing branches of that INVITE transaction, at least with these settings:
modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3)
I have a mobile endpoint that is slow to be pushed awake and reregister,
tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL.
You might ask why that's a problem, if it also didn't receive a forked
INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application.
Anyway, I am aware of numerous possible solutions to this problem in
principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask.
Thanks!
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to
the sender!
-- Jeff
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Hi Ihor,
Thank you for this; that's quite an elaborate solution. However, it might be a little too clever for my needs; in a comment on that post, you said you want to maintain alignment with mainline Linphone, whereas in this case, the client is highly customisable but there is a need to keep the server config simple and have as few moving parts as possible. :-)
In the end, I went with Gohar's approach of using specially coded MESSAGEs to signal deferred cancellation.
-- Alex
On Mar 12, 2025, at 6:17 AM, Ihor Olkhovskyi via sr-users sr-users@lists.kamailio.org wrote:
Alex,
Usual issue https://blog.provoip.org/2021/03/kamailio-and-delayed-cancel-on-ios.html
Le mar. 11 mars 2025 à 19:35, Alex Balashov via sr-users sr-users@lists.kamailio.org a écrit : Hi Jeff,
That's interesting. I wasn't aware of that field.
However, a 30s lifetime isn't going to work here; these endpoints are, unfortunately (from my perspective), in ring groups where another device answers, and some of them get quite a lot of calls this way. We really need to revoke any impression of an incoming call ASAP.
We considered sending another push notification with a payload that intimates an aborted call. This has attractive symmetry; if the incoming call experience wasn't prompted via any actual SIP, but by APN, then it should be cancelled by APN. However, Apple's guidance specifically advises against consecutive APNs for this type of purpose, and we've stuck to that so far.
-- Alex
On Mar 11, 2025, at 2:09 PM, Jeff Bilyk jbilyk@gmail.com wrote:
Interestingly, we are dealing with the same issue right now. The "solution" we have found thus far has been to limit the push notification expiration using the field apns-expiration and setting it to a relatively low value of epoch+(timer). For our scenarios, setting epoch+30s has been good enough,
Jeff
On Tue, Mar 11, 2025 at 2:05 PM Alex Balashov via sr-users sr-users@lists.kamailio.org wrote: Hi,
When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings:
modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3)
I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL.
You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application.
Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask.
Thanks!
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Jeff
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Best regards, Ihor (Igor) __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Alex Balashov -
Ihor Olkhovskyi -
Jeff Bilyk