[sr-dev] t_check_trans with in-dialog requests

Daniel-Constantin Mierla miconda at gmail.com
Mon Jul 15 16:18:29 CEST 2013


because of the route headers, I guess there is a different path in 
config file, not hitting t_check_trans() from config for ACK (or at 
least the one I expected), ending in looking up the r-uri via location, 
like normal requests within dialog.

Can you try to hanlde the ack with t_check_trans() on that config path 
as well, before changing r-uri?


On 7/15/13 10:28 AM, Hugh Waite wrote:
> Hi,
> I've attached the signalling trace of this call.
> The ACK does have a Route set, but we think this is correct according 
> to § of RFC3261.
> "  If the INVITE request whose response is being acknowledged had 
> Route header fields, those header fields MUST appear in the ACK. This 
> is to ensure that the ACK can be routed properly through any 
> downstream stateless proxies.  "
> A failure response to an INVITE does not have a Contact header and a 
> reINVITE does not Record-Route, so the ACK needs to be constructed in 
> the same way as the INVITE w.r.t. request URI and Route set.
> When the ACK for the 407 arrives, can kamailio detect that the 
> transaction is in the 'Completed' state and drop it [1]?
> Hugh
> [1] RFC 6026 §8.6 which updates RFC3261 §17.2.1
> On 12/07/2013 16:22, Daniel-Constantin Mierla wrote:
>> Hello,
>> iirc, ACKs for negative replies should be hop-by-hop, without any 
>> route set. Maybe you can paste a ngrep with invite/407/ack to see 
>> exactly what is there.
>> On the other hand, t_check_trans() for ack returns true if there is 
>> an active invite transaction associated with it, because ack itself 
>> does not create transaction, being a request that doesn't take a reply.
>> Cheers,
>> Daniel
>> On 7/12/13 5:11 PM, Hugh Waite wrote:
>>> Hello,
>>> I have a question on the use of t_check_trans for in-dialog requests.
>>> If an in-dialog INVITE is challenged by kamailio (sending a 407 
>>> response), the ACK should be absorbed. However, the t_check_trans 
>>> function does not terminate the script. In our config, this means 
>>> the ACK gets sent to the client due to the route-set.
>>> Should t_check_trans recognise that this transaction was rejected 
>>> locally, even though there is an onward route-set?
>>> Hugh
> _______________________________________________
> 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
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130715/3054c521/attachment-0001.html>

More information about the sr-dev mailing list