11 Sep
2020
11 Sep
'20
3:12 p.m.
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)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)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
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428