[asterisk-dev] SIP TCP and TLS support (was oej: trunk r128290 - /trunk/channels/chan_sip.c)

[Russell Bryant]

Johansson Olle E wrote:
> Your comments here indicate that you need much more experience
> with SIP before you make definitive statements about it and decisions
> about the implementation...
> 
> I've worked hard to make chan_sip a bit more standardized and  
> compliant and
> that's why I do not like and react strongly when you commit stuff
> that takes us back many steps... I apologize, but you have to
> understand that chan_sip has been my focus for such a long time
> that I want to be proud of it. I'm not proud of this version.
> 
> These issues, and a list of other things, shows that we need to work a  
> lot more
> on the TCP/TLS support to get things right. The commit was premature
> according to your earlier mentioned rules, it should have stayed in
> a branch a while more. But that's old news. Let work on fixing it
> and fixing it so that it complies with both implementations and
> the standards. It's important for Asterisk that we have this support,
> but also that it properly interoperates with other equipment.

One important key thing to recognize if one wants to be the leader of 
anything, is that there is no way that all of the work can be done 
alone.  If all of the work could be done by one person most efficiently, 
then it would, and we would have no need for leaders.  Asterisk is 
clearly too large of a project for one person to take on alone. 
chan_sip, as a subcomponent of the Asterisk project, is also far too big 
of a project for one person to take on alone.

Now, once it is clear that help is needed, great care must be taken in 
managing the help that you receive.  One of the most critical parts of 
this, especially in a community project, is respecting the work done by 
others.  The approaches taken by others may not be the same as the 
leader may have taken, but as I said, there is no way one person can do 
it all.

I'm not an expert of the SIP protocol, nor have I ever claimed to be. 
However, I do know quite a bit about Asterisk, as well as responsible 
community development.

With regards to SIP TCP and TLS support, it was developed in pretty 
standard open source style.  It was worked on by multiple people, tested 
between Asterisk servers, with Polycom phones, the minisip softphone, 
Cisco gateways, Snom phones, and the Zoiper softphone all before it was 
committed to Asterisk trunk.  After multiple developers had their hands 
in the code, multiple people reviewed the code, and a number of 
endpoints were tested, the code was committed as the first revision of 
SIP TCP and TLS support for Asterisk.

It's a shame that for unrelated reasons, you were not able to 
participate in this effort earlier in the process.  However, as a 
community project, development will go on, and has gone on.

You have done a lot of nice things with the SIP support in Asterisk.  I 
would love to see this work continue.  You are in a position to be a 
leader in this area.  Help others understand, and help me understand, 
what we can do to improve the code.

Keep the discussions technical.  Comments that people are not qualified 
to make decisions, that the work people have done is not useful, and 
that the work people have done has actually been a _detriment_ is 
inappropriate, unprofessional, and nothing but counter-productive.

We have the same goal here.  Let's work together in a productive way to 
make SIP support in Asterisk as great as we possibly can.

> There are, as I mentioned in our meeting in Huntsville, some core
> aspects of this that we need to consider as well before we lock
> the implementation of TLS in chan_sip and move it away
> from experimental status.

This sounds like a great place to start the discussion and getting these 
ideas written down.  The things that I remember are less about the 
implementation, and more about providing more enhanced ways for 
transport selection to be configured (per-call, per-domain, etc.).

You added a comment in chan_sip, "Fix TCP/TLS handling in dialplan, SRV 
records, transfers and much more", but that's not very informative.

For the dialplan, I assume you mean your idea for wanting to be able to 
force a secure call from the dialplan.  That sounds like a reasonable 
enhancement.  I know you have presented this idea before.

For SRV records, I assume you mean checking for multiple transports, 
where as right now, it checks for the single configured transport for 
that endpoint.  It would be nice if we could expand the SRV lookup API 
such that we could traverse the results instead of having to do a 
function call (and a DNS lookup) for each transport we care about. 
There are more advanced things to do, but the code now is pretty simple. 
  If you configure chan_sip to connect to an endpoint via TCP, then it's 
going to do so via the hostname in an SRV record for SIP/TCP, or by the 
configured hostname for that peer.

I'm not sure about transfers, and "much more" is pretty much just 
inflammatory.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.