Hi Gang
I have a strange issue after upgrading to 5.7
I use dlg_vars to keep some information until the end of the call to write them in a CDR.
One of those variables records the timestamp of the first invite to determine how long it took from the invite to the 'connection established' if at all.
The CDR is written when the BYE is being processed by the dialog module.
Strangely, since updating to 5.7 (used to work with 5.5 and 5.6 I think, but I could be mistaking as other changes were made to the config) my dialog variables are null when BYE is being processed.
reading the docs, I learned that that dlg_var are only polulated after loose_route() has been called.
So I added some logging statement to track if the BYE in question is processed by loose_route().
Yes, it is, loose_route() returns success on the BYE in question. But when I log the content of my dlg_var after loose_route() it is still null.
Any idea what the cause could be?
Hi
After more intensive testing, I narrowed the issue down.
CPE A => Kamailio+dialog => CPE B
CPE A is sending an INVITE with a session timer too smal for CPE B.
CPE B replies with 422.
This causes the dialog module to trigger the 'call failed' event and attempt to delete the dialog data.
CPA A does not consider the call failed. It repeats the INVITE with CSEQ + 1 and with the session timer as desired by CPE B.
The call is then processed as if in dialog, but some, strangely not all, dialog variables are lost.
I fear the repeated invite with identical callID and from_tag causes a race condition in handling the dialog variables.
I see there are two attempts by the dialog module to write a CDR with the same callID. After processing the 422 and when the call ends while processing BYE.
Hi all
I fear I have found a race condition when a new dialog is being created right after the old one with identical callid is being deleted. I logged a dialog variable on each message and reply and this is what I found:
=> INVITE Initial dialog variable set. <= 422 in 'failure route' dialog variable still present 422 is being relayed event_route[dialog:failed] triggered dialog variable present CDR written => ACK to 422 dialog variable present. => INVITE (same Callid/ftag/cseq++ session timer according 422) Initial dialog variable set <= 200 OK+SDP (manage_reply) event_route[dialog:start] triggered ### dialog variable set during the INVITE is lost! Probably all dialog variables set in the dialog unconfirmed stage are lost at this point.
I fear, some mechanism that is still cleaning out the previous dialog with the same callID is a bit over enthusiastic and also cleans out the dialog variables set after the new invite for the same call.
I found a work-around by using AVP variables during the unconfirmed stage and then use event_route[dialog:start] to set the desired dialog variables from those AVP.
I also had a quick peek at the code. It looks like every reply status >= 300 is considered a failure in unconfirmed dialog state. Not sure if this is true for the 422 status, this does not terminate a call but causes the caller to re-issue the invite.
=> More testing ongoing.
Hi all
I have found another solution:
Don't use: setflag(FLT_DLG);
call dlg_manage() on every message entering request_route before trying to set dlg_vars.
On a 422 reply I now get two CDR, but that is OK as long as I have correct dlg_vars on the second almost identical call (endpoint immediately re-sending the invite with smaller session timer) which is then connected and which I need for billing.
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello Benoit,
yes, there have been multiple reports of setflag together with dialog does not working correctly over the years, and dlg_manage needs to be used. We probably should remove the setflag for dialog to prevent confusion.
Cheers,
Henning
-----Original Message----- From: Benoit Panizzon via sr-users sr-users@lists.kamailio.org Sent: Montag, 8. April 2024 16:17 To: Benoît Panizzon via sr-users sr-users@lists.kamailio.org Cc: Benoit Panizzon benoit.panizzon@imp.ch Subject: [SR-Users] Solution found: Race condition in dialog on 422 reply deletes variables.
Hi all
I have found another solution:
Don't use: setflag(FLT_DLG);
call dlg_manage() on every message entering request_route before trying to set dlg_vars.
On a 422 reply I now get two CDR, but that is OK as long as I have correct dlg_vars on the second almost identical call (endpoint immediately re-sending the invite with smaller session timer) which is then connected and which I need for billing.
Mit freundlichen Grüssen
-Benoît Panizzon-
I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Benoît Panizzon -
Henning Westerholt