Hi Brian, the t_relay() function does server location discovery via DNS (for domain voip.host.tld ).
Based on NAPTR and SRV records, a TLS destination is chosen (this selection also depends on the RURI - like if a specific SIP schema is required, etc). So, your problem is why TLS was chosen or why TLS write failed ? Regards, Bogdan [email protected] wrote: > Hello list, > > PROBLEM > ------- > > Registrations work well, but when sending IVITEs I see this in log: > > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: DBG:core:mk_proxy: > doing DNS lookup... > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: > DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup! > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: > DBG:core:filter_and_sort_naptr: skipping SIP+D2U -> _sip._udp.voip.host.tld > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: > DBG:core:filter_and_sort_naptr: found valid SIPS+D2T -> > _sips._tcp.voip.host.tld > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: > DBG:core:filter_and_sort_naptr: skipping SIP+D2T -> _sip._tcp.voip.host.tld > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: > DBG:core:do_srv_lookup: SRV(_sips._tcp.voip.host.tld) = voip.host.tld:5061 > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: > DBG:core:sip_resolvehost: valid SRV found! > [...] > Dec 10 15:55:18 name.host.tld <debug> opensips[10850]: DBG:core:send2child: > to tcp child 0 0(10848), ceba0508 > Dec 10 15:55:18 name.host.tld <debug> opensips[10850]: > DBG:core:handle_ser_child: read response= ceb903f0, 2, fd 21 from 6 (10848) > Dec 10 15:55:18 name.host.tld <debug> opensips[10850]: > DBG:core:tcpconn_add: hashes: 405, 3 > Dec 10 15:55:18 name.host.tld <debug> opensips[10850]: > DBG:core:io_watch_add: io_watch_add(82d10c0, 21, 2, ceb903f0), fd_no=10 > Dec 10 15:55:18 name.host.tld <error> opensips[10848]: > ERROR:core:tls_blocking_write: too many retries with no operation > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: DBG:core:tcp_send: > after write: c= ceb903f0 n=-1 fd=18 > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: DBG:core:tcp_send: > buf= > INVITE sips:[email protected] SIP/2.0^M > Record-Route: <sip:211.123.22.12:5061;transport=tls;lr=on;ftag=grophp7yc3>^M > Via: SIP/2.0/TLS 211.123.22.12:5061;branch=z9hG4bK4d6.913.0;i=2^M > Via: SIP/2.0/TLS > 192.168.1.12:3352;received=125.81.6.152;branch=z9hG4bK-pt7eil3u8qci;rport=3352^M > [...] > Content-Type: application/sdp^M > ^...@dec 10 15:55:18 name.host.tld <error> opensips[10848]: > ERROR:core:tcp_send: failed to send > Dec 10 15:55:18 name.host.tld <error> opensips[10848]: ERROR:tm:msg_send: > tcp_send failed > Dec 10 15:55:18 name.host.tld <debug> opensips[10850]: > DBG:core:handle_ser_child: read response= ceb903f0, -2, fd -1 from 6 (10848) > Dec 10 15:55:18 name.host.tld <error> opensips[10848]: > ERROR:tm:t_forward_nonack: sending request failed > Dec 10 15:55:18 name.host.tld <debug> opensips[10850]: > DBG:core:io_watch_del: io_watch_del (82d10c0, 21, -1, 0x10) fd_no=11 called > Dec 10 15:55:18 name.host.tld <debug> opensips[10848]: DBG:tm:t_relay_to: > t_forward_nonack returned error > > The forward (I assume by t_relay()) is failing. Is it because a SRV > lookup is being done and finding that raw SIP over TCP is being sent > to the OpenSIPS TLS listener? Should I be using something other than > t_relay() in the config? > > The same config worked well with OpenSER 1.3.X. Only when migrating > to 1.6.0 do we see these errors. What could have changed? > > Thanks, > Brian > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
