19 Jul
2013
19 Jul
'13
6:30 a.m.
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@91.64.193.7:47944;ob SIP/2.0.
CSeq: 1 INVITE.
From: <sip:daniel@openrcs.com>;tag=eec0288f.
To: <sip:micondax@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@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@openrcs.com>;tag=eec0288f.
To: <sip:micondax@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@91.64.193.7:47944;ob SIP/2.0.
Call-ID: WrJ6SbNtgM51yqPAEr9BChJhbgFzbZHw.
Max-Forwards: 70.
From: <sip:daniel@openrcs.com>;tag=eec0288f.
To: <sip:micondax@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@91.64.193.7:47944;ob SIP/2.0.
CSeq: 2 INVITE.
From: <sip:daniel@openrcs.com>;tag=eec0288f.
To: <sip:micondax@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@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@91.64.193.7:47944;ob",response="8d508c695fb767349115fbe816b50170".
Content-Length: 601.
.
On 7/16/13 6:59 PM, Daniel-Constantin Mierla wrote:
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
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:
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda 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:
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda 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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev