[Home]

Summary:ASTERISK-19352: SIP warning message if only UDP is eanbled
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2012-02-13 15:04:19.000-0600Date Closed:2012-02-28 12:16:42.000-0600
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.9.2 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Attachments:( 0) asterisk-19352-transport-warning-message-v1.patch
( 1) issueA19352_no_transport_is_udp.patch
Description:If only udp is enabled in configuration:
{code}
udpbindaddr=0.0.0.0
tcpenable=no                    
tcpbindaddr=0.0.0.0            
tlsenable=no                  
tlsbindaddr=0.0.0.0  
{code}

while loading chan_sip there is a warning message:
{code}No valid transports available, falling back to 'udp'{code}
Comments:By: Sean Darcy (seandarcy) 2012-02-13 17:55:05.270-0600

I'm also getting this on 10.2.0-rc2, but I have tcpenable=yes. I only have transport=tcp on one of the sip devices (this was because some of our employees have udp over port 5060 blocked). The others have no transport specified.

I'd assumed this was simply saying that if no transport was specified, it would default to udp. Is this just a matter of better wording of the warning? For instance "No transport specified, using default 'udp'".

Or is this a real issue?

sip reload
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf':   == Found
 ..........
[Feb 13 18:41:39] WARNING[15670]: chan_sip.c:29554 reload_config: No valid transports available, falling back to 'udp'.


sip.conf:
[general]
....
tcpenable=yes
tcpbindaddr=0.0.0.0
bindaddr=0.0.0.0
......

[office-going-to-home]     ;  places calls
type=peer ;; we only call out
transport=tcp
By: Michael L. Young (elguero) 2012-02-13 22:51:59.306-0600

Try adding transport=udp to the [general] context.  I think that will take away the error message.

In Sean's case, try adding transport=udp,tcp to the [general] context or vice versa if you prefer tcp first then udp.

I think this is probably a setting that needs to be added to the sample config.
By: Walter Doekes (wdoekes) 2012-02-14 02:05:19.856-0600

Unfortunately, the options transport= and tcpenable= have some overlap indeed.

I might have caused this warning when fixing ASTERISK-18837 where the user did the opposite from Sean: transport=tcp without tcpenable=yes.

Fixing the sample config sounds right.
By: Maciej Krajewski (jamicque) 2012-02-14 03:32:14.880-0600

I confirm - adding transport=udp fix the problem.
By: Michael L. Young (elguero) 2012-02-14 08:48:41.128-0600

I am looking into this a bit further.  

Here are my additional thoughts:
1.  We need to add the default configuration "transport=udp" to the [general] context in the sample config

2.  We need to adjust the warning message to clarify that the default transports have not been configured (in the case where someone doesn't have "transport=" in their sip.conf file)

   or

   We need to set the default transport to UDP and later on in the code set this to what is in the user's sip.conf file like we do for many other settings found in the [general] context.  This would be the behavior I would expect rather than a message being displayed to the user.

Thoughts?
By: Michael L. Young (elguero) 2012-02-14 18:09:23.792-0600

After messing around with this, it seems simpler to just adjust the messages displayed and add the transport setting to the sample config.

I think if the message is changed from a WARNING to a NOTICE, it will help prevent the user from being alarmed and thinking there is a serious problem or that there is something broken.  If a user adds the transport setting to the [general] context, they should never see this message.
By: Walter Doekes (wdoekes) 2012-02-15 01:58:50.006-0600

Personally, I prefer your option B: issueA19352_no_transport_is_udp.patch (untested, but should work).

Note that it changes undocumented transport= behaviour:

previously:
* transport=tcp
* transport=udp

would be equivalent to:
* transport=tcp,udp

after the patch, it would be:
* transport=udp

And this would be expected behaviour: insecure=port plus insecure=invite yields only insecure=invite and not a combination of the two.

Thinking out loud here:
But... for consistency's sake, the "!ast_strlen_zero(v->value)" check in the if() would have to go too. Making transport= equivalent to transport=udp. And then, the same would have to be done for the "transport" checks in build_peer. (This doesn't pose a problem for realtime NULL/(empty) columns: the defaults get set below if peer->transport==0, which is expected behaviour.)
By: Sean Darcy (seandarcy) 2012-02-15 18:57:53.193-0600

This issue comes up for me at least when some sip devices are using tcp, while others use udp. As it stands, udp is the default, so transport= only has to be put in those devices that use tcp.

So:

1. why do we need tcpenable at all in [general]? If a device has transport=tcp, why isn't that enough to enable tcp? And same for udp.

2. transport= would only be for a device. [general] could have transportdefault= , which would itself default to udp.

I think this would be backwards compatible, just now tcpenable would be a noop.
By: Michael L. Young (elguero) 2012-02-16 09:43:00.478-0600

Sean, maybe this will help clarify what is being done currently and what the proposed patch by Walter does.  Hopefully I am correct.  If not, please correct me :)

From my understanding of the current code:

1.  transport= in the [general] context sets the allowed transports that can be used by all devices (TCP, UDP, TLS).  This would be the default setting you see when you run "sip show settings".
2.  The order of the transports, sets the primary default outgoing transport.  transport=tcp,udp would make TCP the primary transport used for all devices.  That is actually a good thing, IMO, since you can effect a system wide change easily.
3.  When you add transport= to a device context, it overrides the default settings.  So say in [general] you had transport=udp,tcp and then under the device you have transport=tcp, the allowed transport for the device is TCP, the primary outgoing transport is TCP and all other devices are set to allow UDP,TCP with UDP being the primary outgoing transport.

This is how I understand the current behavior.

What is causing the warning message is that right now, it falls back to UDP.  So, it is setting UDP as the default after the fact, once it determines that no transports have been set and displaying the warning about it, instead of setting it as default from the very beginning.

What Walter's proposed patch does is:
1.  The default allowed transport will always be set to UDP and then it is overridden by what is in [general] if there is anything set.  This eliminates the WARNING message we are seeing.  It would be impossible, unless someone changed the code, to not have at least one transport (UDP) set.
2.  You cannot set in [general] transport=tcp and on another line transport=udp expecting the result to be tcp,udp.  It will have to be all on one line (transport=tcp,udp).  Otherwise, the last instance of transport will override the first instance of it.  This goes the same for the device context as well.

Walter's patch actually goes the route that I was thinking and playing with myself.  The behavior change is what made me opt for the first route in my proposed patch.  Overall, I think Walter's patch is the way to go.  With this not really being documented, it could probably make its way into 1.8, 10 and trunk.  That will have to be judgment call because we do not want to mess up people's systems which have their settings with transports= on separate lines.  I personally don't see where too many people would have done that since what is documented for the device sections always shows transport=tcp,udp all on one line.

Oh and the comment about tcpenable being a noop.  That is incorrect, tcpenable needs to be set to yes in order to use TCP.  If tcpenable is not set to yes, then when you set transport=tcp, it will ignore that setting, display a warning message about it and keep UDP as the transport.

One last thing, I would still add to sip.conf.sample the transport line under the [general] context so that it is clear that this setting can be changed globally as well as per device.  I would maybe even clarify the message so that if someone inadvertently changes the code affecting this setting, it helps to track down what the warning message is about.