Hello John,
Thanks for the info - found the problem. Revert the prev patch and apply
this one (which also contains the patch). Please have it tested.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04/08/2013 05:16 PM, John Quick wrote:
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
Index: forward.c
===================================================================
--- forward.c (revision 9936)
+++ forward.c (working copy)
@@ -271,6 +271,7 @@
break;
#endif /* USE_SCTP */
case PROTO_UDP:
+ LM_ERR("current binding is %p, proto %d\n",bind_address, bind_address->proto);
if ((bind_address==0)||(to->s.sa_family!=bind_address->address.af)||
(bind_address->proto!=PROTO_UDP)){
switch(to->s.sa_family){
@@ -283,7 +284,9 @@
default: LM_ERR("don't know how to forward to af %d\n",
to->s.sa_family);
}
- }else send_sock = msg ? msg->rcv.bind_address : bind_address;
+ LM_ERR("default UDP selected\n");
+ }else send_sock = (msg && msg->rcv.bind_address->address.af==bind_address->address.af &&
+ msg->rcv.bind_address->proto==bind_address->proto)? msg->rcv.bind_address : bind_address;
break;
default:
LM_CRIT("unknown proto %d\n", proto);
Index: forward.h
===================================================================
--- forward.h (revision 9936)
+++ forward.h (working copy)
@@ -92,12 +92,15 @@
union sockaddr_union* to, int id,
char* buf, int len)
{
+ LM_ERR("received socket is %p, proto %d, required proto is %d\n",
+ send_sock,send_sock?send_sock->proto:PROTO_NONE,proto);
if (send_sock==0)
send_sock=get_send_socket(0, to, proto);
if (send_sock==0){
LM_ERR("no sending socket found for proto %d\n", proto);
goto error;
}
+ LM_ERR("selected socket is %p, proto %d\n",send_sock,send_sock?send_sock->proto:PROTO_NONE);
if (proto==PROTO_UDP){
if (udp_send(send_sock, buf, len, to)==-1){
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
