[sr-dev] t_check_trans with in-dialog requests
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jul 17 14:16:38 CEST 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20130717/a049cbe9/attachment-0001.html>
More information about the sr-dev
mailing list