Thank you for the excellent insight. I think you may be right about the race condition on dialogs since it is a combination of a random crash on a high-use server. I have to deal with some pre-requisites later this week, but I will try to give more gdb feedback confirming the dst->send_sock field you mentioned when I do.

You suggested a workaround which I am trying to implement carefully. If I wanted to totally avoid the "dialog" mode but still populate my Homer (HEP) server with records that give feedback on full calls, how would I think in terms of 'transaction' or 'message' modes instead? Would I just use sip_trace on all request_route transactions? I am only asking here because it doesn't seem clear about what these modes entail in the 5.4.x module documentation.

"dialog" seemed like the clear choice for me since I was attempting to provide call debug information to my Homer server so, to be honest, I am a little confused about the use-case for the other two modes?

Per the doc:

In message tracing mode only the current message is stored or mirrored. In transaction tracing mode, all the messages of the current transaction are stored or mirrored. In dialog tracing mode, all the messages of the current dialog are stored or mirrored.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.