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.