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

[Russell Bryant]

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.

-- 
Russell Bryant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121109/01b18e6e/attachment.htm>