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