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

Daniel-Constantin Mierla miconda at gmail.com
Wed Jan 20 08:52:36 CET 2016


Hello,

can you send the reply you got to the CANCEL? I am interested mainly in
the parameters of Via header.

Cheers,
Daniel

On 20/01/16 02:48, 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
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
http://miconda.eu




More information about the sr-users mailing list