[asterisk-dev] Recommendations for using a SIP stack with Asterisk

[Paul Belanger]

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

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger