Re: [SR-Users] topoh quirk with 200 OK for CANCEL

Hi, I'm using topoh and am running into lots of these errors: Jan 19 20:34:52 csrpus1 /usr/local/sbin/kamailio[3641]: ERROR: [R-DEFAULT-STATELESS-REPLY:nmhfrms2ib9Cnm9kS00Qtbtot5PMiQ0Ni1QKS5iKibuotel14Ygc] !> Received stateless reply 200 (CANCEL) from xxx.xxx.xxx.xxx:5060 Jan 19 20:34:53 csrpus1 /usr/local/sbin/kamailio[3639]: ERROR: tm [t_lookup.c:932]: t_reply_matching(): matching transaction found but callids don't match (received: nmhfrms2ib9Cnm9kS00Qtbtot5PMiQ0Ni1QKS5iKibuotel14Ygc stored: 51899BC6-569EE4330005CE1B-7D47C700_bleg) The call topology is: UAC --> Kamailio (+ topoh) --> PSTN GW Topoh is behaving precisely as expected, but it looks like we might have hit a TM case that topoh does not accommodate somehow: 1. A CANCEL comes in from the UAC and Kamailio sends a CANCEL for its branch to the PSTN GW. 2. Kamailio sends a '200 cancelling' for the UAC's branch backward. 3. The PSTN GW replies with a 200 OK for the CANCEL (PSTN GW branch) that contains the topoh-spoofed Call-ID, but for some reason Kamailio does not match this reply, as indicated by the above error. 4. Because the 200 OK reply was stateless and not matched to a CANCEL transaction, this causes Kamailio to retransmit the CANCEL to the PSTN GW, at which point it receives: 481 Call Leg/Transaction Does Not Exist 5. #4 repeats once more. I don't see any real harm from this situation, but it seems like something that needs fixing. The 487 Request Terminated final reply is processed and relayed correctly to the UAC, and the dialog ends appropriately everywhere. FWIW, I thought this might have to do with async processing of the initial INVITE (through mqueue + rtimer), so I turned it off, but it didn't make any difference. My CANCEL handling in the main request route looks like this: if(is_method("CANCEL")) { set_rtpengine_set("1"); rtpengine_delete(); if(!t_relay_cancel()) { sl_send_reply("500", "Internal Server Error"); exit; } xlog("L_ERR", "[R-MAIN:$ci] !> " "Corresponding INVITE transaction for CANCEL " "does not (or, no longer) exists\n"); exit; } So, it just looks like TM is not matching, and therefore not absorbing the 200 OK reply to its CANCEL to the upstream gateway -- when topoh is enabled. Any insights would be appreciated! -- Alex