Hi Alex
You can use $T_inv(...) to access attributes of the original INVITE transaction, to which the CANCEL pertains:
https://www.kamailio.org/wikidocs/cookbooks/5.8.x/pseudovariables/#t_invpv
Thank you, I'll check that out.
However, you may instead consider the attractive simplicity of just calling rtpengine_delete() for every CANCEL, regardless of whether RTPEngine was engaged. If the <Call-ID, From-tag> tuple is not recognised by RTPEngine, no harm, no foul -- not an even error. Yes, there is the overhead of a synchronous round trip to RTPEngine involved in this. However, in most cases, the consequences aren't too significant.
Unfortunately, life sometimes is not that simple, like when you have to find a way to process spiralling calls with rtpengine.
And yes, unfortunately loop-protect is not the solution as some codec quicks are needed depending on the direction of the call.
For this to work, each spiral needs to pass an unique callID to rtpengine. So adding a counter to the real callID, let's call it extraID did the trick (with an X- header and adding a rr_param to process messages the other way round etc.)
But i got stuck when trying to nicely tell rtpengine to stop listening for callID-extraID on a CANCEL as I have not yet found a way to get hold of that extraID.
rtpengine will eventually time out, but I try to tidy up correctly.