[asterisk-dev] SIP TCP/TLS, release policy and more (personal opinions included)
Johansson Olle E
oej at edvina.net
Sun Oct 19 03:30:13 CDT 2008
(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)
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.
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.
More information about the asterisk-dev