Re: CANCEL on a Ringing Sip Dialog is not relayed

Hi!

had similar issue a while ago.

look at your two Vias side by side. Everything is identical: transport
(TCP), port (49196), branch, rport, alias, except the host:

INVITE: ... TCP 192.168.179.124:49196 ... (LAN address)
CANCEL: ... TCP 82.xx.xxx.xxx:49196 ... (NAT public address)

That single host difference is what fails the match.
A CANCEL constructed by a client MUST carry a single Via that is identical
to the top Via value of the request being cancelled.
Your client changed its own sent-by between the INVITE and the CANCEL, so
it broke that rule. Kamailio is doing the correct thing by refusing to
match.

Here is the workaround:
(make sure you have loadmodule "textopsx.so" in your script)

modparam("htable", "htable", "cxvia=>size=10;autoexpire=180;")

for the initial INVITE, add these lines to remember the client's real top
Via
if (is_method("INVITE") && !has_totag()) {
    $sht(cxvia=>$ci) = $(hdr(Via)[0]);
}

Put this in your CANCEL handling

if (is_method("CANCEL")) {
    $var(via0) = $sht(cxvia=>$ci);
    if ($var(via0) != $null && $(hdr(Via)[0]) != $var(via0)) {
        remove_hf("Via");
        insert_hf("Via: $var(via0)\r\n", "Max-Forwards");
        msg_apply_changes();
    }
    if (t_check_trans()) {
        t_relay();
    }
    exit;
}

Note that remove_hf("Via") will remove all the Via headers, might be an
issue if you're using topology hiding.

Overall, this is a palliative workaround, not a final solution because the
real culprit is the client that keeps the Via headers. The fix should be on
the client, not on the server.
Is the client a softphone? Which softphone?


Atenciosamente / Kind Regards / Cordialement / Un saludo,


*Sérgio Charrua*

*www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>*

*OpenTelecom* - Consulting for Telecoms, Lda
Tel.: +351  <callto:+351+91+104+12+66>91 631 11 44

Email : *[email protected] <[email protected]>*

This message and any files or documents attached are strictly confidential
or otherwise legally protected.

It is intended only for the individual or entity named. If you are not the
named addressee or have received this email in error, please inform the
sender immediately, delete it from your system and do not copy or disclose
it or its contents or use it for any purpose. Please also note that
transmission cannot be guaranteed to be secure or error-free.








On Wed, Jun 10, 2026 at 10:03 AM Johannes Westhuis via sr-users <
[email protected]> wrote:

> Hi all,
>
> I have an issue with Kamailio 6.1.3_bpo13 (installed from
> http://deb.kamailio.org/kamailio61 trixie/main amd64 Packages)
>
> My Kamailio is acting as a proxy and is working very nicely. In certain
> circumstances (that i am not really able to grasp) a CANCEL request for a
> ringing call is not relayed as expected.
>
> In the log, i can see, that the transaction matching fails.
>
> The following messages are exchanged:
>
> Client -> INVITE -> Kamailio (Via: SIP/2.0/TCP 192.168.179.124:49196
> ;rport;branch=z9hG4bKPj32D404B5-C596-48B9-93B4-1FA14B659405;alias)
> Client <- 100 Trying <- Kamailio
> Client <- 183 Session Progress <- Kamailio
> Client -> PRACK -> Kamailio
> Client <- 200 OK (PRACK) <- Kamailio
> Client <- 180 Ringing <- Kamailio
> - 7 seconds pause -
> Client -> CANCEL -> Kamailio (Via: SIP/2.0/TCP
> 82.xx.xxx.xxx:49196;rport;branch=z9hG4bKPj32D404B5-C596-48B9-93B4-1FA14B659405;alias)
>
> The Via headers are send by the client, the second one contains the public
> ip of the clients nat.
>
> The log snippet, that i think is relevant here:
>
> 2026-06-05T13:42:19.856635+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} nathelper
> [nhelpr_funcs.c:294]: get_contact_uri(): no Contact header
> 2026-06-05T13:42:19.856649+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} <core>
> [core/parser/sdp/sdp.c:865]: parse_sdp(): message body has length zero
> 2026-06-05T13:42:19.856664+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} htable [ht_api.c:248]:
> ht_get_table(): htable found [vtp]
> 2026-06-05T13:42:19.856679+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:1045]:
> t_lookupOriginalT(): searching on hash entry 18213
> 2026-06-05T13:42:19.856696+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:513]:
> matching_3261(): RFC3261 transaction matching failed - via branch
> [z9hG4bKPj32D404B5-C596-48B9-93B4-1FA14B659405]
> 2026-06-05T13:42:19.856710+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:1142]:
> t_lookupOriginalT():  no CANCEL matching found!
> 2026-06-05T13:42:19.856725+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [t_lookup.c:1144]:
> t_lookupOriginalT(): lookup completed
> 2026-06-05T13:42:19.856741+00:00 proxy1 /usr/sbin/kamailio[5273]: DEBUG:
> {1 1067 CANCEL 591BDD7F-5779-42F8-BF33-4F801CCA02C0} tm [tm.c:1327]:
> ki_t_lookup_cancel_flags(): lookup_original: t_lookupOriginalT returned:
> (nil)
>
> Is the IP in the Via used for matching the transaction?
> What would be the right thing to do here?
>
> Best regards,
> Johannes
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!