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

2017-10-08 Thread Corey Farrell
Correction on number of bugs, most PJSIP bugs are filed against resource modules.  If you select all of the "Resources/res_pj*" categories in addition to Channels/chan_pjsip it shows 121 open bugs.  People are reporting issues against the pjsip modules, most are not against the channel driver

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

2017-10-08 Thread James Finstrom
A large percentage of "PJSIP" Sucks comes down to comfort. I talked to several users at astricon and the summary is: Every provider that actually provides documentation only gives a chan_sip block We don't understand how to configure it. My customers need ccss. So one issue with feature parody

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

2017-10-08 Thread Seán C . McCord
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.Unless some miraculously talented and motivated person emerges to maintain chan_sip (which is

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

2017-10-08 Thread Bryant Zimmerman
I would agree with this. We have tried to deploy pjsip several times over the last year with limited success. We have had nothing but issues with database real-time deployments. Tables not working from one 13.x release to another. Table builders sorcery failing out. Issues when there are

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

2017-10-08 Thread Daniel Journo
> What is _also_ needed, however, is more use of PJSIP and reports of specific > problems, and specific deficits of PJSIP so that the fear can be eased > before, at some point many years from now, chan_sip just doesn't work any > more. There are a number of specific issues on issue tracker

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

2017-10-08 Thread Seán C . McCord
As James mentioned at the top, chan_sip is already de facto deprecated. The discussion (at devcon) was centered around making it _officially_ deprecated. For clarity, deprecation is NOT the same thing as removal. (It is also not depreciation, the reduction in value of something.) Deprecation

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

2017-10-08 Thread Troy Bowman
I sincerely hope they don't deprecate it. The pjsip code might seem fine in development and test environments, but I am still afraid of using it in production. I see too many issues with it regularly on this list. I can't gamble stability versus my job security. >From my perspective, chan_sip

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

2017-10-08 Thread Gunnar Hellström
The Real-Time Text feature of Asterisk does not work with PJSIP. Or at least it is not documented how its redundant transport support is configured. See: https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4260034 for how it once worked. (There are bugs in the release 11 and 13

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

2017-10-08 Thread Daniel Journo
Having run pjsip for about a year now in production, I can say that the current implementation isn’t very reliable for scaling. Due to the issues I describe below, I have to run multiple asterisk boxes with around 100 endpoints per box max. Even at that leve, Asterisk on all boxes randomly stop

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

2017-10-08 Thread James Finstrom
One does not simply depricate a sip stack. Ok so at devcon there was a discussion of depricating chan_sip. This may sound a lot worse than it actually is. Chan_sip has been essentially untouched in 4ish years. It does not receive bug fixes. It is just sort of a barge floating in the ocean. So