[asterisk-dev] SIP TCP and TLS support (was oej: trunk r128290 - /trunk/channels/chan_sip.c)
russell at digium.com
Tue Jul 8 08:19:39 CDT 2008
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
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
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
Senior Software Engineer
Open Source Team Lead
More information about the asterisk-dev