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

[BJ Weschke]

 Olle / Team - Responses interspersed below.... when I first read it 
early this morning, my initial thought was not to respond because it 
initially struck me as troll bait based on your warning and some of the 
content below. After re-reading it a few times though, I don't think 
that this was your intent and you raise some very important issues that 
do warrant attention and further discussion.

Johansson Olle E wrote:
> (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.
>   

 Olle - You say that chan_sip has done well with UDP at the latest 
SIPit. At the end of the day, I don't think any one is disputing the 
fact the SIP over TCP and then TLS suport needs a good amount of work 
still to be fully compliant. I very much appreciate the time and 
expertise you donated this past week to identify areas of improvement 
still needed. Knowing what still needs to be done is half the battle 
done. However, once all that work is complete, whether the larger 
project, Asterisk, calls it 1.6.1, 1.6.2, 1.8.X, or KiwiStrawberry 
Dipped in Fudge, does it really matter?  While chan_sip is a very 
important part of Asterisk it is not, by itself, Asterisk as a whole. 
The new release policy was put in place to address real issues and 
challenges that were present in the old policy.

> 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.
>
>   
 IMHO, -2 on these comments above. I think Russell is doing an excellent 
job as maintainer of Asterisk. He eats, sleeps, and breathes Asterisk 
regardless of who he presently works for. The problem we're having here 
is not a new one. Unfortunately, for as long as I've been involved with 
this project now, we still really haven't come up with a good solution 
to the issue. I thought the Advisory Council was a good idea and a great 
step in that direction, but I never got the feel that the Council hit 
the ground running beyond the initial appointments. The Asterisk 
maintainer, Russell or any one else for that matter, isn't running a 
monarchy. What needs the work here to solve this problem is a more 
community oriented conflict resolution process. This is something that I 
would think that the Asterisk Advisory Council (if rekindled?) would 
have a key role in with John Todd at his new role with Digium playing 
liaison between the needs/wants of the community and the needs/wants of 
Digium.

> 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.
>
>   
  Doesn't the current svn structure with a group/team branch formed off 
of the existing /trunk already provide good infrastructure for 
accomplishing what you're proposing above? I do completely agree with 
your suggested approach. We cannot put trunk into a position where we'd 
be locking out the possible transition of other features/functionalities 
that are ready from trunk to release branch because SIP work is taking 
longer.

> 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" :-)
>
>   
 Why does it have to be "someone" ?   Why couldn't this be a community 
oriented effort and not a fork? I think it's an excellent suggestion. 
Your points are valid. The release policy as it exists now shouldn't be 
written in stone. I think it's very healthy for the community to revisit 
at least every 6-12 months processes and policies to make sure they are 
really "best practice" for achieving the highest level of productivity.

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

 They're very important issues to all of us. Again, you've raised very 
valid points. The community should discuss this further and come up with 
a suitable go forward plan that everyone or at least the majority 
decides is the appropriate direction.  While all of this is fine and 
good, beyond the establishment of that new policy / procedure, we still 
grapple with the challenge of allocating adequate resources that would 
be required to drive/support any new initiatives.

> -----
> 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.
>
>   
  I struggle with the same issues Olle. At the end of the day, we all need to support ourselves and our families. That is not done with "having pride in our product". While I would certainly entertain discussion on this matter too, I suspect this is probably the single most difficult topic in this whole email to solve when it comes to independent consultants like yourself and myself who want to contribute, but also need to maintain the bottom line.

 BJ

--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/