<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 dir="ltr">On Sun, Oct 8, 2017 at 3:33 PM Bryant Zimmerman <<a href="mailto:BryantZ@zktech.com">BryantZ@zktech.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" size="2" width="100%">
<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">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">asterisk-dev@lists.digium.com</a>><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_-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>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">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">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Seán C McCord<div>CyCore Systems, Inc</div><div>+1 888 240 0308</div><div>PGP/GPG: <a href="http://cycoresys.com/scm.asc">http://cycoresys.com/scm.asc</a></div></div></div>