[asterisk-dev] SIP TCP/TLS, release policy and more (personal opinions included)

[BJ Weschke]

 Response interspersed for you below as well.

Grey Man wrote:
> This whole episode is the old classic example of throwing some code
> out there and getting users to do the testing, a phenomena that is
> definitely not unique to Asterisk. Generally programmers love
> programming and hate testing (why test when you could be programming).
> From what Olle is saying - and I havent tested it myself - the SIP TCP
> implementation in Asterisk is broken enough so that most people are
> going to have difficulties with it. If that is the case shouldn't it
> be moved out to a branch and fixed before releasing it?
>
>   
 This is water under the bridge at this point with this particular 
issue. One side has their opinion, another side has theirs. What's 
important going forward is that the community as a whole participates in 
process / policy discussions and decisions so that we don't get to this 
point again and end up where we are now.

> It seems a bit like "experimental feature" here is "half done new
> feature". Asterisk has always changed at a rate of knots and us users
> are used to treating new releases and features as "experimental".
> Knowing that a new feature is broken at best will be fine for those of
> us that keep an eye on things and know to avoid it but will be really
> painful for new users trying to get up and running with broken
> implementations. Those users that do want to "experiment" can checkout
> the branch.
>
>   
 And that's why sip.conf.sample has the following:

tcpenable=no                    ; Enable server for incoming TCP 
connections (default is no)

> As to the fact that having a broken SIP TCP channel is ok becuase the
> UDP one is alright it is worth considering that some user agents, such
> as the xten softphones, will use TCP as first preference over UDP. So
> if an Asteirsk 1.6 user who is only just learning SIP activates the
> TCP channel they'll have problems which is not good for the community.
>
>   
 As noted above, your scenario presented here isn't valid because, by 
default, it is disabled. Based on the latest SIPit findings, it may 
warrant some further dialog/changes in the sample file to the extent of 
"default is no and this feature is still experimental at this time", but 
I think it's not likely that someone "just learning SIP" is going to 
pour over this config with a fine toothed comb when they can just locate 
the "xlite1" peer sample listed in the sample config file, make some 
brief changes and be off an running with the default UDP transport.

> The other underlying issue here is that adding TCP to the Asterisk SIP
> channel should not have been this big a deal in the first place. The
> fact that is is stems from the way the SIP channel has been
> implemented and that the whole 20,000+ (last time I checked) lines of
> code have to be gone through to see where modifications are required.
> I have seen a SIP stack implementation where going from UDP to TCP
> meant adding a transport class of 400 lines and a small number of
> adjustments in the Via headers and URI handling, all up probably a
> couple of days work.
>
>   
 You're digressing into troll bait here. Did this stack implementation you've cited already include a fully state aware session transaction manager? I would hope that it did for your minimal amount of work required to be adequate such that an implementation passes muster at an event like SIPit. 
 The fact of the matter is that chan_sip is what it is and has been and remains to be fully functional for many hundreds of thousands of Asterisk installations it exists today. It's now time for healthy discussion and productive work towards making further improvements on it in the future.
 
--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/