[asterisk-dev] [Code Review] No valid transports available, falling back to 'udp'

[sean darcy]

On 02/15/2012 03:45 PM, wdoekes wrote:
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1745/
>
>
>>  However, somebody somewhere probably relies on current behaviour.. or?
>
> Since I already caused enough regressions on this one issue, I should probably suggest this:
>
> - tone down the warning in 1.8 and 10 and update the sip.conf.sample
> - implement this in trunk and note the changed behaviour of transport= in the changes doc
>
>
> - wdoekes
>
>
> On February 15th, 2012, 2:35 p.m., wdoekes wrote:
>
> Review request for Asterisk Developers.
> By wdoekes.
>
> /Updated Feb. 15, 2012, 2:35 p.m./
>
>
>   Description
>
> In r347727 I introduced an extra warning for anyone who doesn't have any transport= set. This causes confusion, especially since that setting isn't in [general] in the sip.conf.sample.
>
> I could tone down the warning, but I'd rather fix it like this: only complain if transports= was supplied and ended up empty (because of invalid transports).
>
> However, I'd like to change the behaviour of the transport= option for that.
>
> Previously:
>    transport=udp
>    transport=tcp
> meant:
>    transport=udp,tcp
>
> Which is odd, since other options don't behave like that (apart from allow/deny/permit/disallow). insecure=port and insecure=invite means insecure=invite and not the combination of the two.
>
> After this patch, it means:
>    transport=tcp
>
> However, somebody somewhere probably relies on current behaviour.. or?
>
>
>   Testing
>
> Tested that only the last transport= setting for [general] and for peers is used and that the warning is gone if no transport= is supplied in [general]. I didn't run the test-suite (yet).
>
> *Bugs: * ASTERISK-19352
> <https://issues.asterisk.org/jira/browse/ASTERISK-19352>
>
>
>   Diffs
>
>   * /branches/1.8/channels/chan_sip.c (355531)
>
> View Diff <https://reviewboard.asterisk.org/r/1745/diff/>
>

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 I only 
put transport= in those devices that use tcp.

So:

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

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

I think this would be backwards compatible, just now tcpenable and 
transport= in [general] would be a noops. If transport= wasn't 
specified, it would default to udp (unless the default were changed).

sean