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

[Alex Balashov]

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

-- 
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/