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

Alex Balashov abalashov at evaristesys.com
Wed Jan 20 02:52:13 CET 2016


PS. Running 4.3:583dc060.

On 01/19/2016 08:48 PM, Alex Balashov wrote:

> 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/



More information about the sr-users mailing list