[asterisk-dev] 13 November, 2012 New SIP stack update

[Olle E. Johansson]

Friends,

A few years ago, after 1.4 release my opinion was that the stack in Asterisk chan_sip wasn't the
big issue, tests showed that it was better than I thought at the time ;-)

The big issue was the code - one large chunk based on an old chan_iax - and the internals. Peers
and users that makes no sense from a SIP point of view. No transaction support.

After 1.4 with the additions of IPv6 as well as TCP and TLS - things are much worse and
I agree that we need to restart or do a massive clean up, which in fact would be a restart. The current
code base costs too much to maintain. I do agree with the decision to start a new project,
something that I've been waiting for many years to happen. 

I find it hard to depend on an upstream provider of a library for such a core feature, but also recognize
the fact that using an existing SIP stack would speed up the process. This discussion is critical for the 
future of Asterisk and I do appreciate very much that it happens outside the corridors in Huntsville.

I've reported bugs to SIP software and got as an answer that I have to report it to PJSIP directly - as a user. 
That's no good. A project needs to be able to deliver a quality product and have some level of control. 
PJsip doesn't seem to make it possible to control quality without a fork, something that I don't understand. 
As stated before, I have not developed or interacted with PJsip directly so I have no personal experience.
This is just based on observations of other that develop with the library.

The Asterisk project need to always be able to handle our own bugs and support our users. If the upstream
developer group makes it hard for us to do so, forking and managing our own fork is the only option and
we should not be afraid of it, even though it's of course the very last option. If we realize from start
that this is what we have to do with a SIP stack, we've selected a bad option. In the end, it may
be the only one.

Unfortunately that's what I see with both PJsip, Resiprocate and Sofia users - many private "forks". 
I have no insight into why this is the state of the SIP stack "industry". The discussion I've had with
developers indicates low interest, a limit in resources to manage incoming patches or different opinions 
about the need for them - or combinations. Like us in Asterisk, the other projects are probably
in a state where lack of funding makes it hard to spend time on general housekeeping and 
just have to focus on short term revenue-related work. They are all good guys, but everyone
gotta get a living, and with the financial climate we have today, resources are very limited.

When I looked at 3rd party stacks a few years ago there was a lot of functionality missing from 
Asterisk's point of view. They all had high-level interfaces for people who wants to create SIP phones, but some 
operations in a b2bua are very low-level. Look at the stuff we need to do in order to support call transfers,
where we fake some SIP messages to be sip-compliant, just because we can't get proper information from
the other end of the call. Most of the SIP stack developers I talked with then would not let us do
that low-level stuff and break their elegant API's and phone abstractions.

SIP is such a core function in Asterisk so this is a huge decision. If we end up managing a fork
mostly by ourselves, then we are in the same situation that we're in today, but with an updated
code base with an oppurtunity to improve things easier than today. And an oppurtunity to do
things right, from the core out to sip.conf.


I would like to see another discussion soon - how we should change the core PBX in order
to be able to build a proper SIP stack. If Digium and the community invest in this development,
I would like to see an upgrade of the core so that we can do things right. In my installations,
I have almost only SIP. I do believe a majority of Asterisk channels today are SIP. 

That wasn't the state when the core was designed, which gives us translations to ISDN cause codes,
caller IDs that doesn't support domains and much more that makes it complicated to implement
SIP properly. Don't you think it's time we took a look at this and the architecture of a potential
new SIP channel driver so we don't start with peers/users and confuse everyone again... :-)

Let's continue the SIP stack discussion and I'll try to back off and let people with experience
of developing with these stacks hash this out. 

Cheers,
/O