[sr-dev] ACKs to failure responses do not match transactions

Henning Westerholt hw at kamailio.org
Wed Oct 5 16:45:40 CEST 2011


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



More information about the sr-dev mailing list