[sr-dev] ACKs to failure responses do not match transactions
Hugh Waite
hugh.waite at crocodile-rcs.com
Wed Oct 5 17:58:01 CEST 2011
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20111005/4db39a17/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: textopsx.c.diff
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20111005/4db39a17/attachment.asc>
More information about the sr-dev
mailing list