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

[Johansson Olle E]

(Please note that this mail contains a lot of personal opinions and is  
strongly coloured by the treatment I have got while trying to indicate  
how broken chan_sip is in 1.6.0)

Friends,

We do have a broken SIP channel in 1.6.0. UDP still works mostly as  
before, but the code for TCP/TLS support is just not going to work  
without a large amount of work. This was very clear at SIPit.

Because of the new release policy, there won't be any fixes to TCP/TLS  
in 1.6.0. As 1.6.1 is a release candidate now, I don't expect it to be  
fixed in 1.6.1 either. 1.6.1 also contains some very large changes to  
the chan_sip driver by me and Steve Murphy, changes that will require  
heavy testing. Provided that we can allocate development resources,  
SIP/TCP will be fixed in 1.6.2.

In other words: Because of the new release policy, we won't see a  
stable SIP channel with TCP/TLS in the 1.6 generation for quite some  
time, since coming releases will contain other large changes in  
addition to the TCP/TLS code.

For SIP, 1.6.0 is a sad release. We will have to continue tests to  
make sure it at least has the same base-level of functionality for UDP  
as the 1.4 series.

Personally, I would like to see the project reverting the decision to  
fork into 1.6.1, test the 1.6.1 chan_sip with my kill-the-user and  
Steve's hash tables much, much more and fix a lot of issues with TCP.  
After we've done this, it's time to fork into 1.6.1. As 1.6.1 contains  
a lot of additions to other modules that hopefully is ready for  
release and with the current maintainer defending the TCP/TLS work, I  
don't expect this to happen.

SIP/TLS will require a lot of work both in the core and in the SIP  
channel driver, so that will have to wait. It's also based on TCP,  
meaning that  it's a natural first step to fix TCP first and restart  
the work on the TLS implementation later after we've made some  
architectural decisions about secure calls and the core PBX.

I understand that this proposal breaks the new release policy.  
Personally, I want to be proud over our work. Obviously the persons  
committing the TCP/TLS addition doesn't care or doesn't understand and  
did not listen to my objections, before or after the commit. Accepting  
this addition and defending it was a bad mistake by the current  
maintainer of Asterisk. I would like the project (whatever that is) to  
review how a maintainer is selected, and if the community should have  
any right to take part of this decision. I personally think that while  
Russell is an excellent coder with great insights into Asterisk, he's  
not ready to handle the community leadership or management of the  
releases by his own, somehting that was clearly proven by the chan_sip  
changes and the way he's been defending these. In order to get Digium  
to understand how serious the chan_sip issues was for Asterisk, I had  
to write to the CEO and the founder. That should not be needed.

In order to fix that mistake, I think we have to relax and review the  
policys and focus on delivering good and working code. We also  
propably need to integrate large new additions and changes in a  
managed test-this-branch branch for testing before committing to  
trunk, since trunk so quickly moves to release. That small new  
additions that doesn't touch core functionality, like new apps or  
functions, move quickly in trunk doesn't really hurt. But large  
changes to existing code should propably have a trunk-trunk for  
testing longer than we have done recently. As always, there's the old  
issue with getting people to test a development tree. It worked well  
with test-this-branch, but required a lot of interaction on every  
mailing list, and quick feed-back. Mostly a non-coding issue and more  
of a community management issue.

For many of my customers, the way the 1.6 release series is handled  
means that it's a random hit-and-miss if we can find a version in the  
1.6.x series that will work. Approval and testing of a product version  
takes a lot of time and costs money. Since every 1.6.x version will  
include new features and fixes to broken new features won't be  
backported to the previous release, it will be very hard to put a  
1.6.x based Asterisk in production. (yes, I know that I missed this  
discussion last fall, but I was off line at the time). If this policy  
remains, someone will have to create a Centos-like Asterisk  
distribution based on 1.6 and backport fixes and keep core changes out  
of the code base, "Carrier class Asterisk" :-)

In order for this fork not to happen, we have to separate large  
changes to current code and decide that those requires a new version,  
like 1.8. Small cool additions that doesn't touch core or change  
existing modules can move more quickly into release like the current  
policy for 1.6. Apart from the SIP channel we have some very large  
changes under discussion and implementation - IPv6 support, the new  
bridging system, the codec negotiation framework and others, including  
the ideas about PineMango and the security frameworks. Let's find a  
way to implement these in a responsible way that works with the user  
base, both the persons looking for cool new features and those that  
want code that can be put into carrier production. I don't like to see  
these major changes in the 1.6 tree at all.

Sorry for the long mail, but I feel these are important issues for the  
project. As you see, they're very important to me.

Best regards,
/Olle

-----
PS. The work producing the list of bugs and errors in the SIP TCP/TLS  
code that I've added to chan_sip.c in trunk was funded by Kevin  
Fleming at Digium. (shameful plug:) In order for me to contribute to  
fixing this, I will have to find funding somewhere. It's simply too  
much work to do on spare time.