28 May
2009
28 May
'09
5:03 p.m.
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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users