17 Jul
2013
17 Jul
'13
12:16 p.m.
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:
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:
--
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 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