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

[Chris Tooley]

On Mon, Oct 20, 2008 at 8:59 AM, Grey Man <greymanvoip at gmail.com> wrote:
>>  You're digressing into troll bait here. Did this stack implementation you've cited already include a fully state aware session transaction manager? I would hope that it did for your minimal amount of work required to be adequate such that an implementation passes muster at an event like SIPit.
>>  The fact of the matter is that chan_sip is what it is and has been and remains to be fully functional for many hundreds of thousands of Asterisk installations it exists today. It's now time for healthy discussion and productive work towards making further improvements on it in the future.
>
> No trolling intended here I am merely an Asterisk end user with an
> intense interest in the SIP stack and who has been depending on it
> commercially for the last 4 years.
>
> Comparing SIP implementations could be a useful exercise, perhaps
> Asterisk could absorb a few concepts from the numerous stacks that are
> already running TCP.
>
> In regards to the SIP transaction layer yes the stack I mentioned did
> already have it. It actually mystifies me why transactions weren't
> used in the initial Asterisk SIP implementation since they are
> fundamental for B2BUA and it's not a huge amount of work compared to
> oher tasks in the SIP stack like message/header parsing and processing
> (a rough estimate from the afore metioned stack is approx 5000 lines
> for SIP message processing and 1000 lines for the transaction layer).
> The current SIP TCP dilemna is an example of the pain that ommission
> has caused.
>

We discussed replacing the stack at AstriDevCon.

Olle, you mentioned that there were some changes that needed to be
made in Core, but I'd really like to get some clarifications as to
what those actually are.  I have no doubt that it isn't the case,
don't get me wrong, but an enumerated list would be helpful.
Something that could become a "plan" to actually do it would be a good
start.

What we had discussed was using reSIProcate as the actual SIP stack
and implementing Asterisk using it.  The license seems to fit well,
the stack is generally complete, and the process of integration seemed
relatively straightforward.

We did come to the conclusion that replacing the stack portion of
chan_sip was not a silver bullet, but it seems to me that it's a good
start on a new channel driver which can be reimplemented.  No, it's
not a simple task, and yes it requires a lot of time.  But, it
provides us with a clean slate to do a better design (starting with
the large amount of work Olle has already put into codename pineapple)
and provides us with a way to do things in a much better way.  Also,
as Kevin mentioned at Astricon, implementing a channel driver with all
the new features of core is much simpler, and easier to debug.

I would hate to see this devolve into a flame war, and while there are
definitely a lot of issues with the current SIP channel driver, I have
to agree with Kevin at least in part.  The UDP portion of Asterisk's
SIP stack has a lot of good things going for it, and does handle a lot
of things quite well.

Chris Tooley