On Fri, Nov 9, 2012 at 7:19 PM, Faidon Liambotis <span dir="ltr"><<a href="mailto:paravoid@debian.org" target="_blank">paravoid@debian.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 11/09/12 23:28, Mark Michelson wrote:<br>
> 1. If we use PJSIP, no distros have packages for it. If we use<br>
> ReSIProcate, then distro package support is limited. We cannot, as an<br>
> alternative to bundling it with Asterisk, tell people to use their<br>
> distro's package.<br>
<br>
</div>That's fixable, isn't it? If you use a sensible library, then distros<br>
will happily package that and the whole ecosystem will profit. Note that<br>
both resiprocate and sofia-sip are packaged e.g. in Debian/Ubuntu, and<br>
pjsip is probably not packaged because a) it doesn't have that many<br>
software using it, b) it doesn't build a shared library, as previously<br>
stated (although there's an intent-to-package python-sipsimple, which<br>
also embeds pjsip, so there's that problem again).<br>
<div class="im"><br>
> 2. There is a 100% chance that, no matter which SIP stack we use, we<br>
> will need to make modifications to suit Asterisk's needs.<br>
<br>
</div>These modifications should go to the upstream SIP stack project. That's<br>
how the ecosystem works in every other software and library out there --<br>
that's what Asterisk does with every other library that it uses too.<br>
<br>
Can you imagine an ecosystem in which every project embeds and modified<br>
every other library? Would Asterisk even exist in such an ecosystem?<br>
<div class="im"><br>
> 3. If users are forced to do something arcane in order to be able to<br>
> upgrade to Asterisk 12 and use the new SIP channel driver, they simply<br>
> won't do it.<br>
<br>
</div>Depends. I don't see how building a separate library (in case the distro<br>
is lacking a package) would be so difficult to do for users. Isn't that<br>
how it goes for libpri, among others?<br>
<div class="im"><br>
> 4. Users will not tolerate having to wait for patches to be merged<br>
> upstream in order to provide fixes for their SIP issues.<br>
<br>
</div>Why? How's it any different than waiting for Asterisk to merge the patches?<br>
<br>
The only difference seems to be that this SIP stack wouldn't be in your<br>
immediate control. If it's a control issue, It sounds to me like you<br>
don't really want to use a third-party SIP stack.<br>
<div class="im"><br>
> With all of these in mind, what do you suggest the Asterisk project does<br>
> in order to use a third-party SIP stack?<br>
<br>
</div>Work with the community, both upstreams (SIP stacks) and downstreams<br>
(distros). Talk with the SIP stack candidates and ask them what their<br>
feeling is about it. Try to contribute to them so you can affect changes<br>
on them, get commit access and affect their release schedule.<br>
Pick a stack based not only its SIP features and compliance, but also<br>
its integration with the system, the ability to stand as a standard<br>
library with a well-defined API and ABI, the community behind it and the<br>
attitude of the maintainers.<br></blockquote><div> </div><div>Very well stated, Faidon. +1.</div><div><br></div><div>-- </div><div>Russell Bryant </div></div></div>