[OpenSIPS-Users] Unexpected Dispatcher TLS interaction

Bogdan-Andrei Iancu bogdan at opensips.org
Mon Apr 8 17:43:42 CEST 2013 

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: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
>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sock_selection.patch
Type: text/x-patch
Size: 1618 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20130408/1baeaabd/attachment.bin>

More information about the Users mailing list