[sr-dev] t_check_trans with in-dialog requests

[Hugh Waite]

Hi,
This is happening in the WITHINDLG route of our config. For gruu'd 
clients, we run t_check_trans and then do the location lookup. I added 
some extra debug and found it is returning -1 for ACKs to both 407 and 
200 in-dialog responses.

    route[WITHINDLG] {
       if (has_totag()) {
         if (is_method("ACK")) {
           xlog("L_WARN", "Handling ACK...\n");
           t_check_trans();
           xlog("L_WARN", "...returned $rc\n");
         }
         ...
         # lookup/forward etc.
       }
    }

Hugh

On 15/07/2013 15:18, Daniel-Constantin Mierla wrote:
> Hello,
>
> 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?
>
> Cheers,
> Daniel
>
> 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 §17.1.1.3 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
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.

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