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

[Hugh Waite]

We have discovered the cause of the problem I described, but we still do 
not understand why.

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?

Regards,
Hugh

On 04/10/2011 15:15, Hugh Waite wrote:
> We are seeing an issue with ACKs to failure responses.
>
> Our config is set up to forward an INVITE to another destination. It 
> replies with a 407 Auth Required. Kamailio sends an ACK to the 
> destination and relays the 407 back to the source. The source sends an 
> ACK, but this always fails the transaction match, so kamailio keeps 
> retransmitting the 407 (when using UDP)
>
> UA            KAM              UA
>
>  -- INVITE -->   -- INVITE -->
> <--   407  --
>                  --   ACK  -->
> <--   407  --
>  --   ACK  -->
>  ...
> <--   407  -- (retrans)
>  --   ACK  -->
>
> I wondered if it was the same issue as the stateless reply (Flyspray 
> #154), but this happens when we do a t_relay.
>
> Basically, when t_check_trans() is called for the ACK, it does not 
> terminate the script. I have worked my way into the t_check_trans() 
> code and found that it does not find a matching transaction; 
> matching_3261() in t_lookup.c returns 0 because there are no entries 
> in that hash bucket.
>
> Does anyone understand why this may be happening?
>
> Regards,
> Hugh
>


-- 
--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20111005/a4a37657/attachment.htm>