<html><head></head><body bgcolor="#FFFFFF"><div><div>Sobre a reescrita do stack SIP no Asterisk.</div><div><br></div><div>Importante e precisamos estar atentos a esta mudança, pois o impacto pode ser grande o início, mas com benefícios a médio e longo prazo.</div><div><br></div><div>Abs,<br><br>Denis at mobile.</div><div><br>Begin forwarded message:<br><br></div><blockquote type="cite"><div><b>From:</b> Matthew Jordan <<a href="mailto:mjordan@digium.com">mjordan@digium.com</a>><br><b>Date:</b> 10 de dezembro de 2012 23:56:41 BRST<br><b>To:</b> Asterisk Developers Mailing List <<a href="mailto:asterisk-dev@lists.digium.com">asterisk-dev@lists.digium.com</a>><br><b>Subject:</b> <b>[asterisk-dev] SIP Stack - Update</b><br><b>Reply-To:</b> Asterisk Developers Mailing List <<a href="mailto:asterisk-dev@lists.digium.com">asterisk-dev@lists.digium.com</a>><br><br></div></blockquote><div></div><blockquote type="cite"><div><span>Greetings!</span><br><span></span><br><span>Recently, we've had a lot of discussion about which SIP stack to use for</span><br><span>a new SIP channel driver [1]. Josh's initial research [2] resulted in</span><br><span>three candidates: Sofia-sip, reSIProcate, and pjproject. All three SIP</span><br><span>stacks have various advantages and disadvantages, which the community</span><br><span>discussed in depth [3]. While there are many factors to consider in the</span><br><span>choice of a SIP stack, the discussion primarily landed on whether or not</span><br><span>the SIP stack could be available as a package outside of the Asterisk</span><br><span>source.</span><br><span></span><br><span>Of the three candidates, both Sofia-sip and reSIProcate are available as</span><br><span>packages. However, it was determined that Sofia-sip is no longer</span><br><span>actively maintained, and the largest project that utilizes it currently</span><br><span>embeds it within their source. While there may be options there, the</span><br><span>fact that there is no active upstream maintainer of the Sofia-sip stack</span><br><span>means that we would become the SIP stack maintainers ourselves, which</span><br><span>would be a very limited improvement from the current state of SIP in</span><br><span>Asterisk.</span><br><span></span><br><span>This leaves reSIProcate and pjproject. reSIProcate is a fantastic SIP</span><br><span>stack that is available as a package on some distros; it is, however,</span><br><span>written in C++ and does not currently declare an API compatible with C</span><br><span>linkage. The pjproject SIP stack is also a great SIP stack and one that</span><br><span>Digium is very familiar with; however, it is not available as a package</span><br><span>and its build system is oriented toward embedding in a project. As both</span><br><span>have similar SIP capabilities, this leads us to the following two questions:</span><br><span>1) If a C++ SIP stack were chosen, what effect would that have on the</span><br><span>SIP channel driver that uses it, and on the Asterisk project as a whole?</span><br><span>2) Is it possible to package pjproject?</span><br><span></span><br><span>The second was easier to answer. While not exactly a trivial effort, it</span><br><span>is possible to modify the pjproject build system to produce shared</span><br><span>object libraries suitable for packaging. Teluu has agreed to support</span><br><span>such an effort, although the work would have to be started by the</span><br><span>Asterisk project. The initial project to create such a package is</span><br><span>outlined on the Asterisk wiki [4]. At a minimum, Digium will work to create:</span><br><span> * A Git repository with a modified build system that produces shared</span><br><span>object libraries and install targets of the libraries needed by Asterisk.</span><br><span> * Tarballs on <a href="http://downloads.asterisk.org">downloads.asterisk.org</a>.</span><br><span> * A package for CentOS.</span><br><span>Ideally, the entire repository would end up being pushed up stream, but</span><br><span>this would work in the interim to pull pjproject outside of the Asterisk</span><br><span>source. The results of this effort will be available for developers who</span><br><span>are interested in using them as the basis for creating and maintaining</span><br><span>packages for other distributions.</span><br><span></span><br><span>The first question was harder: what impact would a C++ SIP stack have on</span><br><span>the Asterisk project? There are two facets to this:</span><br><span>1) The technical impact on using C++ libraries in C</span><br><span>2) The impact on the Asterisk community.</span><br><span>The first poses significant problems – for a full write up, see [5]. To</span><br><span>summarize that page, the C++ model of memory management, error handling,</span><br><span>and building has major implications that would fundamentally change the</span><br><span>Asterisk project. That leads to the second issue - given that Asterisk's</span><br><span>developer community have traditionally written modules in C, a C++ SIP</span><br><span>stack would potentially create a barrier for entry in development for</span><br><span>the current community. Based on those two problems, using a SIP stack</span><br><span>written in C++ would have to be a last resort for the Asterisk project.</span><br><span></span><br><span>Given all of the above, we feel that going with pjproject as a SIP stack</span><br><span>is feasible and the best option for Asterisk. If Asterisk were written</span><br><span>in C++ I'm certain we would have chosen reSIProcate, but as it is, the</span><br><span>only major issue with pjproject is its lack of a package, which I</span><br><span>believe we can address. Thanks to everyone who has participated in the</span><br><span>discussion – with your input, I think we have what is the best path</span><br><span>forward for Asterisk.</span><br><span></span><br><span>[1] <a href="http://lists.digium.com/pipermail/asterisk-dev/2012-November/057512.html">http://lists.digium.com/pipermail/asterisk-dev/2012-November/057512.html</a></span><br><span></span><br><span>[2] <a href="http://lists.digium.com/pipermail/asterisk-dev/2012-November/057549.html">http://lists.digium.com/pipermail/asterisk-dev/2012-November/057549.html</a></span><br><span></span><br><span>[3] <a href="http://lists.digium.com/pipermail/asterisk-dev/2012-November/057591.html">http://lists.digium.com/pipermail/asterisk-dev/2012-November/057591.html</a></span><br><span></span><br><span>[4] <a href="https://wiki.asterisk.org/wiki/display/AST/Packaging+pjproject">https://wiki.asterisk.org/wiki/display/AST/Packaging+pjproject</a></span><br><span></span><br><span>[5]</span><br><span><a href="https://wiki.asterisk.org/wiki/display/AST/Investigation+of+a+reSIProcate+Based+SIP+Channel+Driver+in+Asterisk">https://wiki.asterisk.org/wiki/display/AST/Investigation+of+a+reSIProcate+Based+SIP+Channel+Driver+in+Asterisk</a></span><br><span></span><br><span>-- </span><br><span>Matthew Jordan</span><br><span>Digium, Inc. | Engineering Manager</span><br><span>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</span><br><span>Check us out at: <a href="http://digium.com">http://digium.com</a> & <a href="http://asterisk.org">http://asterisk.org</a></span><br><span></span><br><span></span><br><span>--</span><br><span>_____________________________________________________________________</span><br><span>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --</span><br><span></span><br><span>asterisk-dev mailing list</span><br><span>To UNSUBSCRIBE or update options visit:</span><br><span> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></span><br></div></blockquote></div></body></html>