[asterisk-dev] One sip stack to rule them all...

[Bruce Ferrell]

On 10/09/2017 07:11 AM, Daniel Journo wrote:
>>> Every provider that actually provides documentation only gives a chan_sip block
>>> We don't understand how to configure it.
>>> My customers need ccss.
> 
>> You bring up an issue that was discussed at Devcon. We, as a community, need to step up and provide this kind of documentation, best practices, and examples so people can use Asterisk (and in this case PJSIP) properly and with confidence.
>> If we want people to use it, we need to show them how to do it in a supported and stable way.
> 
> Your point about every provider only documenting chan_sip is an interesting one. Most advanced users would be able to learn how to configure PJSIP using the wiki. Beginners asking 

Actually the wiki SUCKS as do most wiki's... They presume too much and leave too much unsaid as "obvious".
My rule of thumb when I write documents is that if I think it's obvious, it probably isn't and needs to be
explicitly called out.  The Asterisk book is/was good at that.

I've been attempting to use the wiki for pjsip to get a recent Digium blog entry working (the one of
video conferencing).  It's a nice step by step... and it doesn't work for me.  And precisely ZERO on
how to figure out why.

I WAS able to get hard phones to register, but I have to say, it's convoluted and I can't see a good reason
for making it that way.  Maybe it's "obvious".  chan_sip has a clean configuration for endpoints.


> questions on the #asterisk irc channel are often told to go to the Asterisk book to learn how to configure Asterisk. As the latest Asterisk book was written for v11, I think that 
> would be one of the major causes of the continued usage of chan_sip rather than the providers.
> 
> I'm surprised to hear that Digium uses PJSIP commercially because I've always struggled with various bugs and issues. I can't reload PJSIP without causing any downtime for example. 
> PJSIP is getting there, but it has a way to go before it can be trusted.
> I don't consider my use case of 100 endpoints per Asterisk box to be particularly unusual, but I do have my fair share of bugs with PJSIP. So do others I speak to on IRC.
> 
>>>> I obviously failed to sufficiently emphasize the point.  Whether you like it or not, whether you think pjsip is ready or not, whether it is better or not, chan_sip is effectively at a dead end

Ya know, I've seen this trumpeted quite a bit... A dead end is something going nowhere and doesn't work.

Like it or NOT... It seems that for a significant number of applications chan_sip DOES work and does so better
than pjsip does.

As I was taught many, many, years ago, good engineering is about cost effective solutions, not "whiz bang"
technology.  If the cost in effort/downtime/etc is more for the "cool/forward looking" technology is higher
and presents barriers to adoption, that test fails.



> I'm not sure what the purpose of this thread is then. It seems like this is not actually a question of whether it should be depreciated. Just a statement that it is. If it is, 
> PJSIP needs some serious work otherwise it opens the window for commercial solutions to take some market share.
> 
> If chan_sip is a dead end and it is made officially depreciated, it would have the following effect:-
> 
> - It would 'hopefully' increase uptake and therefore bug reports. As long as there are people able to work through them, that’s fine. Otherwise, it opens the window for commercial 
> solutions to take some market share.
> - There would currently be no reliable sip stack for some use cases whereas chan_sip worked fine as some support is still available.