[OpenSIPS-Users] Unexpected Dispatcher TLS interaction
John Quick
john.quick at smartvox.co.uk
Mon Apr 8 16:16:57 CEST 2013
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:bogdan at opensips.org]
Sent: 08 April 2013 13:18
To: john.quick at smartvox.co.uk
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:200800002 at b1.x-onsip.net;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:bogdan at opensips.org]
> Sent: 08 April 2013 11:31
> To: john.quick at smartvox.co.uk; 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
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
More information about the Users
mailing list