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 <ule...@gmail.com
<mailto:ule...@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
<brya...@zktech.com <mailto:brya...@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" <d...@keshercommunications.com
<mailto:d...@keshercommunications.com>>
*Sent*: Sunday, October 8, 2017 3:12 PM
*To*: "Asterisk Developers Mailing List"
<asterisk-dev@lists.digium.com
<mailto:asterisk-dev@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
--
_____________________________________________________________________
-- 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
