[OpenSIPS-Users] ACK not relaying - no NAT problem

[samuel]

Hi folks,

I've seeing a weird issue with an opensips 1.7.1 installation and the
standard configuration. I can provide more information if required but it
looks like the ACK is absorved without being relayed. This ACK is the 3-rd
handshake of the session initiation, not an acknowledge. The INVITE-180
Ringing-200 OK is sent between endpoints (blink 0.2.8 and sylkerver 1.3.0)
but when the sylkservers send the ACK to Blink, the SIP proxy, it does not
forward it:


T IP.adress.of.Blink:47793 -> IP.adress.of.Opensips:5060 [AP]
  ACK sip:666159753 at IP.adress.of.Sylkserver:5060
  SIP/2.0..Via: SIP/2.0/tcp
IP.adress.of.Blink:47793;rport;branch=z9hG4bKPj7YGMzdPHc9T.PIoWqBj6f21w50CkGByH
  Max-Forwards: 70
  From: "Samuel" <sip:sam at test.domain.org
>;tag=CRRPKM1rHO8cSe8vkBJNL93KupfjkiwC
  To: <sip:666159753 at test.domain.org>;tag=tnoBz19pYIcw9QmTB90CP3hC6g7Mdayk
  Call-ID: -SAKz4FlDSJ0rjEks.EUC5LTOlsttkFa
  CSeq: 19923 ACK
  Route: <sip:IP.adress.of.Opensips;transport=tcp;lr;r2=on;did=cd4.66e94036>
  Route: <sip:IP.adress.of.Opensips;lr;r2=on;did=cd4.66e94036>
  User-Agent: Blink 0.2.8 (Linux)
  Content-Length:  0

Opensips' logs contain the following lines:

Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_msg:
method:  <ACK>
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_msg:
uri:     <sip:666159753 at IP.adress.of.Sylkserver:5060>
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_msg:
version: <SIP/2.0>
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: flags=2
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_via_param: found param type 235, <rport> = <n/a>; state=6
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_via_param: found param type 232, <branch> =
<z9hG4bKPj7YGMzdPHc9T.PIoWqBj6f21w50CkGByH>; state=16
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]: DBG:core:parse_via:
end of header reached, state=5
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: via found, flags=2
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: this is the first via
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:receive_msg: After parse_msg...
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:receive_msg: preparing to run routing scripts...
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:sl:sl_filter_ACK: to late to be a local ACK!
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:parse_headers: flags=100
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:maxfwd:is_maxfwd_present: value = 70
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:destroy_avp_list: destroying list (nil)
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21833]:
DBG:core:receive_msg: cleaning up
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
DBG:tm:cleanup_uac_timers: RETR/FR timers reset
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]: DBG:tm:t_unref:
UNREF_UNSAFE: [0x7f173201f8d8] after is 0
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
DBG:core:destroy_avp_list: destroying list (nil)
Jan  3 13:41:23 osip2 /usr/local/sbin/opensips[21830]:
DBG:core:receive_msg: cleaning up

It looks like the ACK is not even passed to route(0) because I do not see
anything from the config line appeared and no matter which log I setup in
the start, its not rendered in the logs.

I'm using dialog module with db_mode 1 to trace dialogs in database, so the
ACK might trigger a hook in this module.
I'm also using mediaproxy with dialog built-in hooks, engage_mediaproxy()
        # account only INVITEs
        if (is_method("INVITE")) {
                setflag(1); # do accounting

                #modifications
                create_dialog("PpB");
                $dlg_val(caller) = $fu;
                $dlg_val(callee) = $ru;

                engage_media_proxy();

        }

Does anyone see any issue with the ACK or any hint to look into the
configuration file so I can trace why the ACK is not sent?

Thank you very much in advance and apologies for the longitude,

Samuel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120103/f2a19a72/attachment-0001.htm>