[Kamailio-Users] ACKed dialog remains in state 3 instead of 4

[Ovidiu Sas]

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 at 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 at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>