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
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.