<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
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.<br>
<br>
Can you try to hanlde the ack with t_check_trans() on that config
path as well, before changing r-uri?<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 7/15/13 10:28 AM, Hugh Waite wrote:<br>
</div>
<blockquote cite="mid:51E3B2AE.90604@crocodile-rcs.com" type="cite">Hi,
<br>
I've attached the signalling trace of this call.
<br>
The ACK does have a Route set, but we think this is correct
according to §17.1.1.3 of RFC3261.
<br>
" 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. "
<br>
<br>
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.
<br>
When the ACK for the 407 arrives, can kamailio detect that the
transaction is in the 'Completed' state and drop it [1]?
<br>
<br>
Hugh
<br>
<br>
[1] RFC 6026 §8.6 which updates RFC3261 §17.2.1
<br>
<br>
<br>
On 12/07/2013 16:22, Daniel-Constantin Mierla wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Cheers,
<br>
Daniel
<br>
<br>
On 7/12/13 5:11 PM, Hugh Waite wrote:
<br>
<blockquote type="cite">Hello,
<br>
I have a question on the use of t_check_trans for in-dialog
requests.
<br>
<br>
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.
<br>
<br>
Should t_check_trans recognise that this transaction was
rejected locally, even though there is an onward route-set?
<br>
<br>
Hugh
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
</pre>
</body>
</html>