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

[Faidon Liambotis]

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.

Regards,
Faidon