[OpenSIPS-Users] Unexpected Dispatcher TLS interaction

[John Quick]

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
>