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
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 GWTopoh is behaving precisely as expected, but it looks like we might have hit a TM case that topoh does not accommodate somehow:
- A CANCEL comes in from the UAC and Kamailio sends a CANCEL for its
branch to the PSTN GW.
Kamailio sends a '200 cancelling' for the UAC's branch backward.
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.
- 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
- #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
I went back and looked through topoh commit history and found this:
https://github.com/kamailio/kamailio/commit/78324dcc09d0a51fa02a960a40faa7fd...
After I applied the advice given therein, the error seems to have gone away. I assume this applies because CANCEL is also a locally generated request, since it is hop-by-hop.
However, I would be curious for some elaboration as to why this step is necessary and what connection the dialog module has to it.
On 01/19/2016 08:57 PM, Alex Balashov wrote:
After I applied the advice given therein, the error seems to have gone away.
Alas, false hope. The problem persists.
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:
- A CANCEL comes in from the UAC and Kamailio sends a CANCEL for its
branch to the PSTN GW.
Kamailio sends a '200 cancelling' for the UAC's branch backward.
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.
- 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
- #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
On 01/20/2016 02:52 AM, Daniel-Constantin Mierla wrote:
Hello,
can you send the reply you got to the CANCEL? I am interested mainly in the parameters of Via header.
Thanks, Daniel. I sent it to you privately.
On 20/01/16 16:48, Alex Balashov wrote:
On 01/20/2016 02:52 AM, Daniel-Constantin Mierla wrote:
Hello,
can you send the reply you got to the CANCEL? I am interested mainly in the parameters of Via header.
Thanks, Daniel. I sent it to you privately.
Just about to look at it. I noticed it as I have emails from Kamailio devs filtered on a special folder, but I had some other tasks to do so far today.
But you reminded me that I should highlight again that private replies to mailing discussions are unlikely to be followed, going in the common folder (no longer filtered by mailing list rules), where I have a lot of unsolicited emails and I don't check it often -- searching now the [sr-users] prefix on subject shows couple of hundreds there, so if anyone replied directly to me to a mailing list discussion without being advised to do so and wants an answer, better resend to mailing list.
Cheers, Daniel
On 01/20/2016 11:01 AM, Daniel-Constantin Mierla wrote:
But you reminded me that I should highlight again that private replies to mailing discussions are unlikely to be followed, going in the common folder (no longer filtered by mailing list rules), where I have a lot of unsolicited emails and I don't check it often -- searching now the [sr-users] prefix on subject shows couple of hundreds there, so if anyone replied directly to me to a mailing list discussion without being advised to do so and wants an answer, better resend to mailing list.
Yeah, I know. And I agree with you one hundred percent on the reasons for why threads should be kept public consistently.
Sometimes there are packet captures with customer proprietary network information or other topology information, however, and replacing with fake values is not always easy. In some situations, the original values can be integral to the problem. In those cases and in those cases only, I may send something privately.
If you insist, I can post the CANCEL-200 OK exchange with proprietary topology redacted.
-- Alex
On 20/01/16 17:04, Alex Balashov wrote:
On 01/20/2016 11:01 AM, Daniel-Constantin Mierla wrote:
But you reminded me that I should highlight again that private replies to mailing discussions are unlikely to be followed, going in the common folder (no longer filtered by mailing list rules), where I have a lot of unsolicited emails and I don't check it often -- searching now the [sr-users] prefix on subject shows couple of hundreds there, so if anyone replied directly to me to a mailing list discussion without being advised to do so and wants an answer, better resend to mailing list.
Yeah, I know. And I agree with you one hundred percent on the reasons for why threads should be kept public consistently.
Sometimes there are packet captures with customer proprietary network information or other topology information, however, and replacing with fake values is not always easy. In some situations, the original values can be integral to the problem. In those cases and in those cases only, I may send something privately.
If you insist, I can post the CANCEL-200 OK exchange with proprietary topology redacted.
No need to send on mailing list, traces/sensitive data can be sent directly - if there is a note on mailing list it was send, I will grab it for anyone, this is something common done so far.
Cheers, Daniel
Can you check with commit:
https://github.com/kamailio/kamailio/commit/0ce66908ee9da74806e2fa506ef98b5f...
It seems it was a stupid improper cancel detection bug, but I didn't have the environment the test the patch.
Cheers, Daniel
On 20/01/16 16:48, Alex Balashov wrote:
On 01/20/2016 02:52 AM, Daniel-Constantin Mierla wrote:
Hello,
can you send the reply you got to the CANCEL? I am interested mainly in the parameters of Via header.
Thanks, Daniel. I sent it to you privately.
On 01/20/2016 12:35 PM, Daniel-Constantin Mierla wrote:
Can you check with commit:
https://github.com/kamailio/kamailio/commit/0ce66908ee9da74806e2fa506ef98b5f...
It seems it was a stupid improper cancel detection bug, but I didn't have the environment the test the patch.
That seems to have fixed it. Thank you very much, as always, for your help, diligence and timely response! It is inestimably appreciated.
OK, thanks for testing -- patch backported to 4.3 branch.
Cheers, Daniel
On 21/01/16 00:49, Alex Balashov wrote:
On 01/20/2016 12:35 PM, Daniel-Constantin Mierla wrote:
Can you check with commit:
https://github.com/kamailio/kamailio/commit/0ce66908ee9da74806e2fa506ef98b5f...
It seems it was a stupid improper cancel detection bug, but I didn't have the environment the test the patch.
That seems to have fixed it. Thank you very much, as always, for your help, diligence and timely response! It is inestimably appreciated.
-
Alex Balashov -
Daniel-Constantin Mierla