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!