<div dir="ltr">I enabled debug level 6 and I am noticing this <div>

<span style="font-stretch:normal;color:rgb(202,251,66);font-family:&#39;Helvetica Neue&#39;;font-size:14px;background-color:rgb(0,0,0)">: DBG:core:mk_proxy: doing DNS lookup...<br>Aug 14 20:42:09 cloud-server-06 /sbin/opensips[22814]: DBG:core:sip_resolvehost: no port, no proto -&gt; do NAPTR lookup!</span><br></div><div><span style="font-stretch:normal;color:rgb(202,251,66);font-family:&#39;Helvetica Neue&#39;;font-size:14px;background-color:rgb(0,0,0)"><br></span></div><div>Here it claims that this request is lacking a port and and a proto on this branch I am appending the branch like so </div><div><br></div><div>







<p class="p1"><span class="s1">                                        avp_pushto(&quot;$du&quot;,&quot;sip:sisterproxyIP&quot;);</span></p><p class="p1"><span class="s1">                                    </span></p><p class="p1"><span class="s1">







</span></p><p class="p1"><span class="s1">                                        append_branch();</span></p><p class="p1"><br></p><p class="p1">the sister proxy is where the user resides. This is actually confusing the remote opensips  proxy(same version) because now it sends all in dialog request via a tcp socket all thought the 200 was sent via udp leg. 2 requests came into the sister proxy. I&#39;m not sure why the one gets a 404 and the proceeds the only difference is the udp request has two rr headers. It appears that the remote proxy might not have cancelled the dialog even thought it sent a negative reply. I have a trace of this if needs to be supplied.</p><p class="p1"><br></p><p class="p1">Thanks,</p><p class="p1">Tito</p><p class="p1"><br></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 3:52 PM, Tito Cumpen <span dir="ltr">&lt;<a href="mailto:tito@xsvoce.com" target="_blank">tito@xsvoce.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Group,<div><br></div><div><br></div><div>I am using :</div><div>







<p><span>version: opensips 2.2-dev (x86_64/linux)</span></p>
<p><span>flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT</span></p>
<p><span>ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535</span></p>
<p><span>poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.</span></p>
<p><span>git revision: b7db080</span></p>
<p><span>main.c compiled on 22:43:41 Jun 25 2015 with gcc 4.8.3</span></p><p><span><br></span></p><p><span><br></span></p><p><span>I have a strange issue in which dns SRV lookups and routing is happening although I have set the RURI domain as an alias in my config. On some calls this will  eventually screw up the dialog termination once a bye is sent because it makes an attempt to transmit the bye to this SRV entry.</span></p><p><span>I see this error in the logs.</span></p>

<div style="font-family:&#39;Helvetica Neue&#39;;font-size:14px"><span style="background-color:rgb(0,0,0)"><span style="font-size:12px"><span style="font-family:&#39;Andale Mono&#39;"><span style="color:rgb(202,251,66)">Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 47<br>Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]: ERROR:core:tcpconn_async_connect: poll error: flags 1c<br>Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]: ERROR:core:tcpconn_async_connect: failed to retrieve SO_ERROR [server=192.XX.XX.XX:38798] (111) Connection refused<br>Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]: ERROR:core:proto_tcp_send: async TCP connect failed<br>Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]: ERROR:tm:msg_send: send() for proto 2 failed</span></span></span></span></div><p><span><span style="color:rgb(202,251,66);font-family:&#39;Andale Mono&#39;;font-size:12px;background-color:rgb(0,0,0)">Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]: ERROR:tm:t_forward_nonack: sending request failed</span> </span></p><p><span><br></span></p><p><span><br></span></p></div></div>
</blockquote></div><br></div>