On Wednesday 05 October 2011, Hugh Waite wrote:
We have discovered the cause of the problem I described, but we still do not understand why.
Hello Hugh,
After a SIP request arrives we make some changes to the P-Preferred/Asserted-Identity headers after our own validation. To allow these changes to be visible later (e.g. in $hdr() variables) we call msg_apply_changes(). It seems that calling this function causes the transaction matching to fail for subsequent messages (e.g. ACK and CANCEL).
Non-Working Example: append_hf("My-Header: yes\r\n"); msg_apply_changes(); if (is_present_hf("My-Header")) { # log("Found my header") - this gets run } t_relay(); If the destination responds with a 4XX then the ACK does not match and the 4XX is retransmitted. If a CANCEL is sent, then it does not match and is not relayed.
Working Example: append_hf("My-Header: yes\r\n"); if (is_present_hf("My-Header")) { # log("Found my header") - this does not get run } t_relay(); In this example, the header is not found, but the transaction matching works properly
Is this something to do with re-parsing the request? And is it a bug to be investigated?
It is documentated that msg_apply_changes() is a bit risky function.. But i'm not aware of this side effects so far. It could be a design limitation (then it needs to be properly documented) or just a bug. Can you please open a bug report on the tracker about this?
Best regards,
Henning