Hi Tito,
Yes, your SIP URI does not have any protocol or port indication, so
NAPTR lookup is perform.
Now, of the call flow you describe : DNS based discovery is to be done
for initial request only - the sequential requests (in dialog) should
simply follow the path discovered by the initial request. So, better
post somewhere the pcap or so.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 15.08.2015 00:41, Tito Cumpen wrote:
I enabled debug level 6 and I am noticing this
: DBG:core:mk_proxy: doing DNS lookup...
Aug 14 20:42:09 cloud-server-06 /sbin/opensips[22814]:
DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
Here it claims that this request is lacking a port and and a proto on
this branch I am appending the branch like so
avp_pushto("$du","sip:sisterproxyIP");
append_branch();
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'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.
Thanks,
Tito
On Fri, Aug 14, 2015 at 3:52 PM, Tito Cumpen <[email protected]
<mailto:[email protected]>> wrote:
Group,
I am using :
version: opensips 2.2-dev (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
git revision: b7db080
main.c compiled on 22:43:41 Jun 25 2015 with gcc 4.8.3
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.
I see this error in the logs.
Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 47
Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
ERROR:core:tcpconn_async_connect: poll error: flags 1c
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
Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
ERROR:core:proto_tcp_send: async TCP connect failed
Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
ERROR:tm:msg_send: send() for proto 2 failed
Aug 14 18:36:25 cloud-server-06 /sbin/opensips[15805]:
ERROR:tm:t_forward_nonack: sending request failed
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
