Hi Hennning,
loose_route() is what we are using.
But we use also dialog module for call counting etc.
We did not really change the default config.
This is the snippet in our config.
if (has_totag()) { # sequential requests within a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) {
t_on_reply("bye_reason"); setflag(FLT_ACC); # ... even if the transaction fails
But I think that is not the point.
The responses 18x responses are my real problem, because they have the same did in record-route but different to-tags because of the call forwarding scenario.
That leads to the BYE of the first fork. With this BYE they try to stop the call with the first to-tag. But the first fork ist already canceld. So Kamailio behaves correctly by not answering or forwarding anythin, but throwing a warning with tight dialog matching not possible.
Thats because at that point Kamailio does only know about the call with the second. So when the BYE is received by Kamailio the dialog modules can find the did but not the to-tog as Kamailio only has the second one left in memory.
Now the point is, is there a way to hold the first early dialog fork in memory until it is either terminatet with a CANCEL or BYE or the last fork with the corresponding did is terminatet.
I have read that ims_dialog or dialog_ng in our can handle things like this, but I also can't get it to work. By the way cdr generation does also not work with dialog_ng or ims_dialog (i also made tests with kamailio 5.3.5).
This is the problematic BYE Message (i deleted customer relatet infomations)
BYE sip:bob@kamailio:5060 SIP/2.0 Via: SIP/2.0/UDP carrier:5060;branch=z9hG4bKh6e7ie103g9amkc8gdo0.1 Max-Forwards: 65 To: sip:bob@kamailio;tag=11A2CF0C-5F578E7E000376B5-AA5BD700 From: sip:anonymous@anonymous.invalid;tag=h7g4Esbg_h7g4Esbg_c5478d8b Call-ID: ae36c13c31b5e910@a.b.c.d CSeq: 1313626 BYE Privacy: user;id Content-Length: 0 Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, OPTIONS, PRACK, PUBLISH, REGISTER, SUBSCRIBE, UPDATE Route: sip:kamailio-ip:5070;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5 Route: sip:sems-ip;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5
This one matches to the 180 of the call to callee b
SIP/2.0 180 Ringing Record-Route: sip:sems-ip;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5 Record-Route: sip:kamailio-ip:5070;r2=on;lr;ftag=h7g4Esbg_h7g4Esbg_c5478d8b;did=c4851.7b1c5 Via: SIP/2.0/UDP bob@kamailiko:5060;branch=z9hG4bK1s9rar309o1uf6j41ik0.1 Call-ID: ae36c13c31b5e910@a.b.c.d CSeq: 1313625 INVITE To: sip:bob@kamailio;tag=11A2CF0C-5F578E7E000376B5-AA5BD700 From: sip:anonymous@anonymous.invalid;tag=h7g4Esbg_h7g4Esbg_c5478d8b Content-Length: 0 Contact: <bob-pjhq8ddet3tu9@bobdomain;transport=udp>
I hope you can understand my problem a little better now.
BR Björn
Am 11.09.20 um 12:26 schrieb Henning Westerholt:
Hello Björn,
I was not referring to dialog stateful routing e.g. with dialog module. I was referring to the loose_route() function in your kamailio.cfg (e.g. compare to the default cfg in github).
Maybe you can quote the problematic BYE SIP message here.
Cheers,
Henning
Hello Björn,
1) about the signalisation The different 180 responses establishing different early dialogs, each with its own to-tag, as required from the standard. The 200 OK for the winning branch will then initialize the dialog. The BYE to this dialog should include the winning branch to-tag (in your case the TT2). Your carrier sends also a BYE to the early dialog, which is not recommend from the standard, but it is not forbidden.
2) about Kamailio routing I am not sure what you mean with "Kamailio cannot find the to-tag in memory". The method has_totag() is just checking for the existence of an to-tag in the message, without any memory storage involved.
The warning about the tight dialog matching failed is just a warning, if you do not use the dialog module for routing decision it should not cause these problems.
Your Kamailio should forward the BYE according to the Route header (if there is one) or the request-URI. In your example message below, this would be to the sems server.
If you want to implement some other logic, you can use e.g. the htable module to store information about call branches for some time and then expire it later on.
Cheers,
Henning
Hi Henning,
i think I've got a solution for this. I just make a check is_known_dialog. If not i reply with 481
I'm just testing, but it seem to work. The carrier is not sending retransmission of the BYE and the call seems to be stable.
By the way, the carrier is Telekom so discussions about standard is worthless here ;)
BR, Björn
Am 11.09.20 um 16:00 schrieb Henning Westerholt:
Hello Björn,
- about the signalisation
The different 180 responses establishing different early dialogs, each with its own to-tag, as required from the standard. The 200 OK for the winning branch will then initialize the dialog. The BYE to this dialog should include the winning branch to-tag (in your case the TT2). Your carrier sends also a BYE to the early dialog, which is not recommend from the standard, but it is not forbidden.
- about Kamailio routing
I am not sure what you mean with "Kamailio cannot find the to-tag in memory". The method has_totag() is just checking for the existence of an to-tag in the message, without any memory storage involved.
The warning about the tight dialog matching failed is just a warning, if you do not use the dialog module for routing decision it should not cause these problems.
Your Kamailio should forward the BYE according to the Route header (if there is one) or the request-URI. In your example message below, this would be to the sems server.
If you want to implement some other logic, you can use e.g. the htable module to store information about call branches for some time and then expire it later on.
Cheers,
Henning
-
Björn Klasen -
Henning Westerholt