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

Daniel-Constantin Mierla miconda at gmail.com
Thu Oct 6 01:07:12 CEST 2011


Hi Hugh,

thanks for investigating and providing the patch. It is applied on 
master and 3.1 branches.

Cheers,
Daniel

On 10/5/11 5:58 PM, Hugh Waite wrote:
> I have found the problem.
>
> When msg_apply_changes() copies the sip_msg structure, it copies 
> msg_flags which includes FL_HASH_INDEX indicating that the hash_index 
> is valid (which is now zero).
>
> I have attached a patch which updates the msg_apply_changes() function 
> to copy the hash_index as it is in the original msg. This will be 
> valid if the flag is set, and therefore avoid unecessary hash calculation.
>
> Hugh
>
> On 05/10/2011 15:25, Hugh Waite wrote:
>> 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.
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> -- 
> --
> Hugh Waite
> Senior Design Engineer
> Crocodile RCS Ltd.
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda

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


More information about the sr-dev mailing list