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

[Kevin P. Fleming]

On 02/15/2012 07:08 PM, sean darcy wrote:
> 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?

A one word answer: Realtime :-)

> 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).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org