5 Apr
2024
5 Apr
'24
5:42 p.m.
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?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
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
______________________________________________________
5 Apr
5 Apr
6:46 p.m.
New subject: Handling 422 Message (was: Re: dlg_vars of existing dialog not set after loose_route())
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.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
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
______________________________________________________
6 Apr
6 Apr
9:30 a.m.
New subject: Race condition in dialog on 422 reply deletes variables.
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.
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
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
______________________________________________________
8 Apr
8 Apr
4:16 p.m.
New subject: 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
______________________________________________________
10 Apr
10 Apr
4:52 p.m.
New subject: Solution found: Race condition in dialog on 422 reply deletes variables.
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(a)lists.kamailio.org>
Sent: Montag, 8. April 2024 16:17
To: Benoît Panizzon via sr-users <sr-users(a)lists.kamailio.org>
Cc: Benoit Panizzon <benoit.panizzon(a)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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
24
days inactive
29
days old
4 comments
2 participants
participants (2)
-
Benoît Panizzon -
Henning Westerholt