6 Oct
2011
6 Oct
'11
2:07 a.m.
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:
--
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
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:
--
--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev