<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/08/2017 07:47 PM, James Finstrom
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE3BMY1BTVzKNfzrbqfoqs9bmUgASir0VM_DJ2f_ve=fTTD9fw@mail.gmail.com">
<div dir="ltr">A large percentage of "PJSIP" Sucks comes down to
comfort. I talked to several users at astricon and the summary
is:
<div><br>
</div>
<div>Every provider that actually provides documentation only
gives a chan_sip block</div>
<div>We don't understand how to configure it.</div>
<div>My customers need ccss.</div>
<div><br>
</div>
<div>So one issue with feature parody and mostly people who
simply don't want to configure it.</div>
<div><br>
</div>
<div>The process of eventual removal when the ball gets rolling
to do so is several releases away.</div>
<div>PJSIP is already in use on Digium's commercial platform
which shows their level of confidence in the stack.</div>
<div><br>
</div>
<div>This ultimately comes down to the chicken vs the egg.</div>
<div>Once major adoption occurs PJSIP will become a rock. PJSIP
will become a rock when major adoption occurs.<br>
</div>
<div><br>
</div>
<div>Looking at the tracker chan_sip has 233 open bugs,
Chan_pjsip 38.</div>
<div>So if our metric is "bugs" then there is a clear winner</div>
<div><br>
</div>
<div>Remember the golden rule of software. No ticket, no bug.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Oct 8, 2017 at 4:51 PM, Seán C.
McCord <span dir="ltr"><<a href="mailto:ulexus@gmail.com"
target="_blank" moz-do-not-send="true">ulexus@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.
<div><br>
</div>
<div>
<div>Factual deprecation itself is not even under
discussion. chan_sip _is_ deprecated, whether that is
officially acknowledged or not.</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div>
<div class="h5">
<div dir="ltr">On Sun, Oct 8, 2017 at 3:33 PM Bryant
Zimmerman <<a href="mailto:BryantZ@zktech.com"
target="_blank" moz-do-not-send="true">BryantZ@zktech.com</a>>
wrote:<br>
</div>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5"><span
style="font-family:Arial,Helvetica,Sans-Serif;font-size:12px">
<div>I would agree with this. We have tried to
deploy pjsip several times over the last year
with limited success. </div>
<div>We have had nothing but issues with database
real-time deployments. Tables not working from
one 13.x release to another. </div>
<div>Table builders sorcery failing out. </div>
<div> </div>
<div>Issues when there are multiple transports on
varying networks were udp is not routed
correctly through the asterisk servers. No
matter the settings. </div>
<div> </div>
<div>Connectivity issues with varying success by
carrier. </div>
<div> </div>
<div>Unexplained audio quality issues that don't
occur on the same spec running chan_sip</div>
<div> </div>
<div>We want to move to pjsip but the
functionality and stability have only proven out
for limited applications.</div>
<div> </div>
<div> </div>
<div>Bryant</div>
<div> </div>
<hr align="center" width="100%" size="2">
<div><span
style="font-family:tahoma,arial,sans-serif;font-size:10pt"><b>From</b>:
"Daniel Journo" <<a
href="mailto:dan@keshercommunications.com"
target="_blank" moz-do-not-send="true">dan@keshercommunications.com</a>><br>
<b>Sent</b>: Sunday, October 8, 2017 3:12 PM<br>
<b>To</b>: "Asterisk Developers Mailing List"
<<a
href="mailto:asterisk-dev@lists.digium.com"
target="_blank" moz-do-not-send="true">asterisk-dev@lists.digium.com</a><wbr>><br>
<b>Subject</b>: Re: [asterisk-dev] One sip
stack to rule them all....</span></div>
</span><span
style="font-family:Arial,Helvetica,Sans-Serif;font-size:12px">
<div>
<div> </div>
<div
class="m_-3946323705817662575m_-611516591877919559WordSection1">
<p><span
style="font-size:10.0pt;font-family:"Arial","sans-serif"">>
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.<br>
<br>
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.<br>
Making chan_sip depreciated would leave
Asterisk with no production grade sip
stack that is officially being maintained.</span></p>
</div>
</div>
</span></div>
</div>
--<span class=""><br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a
href="http://www.api-digital.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.api-digital.com</a>
--<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a
href="http://lists.digium.com/mailman/listinfo/asterisk-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-dev</a></span></blockquote>
</div>
<div class="HOEnZb">
<div class="h5">
<div dir="ltr">-- <br>
</div>
<div class="m_-3946323705817662575gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">Seán C McCord
<div>CyCore Systems, Inc</div>
<div><a href="tel:%28888%29%20240-0308"
value="+18882400308" target="_blank"
moz-do-not-send="true">+1 888 240 0308</a></div>
<div>PGP/GPG: <a
href="http://cycoresys.com/scm.asc"
target="_blank" moz-do-not-send="true">http://cycoresys.com/scm.asc</a></div>
</div>
</div>
</div>
</div>
<br>
--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a
href="http://www.api-digital.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.api-digital.com</a>
--<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a
href="http://lists.digium.com/mailman/listinfo/asterisk-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">James </div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>