[OpenSIPS-Users] Unexpected Dispatcher TLS interaction

[Bogdan-Andrei Iancu]

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: 1388 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20130408/5c47afb8/attachment.bin>