[sr-dev] t_check_trans with in-dialog requests - SOLVED
Hugh Waite
hugh.waite at crocodile-rcs.com
Fri Jul 19 12:30:02 CEST 2013
Hi,
Turns out there was a very easy fix. I was not running t_newtran() at
the AUTH step in the config so the ACK did not have a transaction to match.
Adding a t_newtran() before the challenge has solved the problem.
Thanks for the help,
Hugh
On 17/07/2013 13:16, Daniel-Constantin Mierla wrote:
> Hello,
>
> I tested with a call between jitsi and csipsimple, authenticating an
> INVITE for a call on hold and the ACK for 407 is intercepted by tm.
>
> I used openrcs.com which runs kamailio from few days ago, see the
> trace below (note that I reverted to the old config, so no more auth
> for re-invites on openrcs.com, if you think of trying yourself, but
> should just go the same with the default config file -- for me was
> easier as I had two phones already configured).
>
> Again, be sure the r-uri for ACK is not changed (this check can be
> turned off, look at the sources of t_lookup_request() function in
> tm/t_lookup.c to understand better how the ack is matched to the
> invite transaction).
>
> Cheers,
> Daniel
>
> U 2013/07/17 13:37:18.672912 91.64.193.7:5060 -> 78.47.51.102:5060
> INVITE sip:micondax at 91.64.193.7:47944;ob SIP/2.0.
> CSeq: 1 INVITE.
> From: <sip:daniel at openrcs.com>;tag=eec0288f.
> To: <sip:micondax at openrcs.com>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.
> Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.
> Max-Forwards: 70.
> Route: <sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes>.
> Via: SIP/2.0/UDP
> 192.168.178.31:5060;branch=z9hG4bK-353538-3ca2602df68a86071a1c105f5659404e.
> Contact: "daniel"
> <sip:daniel at 192.168.178.31:5060;transport=udp;registering_acc=openrcs_com>.
> User-Agent: Jitsi2.3.4690.9793Mac OS X.
> Content-Type: application/sdp.
> Content-Length: 601.
> .
>
> U 2013/07/17 13:37:18.674008 78.47.51.102:5060 -> 91.64.193.7:5060
> SIP/2.0 407 Proxy Authentication Required.
> CSeq: 1 INVITE.
> From: <sip:daniel at openrcs.com>;tag=eec0288f.
> To: <sip:micondax at openrcs.com>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.
> Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.
> Via: SIP/2.0/UDP
> 192.168.178.31:5060;branch=z9hG4bK-353538-3ca2602df68a86071a1c105f5659404e;rport=5060;received=91.64.193.7.
> Proxy-Authenticate: Digest realm="openrcs.com",
> nonce="UeaDGlHmge5QrNqex8mLThI/UGoO/wyB".
> Server: kamailio (4.1.0-dev7 (x86_64/linux)).
> Content-Length: 0.
> .
>
>
> U 2013/07/17 13:37:18.713261 91.64.193.7:5060 -> 78.47.51.102:5060
> ACK sip:micondax at 91.64.193.7:47944;ob SIP/2.0.
> Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.
> Max-Forwards: 70.
> From: <sip:daniel at openrcs.com>;tag=eec0288f.
> To: <sip:micondax at openrcs.com>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.
> Via: SIP/2.0/UDP
> 192.168.178.31:5060;branch=z9hG4bK-353538-3ca2602df68a86071a1c105f5659404e.
> CSeq: 1 ACK.
> Route: <sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes>.
> Content-Length: 0.
> .
>
> U 2013/07/17 13:37:18.713278 91.64.193.7:5060 -> 78.47.51.102:5060
> INVITE sip:micondax at 91.64.193.7:47944;ob SIP/2.0.
> CSeq: 2 INVITE.
> From: <sip:daniel at openrcs.com>;tag=eec0288f.
> To: <sip:micondax at openrcs.com>;tag=QmVmF5nduqQ2agp8SF8dMRCT-ix11.w3.
> Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.
> Max-Forwards: 70.
> Route: <sip:78.47.51.102;lr=on;did=7d2.5f5;nat=yes>.
> Contact: "daniel"
> <sip:daniel at 192.168.178.31:5060;transport=udp;registering_acc=openrcs_com>.
> User-Agent: Jitsi2.3.4690.9793Mac OS X.
> Content-Type: application/sdp.
> Via: SIP/2.0/UDP
> 192.168.178.31:5060;branch=z9hG4bK-353538-13263d273bd563595f7035d30c733ec6.
> Proxy-Authorization: Digest
> username="daniel",realm="openrcs.com",nonce="UeaDGlHmge5QrNqex8mLThI/UGoO/wyB",uri="sip:micondax at 91.64.193.7:47944;ob",response="8d508c695fb767349115fbe816b50170".
> Content-Length: 601.
> .
> On 7/16/13 6:59 PM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> I looked over the code and should match if no changes to r-uri were done.
>>
>> If convenient for you, send me the logs for ACK with debug=3. I will
>> try to reproduce these days.
>>
>> The ack for 200ok is considered separate from invite transaction
>> (because it can have different path than the invite).
>>
>> Cheers,
>> Daniel
>>
>> On 7/15/13 7:04 PM, Hugh Waite wrote:
>>> 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.
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> Daniel-Constantin Mierla -http://www.asipto.com
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
--
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/20130719/bafd7975/attachment.html>
More information about the sr-dev
mailing list