Hello,
We found out the problem, it was out fault. The ACK was dropped because the
was a previous (and incorrect) evaluation of $rU. Being $null for these
calls, the ACK wasn't relayed. We already fixed it; thanks for the
assistance.
Regards,
David.
2012/7/30 Daniel-Constantin Mierla
> Hello,
Hello,
It looks like the r-uri in the trace is different from the one kamailio
considers. From the ACK message captured with ngrep:
ACK sip:200.87.137.150:5060;user=phone SIP/2.0
But form the logs:
Jul 30 09:15:00 theseus-test /usr/local/kamailio/sbin/kamailio[1577]:
DEBUG: [parser/msg_parser.c:
Hello,
the log message shows that the transaction is not found. Is the ACK
coming late after 200ok ? There is a tm module parameter that you can
adjust to prolong the time a transaction is kept after completion, if
that is the case.
Also, be sure the INVITE is sent using tm functions, not st
This is the code that's being executed:
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
xlog("ESTAMOS EN WITHIN\n");
if (loose_route()){
xlog("LOOSE ROUTE DETECTED\n");
Hello,
if your config is based on the default one, there is a check for
associated INVITE transaction and if that does not exist, then the ACK
is droppend.
You can use debugger module with cfgtrace set on in order to see what
actions in the config file are executed. That will help to see if
Hi Daniel,
This is the ACK message:
U 2012/07/30 04:23:31.604721 79.170.68.151:5060 -> 79.170.68.157:5060
ACK sip:200.87.137.150:5060;user=phone SIP/2.0.
Via: SIP/2.0/UDP 79.170.68.151:5060
;branch=z9hG4bK334faa4497ll114a52eACK450932302031.
Max-Forwards: 70.
Route: .
To: ;tag=ldb0cbn6-CC-23.
From
Hello,
can you add a log message to print the source ip, call id and r-uri?
It may happen that the ACK is looping back if r-uri is pointing to itself.
Also, try to get the ngrep on all devices, like:
ngrep -d any -qt -W byline port 5060
Pasting the ACK request here will help to see if somethi
In a UAC-Kamailio-UAS scenario, we've found a case where the ACK coming
from uac is not relayed by our proxy to the uas. This is the log for the
ACK message:
Jul 27 10:04:59 theseus-test /usr/local/kamailio/sbin/kamailio[17358]:
DEBUG: [parser/msg_parser.c:624]: SIP Request:
Jul 27 10:04
