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
