Hello,
I was excited to find that I can now use dlg_manage instead of record_route so that I no longer need the record_route parameter but I now found a strange situation that maybe somebody can explain.
I am sending an INVITE to kamailio, and kamailio sends it to a provider. It's like this:
asterisk-----INVITE cseq 1-------> kamailio -----INVITE cseq 1-----------> provider asterisk<-----407 auth required---- kamailio <-----407 auth required------- provider asterisk-----ACK----------------------> kamailio -----ACK------------------------> provider When 407 reaches kamailio, kamailio changes dialog state to state 5. But the dialog is not deleted.
Then the INVITE arrives again, authenticated, and a new dialog is created, but having the same callid and from-tag: asterisk-----INVITE cseq 2-------> kamailio -----INVITE cseq 2----------> provider asterisk<---- 200OK ----------------- kamailio <-----200OK--------------------- provider asterisk-----ACK----------------------> kamailio -----ACK------------------------> provider When this ACK arrives to kamailio, dlg_manage is called and kamailio searches for the dialog in the dialog list. It finds one but with state 5 (I printed a debug in the source), probably finds the first one, and thus it can no longer identify the ACK as being part of the second dialog. For this reason, the dialog created during the second invite remains with state 3.
This causes sometimes the BYE not to be accepted correctly either, and some dialogs remain stuck in the database until they expire.
Does anybody know why, when a dialog match is searched, when a match that is in state 5 in found, the search is interrupted? I was thinking of changing this so that the search can continue and the second INVITE dialog can be found, but I'm not sure that's safe.
Thanks a lot, Catalina Oancea
Catalina,
Unless I am missing something, dlg_manage() does not allow you to avoid setting Record-Route; how else will the endpoints know to send sequential messages through the proxy once the dialog is established?
The purpose of dlg_manage() is to provide an alternative to setting a flag for the purpose of indicating to Kamailio that the dialog the current INVITE seeks to establish should be statefully tracked and exposed to additional user-defined dialog module functionality (profiles, statistics, etc.) and other module functionality relying on internal API callbacks from the dialog module.
modparam("dialog", "dlg_flag", 4)
route { ...
# Process initial INVITE.
if(is_method("INVITE")) { ...
setflag(4); # Track this dialog.
}
}
Hello,
On 05/27/2009 05:38 PM, Alex Balashov wrote:
Catalina,
Unless I am missing something, dlg_manage() does not allow you to avoid setting Record-Route;
you can use dlg_manage() without record-routing. It can match based on call-id/from tag/to tag.
how else will the endpoints know to send sequential messages through the proxy once the dialog is established?
Could be static routing, depending from case to case. For example, in some of my deployments I have:
[users] ==== [inbound proxy] ===== [main proxy] ===== [outbound proxy] ===== [users]
inbound and outbound add RR, the rest is static, if not coming from main proxy, send request there. if coming from inbound, send to outbound and viceversa.
Cheers, Daniel
The purpose of dlg_manage() is to provide an alternative to setting a flag for the purpose of indicating to Kamailio that the dialog the current INVITE seeks to establish should be statefully tracked and exposed to additional user-defined dialog module functionality (profiles, statistics, etc.) and other module functionality relying on internal API callbacks from the dialog module.
modparam("dialog", "dlg_flag", 4) route { ... # Process initial INVITE. if(is_method("INVITE")) { ... setflag(4); # Track this dialog. } }
Hello Catalina,
The same issue that you are describing here should show up if you are looping a a call through the same proxy. In order to circumvent this issue, you will need to force dialog matching based on did. Did matching should work fine. This is one of the limitations of the dialog module. I'm using dlg_match_mode 2 without any issues, but without authentications and looping on my proxy.
Regards, Ovidiu Sas
On Wed, May 27, 2009 at 10:30 AM, catalina oancea catalina.oancea@gmail.com wrote:
Hello,
I was excited to find that I can now use dlg_manage instead of record_route so that I no longer need the record_route parameter but I now found a strange situation that maybe somebody can explain.
I am sending an INVITE to kamailio, and kamailio sends it to a provider. It's like this:
asterisk-----INVITE cseq 1-------> kamailio -----INVITE cseq 1-----------> provider asterisk<-----407 auth required---- kamailio <-----407 auth required------- provider asterisk-----ACK----------------------> kamailio -----ACK------------------------> provider When 407 reaches kamailio, kamailio changes dialog state to state 5. But the dialog is not deleted.
Then the INVITE arrives again, authenticated, and a new dialog is created, but having the same callid and from-tag: asterisk-----INVITE cseq 2-------> kamailio -----INVITE cseq 2----------> provider asterisk<---- 200OK ----------------- kamailio <-----200OK--------------------- provider asterisk-----ACK----------------------> kamailio -----ACK------------------------> provider When this ACK arrives to kamailio, dlg_manage is called and kamailio searches for the dialog in the dialog list. It finds one but with state 5 (I printed a debug in the source), probably finds the first one, and thus it can no longer identify the ACK as being part of the second dialog. For this reason, the dialog created during the second invite remains with state 3.
This causes sometimes the BYE not to be accepted correctly either, and some dialogs remain stuck in the database until they expire.
Does anybody know why, when a dialog match is searched, when a match that is in state 5 in found, the search is interrupted? I was thinking of changing this so that the search can continue and the second INVITE dialog can be found, but I'm not sure that's safe.
Thanks a lot, Catalina Oancea
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-
Alex Balashov -
catalina oancea -
Daniel-Constantin Mierla -
Ovidiu Sas