Hi Bogdan, Here is the extra output with your patch: 2013-04-08 15:13:41 INFO:core:probe_max_sock_buff: using snd buffer of 255 kb 2013-04-08 15:13:41 INFO:core:init_sock_keepalive: -- TCP keepalive enabled on socket 2013-04-08 15:13:41 INFO:core:tls_accept: New TLS connection from 81.104.44.9:2105 accepted 2013-04-08 15:13:41 INFO:core:tls_accept: Client did not present a TLS certificate 2013-04-08 15:13:41 INFO:core:tls_dump_cert_info: tls_accept: local TLS server certificate subject: /C=GB/ST=Hertfordshire/O=Smartvox Limited/..... 2013-04-08 15:13:41 ERROR:sl:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 3 2013-04-08 15:13:41 ERROR:sl:msg_send: selected socket is 0x7f5b485c3228, proto 3 2013-04-08 15:13:41 ERROR:sl:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 3 2013-04-08 15:13:41 ERROR:sl:msg_send: selected socket is 0x7f5b485c3228, proto 3 2013-04-08 15:13:45 ERROR:sl:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 3 2013-04-08 15:13:45 ERROR:sl:msg_send: selected socket is 0x7f5b485c3228, proto 3 2013-04-08 15:13:45 ERROR:tm:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 3 2013-04-08 15:13:45 ERROR:tm:msg_send: selected socket is 0x7f5b485c3228, proto 3 2013-04-08 15:13:46 ERROR:core:get_send_socket: current binding is 0x7f5b485c3228, proto 3 2013-04-08 15:13:46 ERROR:core:get_send_socket: default UDP selected 2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is 0x7f5b485c33f0, proto 1, required proto is 1 2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is 0x7f5b485c33f0, proto 1 2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is 0x7f5b485c33f0, proto 1, required proto is 1 2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is 0x7f5b485c33f0, proto 1 2013-04-08 15:13:46 ERROR:core:get_send_socket: current binding is 0x7f5b485c33f0, proto 1 2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 1 2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is 0x7f5b485c3228, proto 3 2013-04-08 15:13:46 ERROR:core:udp_send: sendto(sock,0x7f5b350454d0,1261,0,0x7f5b350418b8,16): Broken pipe(32) 2013-04-08 15:13:46 ERROR:tm:msg_send: udp_send failed 2013-04-08 15:13:46 ERROR:tm:t_forward_nonack: sending request failed 2013-04-08 15:13:46 ERROR:tm:w_t_relay: t_forward_nonack failed 2013-04-08 15:13:46 ERROR:sl:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 3 2013-04-08 15:13:46 ERROR:sl:msg_send: selected socket is 0x7f5b485c3228, proto 3 2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is 0x7f5b485c3228, proto 3, required proto is 3 2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is 0x7f5b485c3228, proto 3
John -----Original Message----- From: Bogdan-Andrei Iancu [mailto:[email protected]] Sent: 08 April 2013 13:18 To: [email protected] Cc: 'OpenSIPS users mailling list' Subject: Re: [OpenSIPS-Users] Unexpected Dispatcher TLS interaction Hi John, So, UDP is still tried - I see the "udp_send" is calls after the failover. I suspect that somehow the outgoing socket is wrongly selected, as "Broken pipe" cannot be generated on UDP. To check what kind of interface is selected by msg_send() , I made here a small patch to print some stuff - if you could apply it and get the logs it will be really helpful. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/08/2013 02:00 PM, John Quick wrote: > Hi Bogda, > > Here is the log output you requested: > 2013-04-08 11:52:31 Failure_Route: Trying next dispatcher target. > ru=sip:[email protected];user=phone du=<null> > 2013-04-08 11:52:31 t_relay failed > > 2013-04-08 11:52:31 ERROR:core:udp_send: > sendto(sock,0x7f51a476c110,1261,0,0x7f51a47534a8,16): Broken pipe(32) > 2013-04-08 11:52:31 ERROR:tm:msg_send: udp_send failed > 2013-04-08 11:52:31 ERROR:tm:t_forward_nonack: sending request failed > 2013-04-08 11:52:31 ERROR:tm:w_t_relay: t_forward_nonack failed > > John > > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:[email protected]] > Sent: 08 April 2013 11:31 > To: [email protected]; OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] Unexpected Dispatcher TLS interaction > > Hello John, > > By default, the protocol selection (for outbound part) is done based > on RURI > - as the call comes via TLS, I expect to have a "transport=TLS" in > RURI, param which will be preserved after doing dispatcher (dispatcher > changes domain and port part). So, I guess, opensips is trying to set > the call out via TLS (after dispatcher). > > Could you: > 1) print $ru and $du after dispatcher (before t_relay) > 2) post here the err logs from t_relay > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > On 04/08/2013 11:43 AM, John Quick wrote: >> I have been running some tests using the Dispatcher module on v1.9 of >> OpenSIPS and found an unexpected interaction with the transport >> protocol of the received INVITE request. When the INVITE request is >> received over UDP, Dispatcher works fine for all destinations in the >> set, but when the INVITE is received over TLS only the first >> Dispatcher destination works. The second and subsequent destinations > (after calls to ds_next_domain) all fail. i.e. >> in this code, t_relay() returns false: >> ds_next_domain("1", "0"); >> if (!t_relay()) { >> xlog("L_WARN", " t_relay failed"); >> sl_reply_error(); >> } >> >> I suspect this is a problem with transport protocol selection for the >> onward request because the following alternative code works: >> ds_next_domain("1", "0"); >> force_send_socket(udp:<interface-address>); >> if (!t_relay()) { >> xlog("L_WARN", " t_relay failed"); >> sl_reply_error(); >> } >> >> The problem also happens for the first destination in a new >> destination set (e.g. using ds_select_domain("2", "0")), after >> exhausting all members of set 1. >> >> I would expect Dispatcher to use the same transport for the first and >> all subsequent destinations, but it actually looks like it is using >> UDP for the first and then using the transport of the received >> request for subsequent destinations. Can the transport be specified >> in the destination field of the dispatcher table? For example, could >> this field be set to "sip:<destination-ip>;transport=udp" ? >> >> John Quick >> Smartvox Limited >> Web: www.smartvox.co.uk >> >> >> >> >> _______________________________________________ >> 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
