[asterisk-dev] One sip stack to rule them all....
Corey Farrell
git at cfware.com
Sun Oct 8 19:26:44 CDT 2017
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 itself.
On 10/08/2017 07:47 PM, James Finstrom wrote:
> 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 and mostly people who simply don't
> want to configure it.
>
> The process of eventual removal when the ball gets rolling to do so is
> several releases away.
> PJSIP is already in use on Digium's commercial platform which shows
> their level of confidence in the stack.
>
> This ultimately comes down to the chicken vs the egg.
> Once major adoption occurs PJSIP will become a rock. PJSIP will become
> a rock when major adoption occurs.
>
> Looking at the tracker chan_sip has 233 open bugs, Chan_pjsip 38.
> So if our metric is "bugs" then there is a clear winner
>
> Remember the golden rule of software. No ticket, no bug.
>
> Side note remember if it is removed in say Asterisk 19 (made up
> scenario) You don't have to use 19. All the previous releases will
> still have it.
>
>
> On Sun, Oct 8, 2017 at 4:51 PM, Seán C. McCord <ulexus at gmail.com
> <mailto:ulexus at gmail.com>> wrote:
>
> 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 somewhat less likely than
> my dead grandmother taking up x86 assembly), there is no future
> for it. The discussion is not about that. There is no discussion
> about that. This is not about chan_sip vs chan_pjsip. It is
> pointless to wax about the perceived solidity of chan_sip. It is
> not solid. It is not maintainable. It is already years behind.
> People have managed to patch it into a simulacrum of stability
> under certain use cases (though I will admit that those use cases
> are wide and, in a self-fulfilling manner, perhaps do represent
> the majority of present use cases of active users of chan_sip),
> but this will not and has not continued.
>
> Factual deprecation itself is not even under discussion. chan_sip
> _is_ deprecated, whether that is officially acknowledged or not.
>
> Rather, this discussion is about making sure lurkers who are still
> using chan_sip but have not reported specific problems or feature
> gaps have their say, are aware that chan_sip is NOT the
> recommended stack, and understand that chan_sip will (again,
> whether anyone likes it or not) progressively worsen as time
> progresses.
>
>
> On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman
> <BryantZ at zktech.com <mailto:BryantZ at zktech.com>> wrote:
>
> 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 multiple transports on varying networks
> were udp is not routed correctly through the asterisk servers.
> No matter the settings.
> Connectivity issues with varying success by carrier.
> Unexplained audio quality issues that don't occur on the same
> spec running chan_sip
> We want to move to pjsip but the functionality and stability
> have only proven out for limited applications.
> Bryant
> ------------------------------------------------------------------------
> *From*: "Daniel Journo" <dan at keshercommunications.com
> <mailto:dan at keshercommunications.com>>
> *Sent*: Sunday, October 8, 2017 3:12 PM
> *To*: "Asterisk Developers Mailing List"
> <asterisk-dev at lists.digium.com
> <mailto:asterisk-dev at lists.digium.com>>
> *Subject*: Re: [asterisk-dev] One sip stack to rule them all....
>
> > 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 which
> still need addressing before more people will take it on
> properly. Some issues probably require a semi-major rethink
> and probably won’t be dealt with for months.
> Making chan_sip depreciated would leave Asterisk with no
> production grade sip stack that is officially being maintained.
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by
> http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> <http://lists.digium.com/mailman/listinfo/asterisk-dev>
>
> --
> Seán C McCord
> CyCore Systems, Inc
> +1 888 240 0308 <tel:%28888%29%20240-0308>
> PGP/GPG: http://cycoresys.com/scm.asc
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> <http://lists.digium.com/mailman/listinfo/asterisk-dev>
>
>
>
>
> --
> James
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20171008/724e2785/attachment.html>
More information about the asterisk-dev
mailing list