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

Tue Nov 13 08:34:25 CST 2012

On 12-11-13 09:17 AM, Daniel Pocock wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 13/11/12 14:31, Marek Cervenka wrote:
>> Dne 10.11.2012 23:18, Paul Belanger napsal(a):
>>> 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.
>>>
>>
>> +1 SIP stack need good references. Asterisk is good reference.
>>
>
> I'm just replying on behalf of reSIProcate, which I've been involved
> with intermittently for about 7 years
>
> This year, I've made the following contributions to reSIProcate that
> are directly relevant to Asterisk (and other potential users):
>
> - - converting the build system to autotools.  There was initially some
> skepticism about this, and people wanted it very thoroughly tested on
> all the main target platforms.  Surprisingly, autotools did it's magic
> and built the stack on platforms like MacOS that I had never tested on
> myself.  It is now very easy to build, just ./configure && make, much
> like other Asterisk dependencies.
> http://www.resiprocate.org/AutotoolsBuild
>
> - - packaging for Debian/Ubuntu.  This was also a big effort, because it
> depended upon the autotools work and because there was a lot of
> non-free contrib material in the source tree.  All those issues were
> resolved.  As part of the packaging strategy, each reSIProcate release
> goes into Debian independently, e.g. you can have both the 1.8 and
> eventually 1.9 libs installed concurrently.  This will be useful if
> Asterisk depends on a particular ABI version.
> http://packages.debian.org/source/sid/resiprocate
>
> - - mutual TLS implementation.  A lot of the foundation was already
> there, I just finished it off and added config options for the proxy
> `repro' to run full mutual TLS for federated SIP over the public
> internet.  I consider this much more practical and secure than
> connecting Asterisk directly to the public Internet.  I actually run
> my own Asterisk behind a repro proxy, all my Polycom phones
> authenticate to the proxy using their client certs.
>
> http://www.resiprocate.org/Using_reSIProcate_and_repro_for_Federated_VoIP
>
> http://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi
>
> Going forward, I think this could have great potential for Asterisk
> and reSIProcate alike
>
> If you look over the 1.8 release, you'll find most of the work has
> been done by Scott Godin, he is by far the most active developer at
> present and he knows the stack inside-out.  He has also ensured a high
> standard of C++ coding is maintained.  Scott and I have probably been
> the most active committers this year, so there probably is space for
> other people to contribute directly rather than forking.  We've also
> had some discussion about using git (maybe even github), this would
> also help bring people into the project using the pull request process.
>
> The autotools build system is actually very generic, I've deliberately
> done things in such a way that it should be very easy to build RPMs.
> So although RPMs don't exist, making a spec file for an autotools
> project is not hard and if somebody writes one, I'd be happy to commit
> it.  It could then go into Fedora and EPEL.
>
> I've also recently added reSIProcate for OpenWRT, this validated very
> thoroughly the ability of the autotools system to cross compile.
> http://patchwork.openwrt.org/patch/2655/
>
> The features of reSIProcate are quite extensive, some of the
> interesting things for Asterisk and Digium:
>
> - - IPv6
>
> - - full TLS
>
> - - the `repro' proxy is part of the source tree
>
> - - the stack also includes a TURN client library, TURN server and
> various other goodies
>
> - - BSD style licensing
>
> A further benefit of using reSIProcate is the licensing and
> contribution policy.  People who are not comfortable with the Digium
> contributor agreement and don't contribute directly to Asterisk may
> still be willing to contribute fixes directly to reSIProcate itself.
> Such contributions must be made under BSD terms.  The contributor
> retains copyright and ownership of their contributions, but because it
> is a BSD style project, it will not impact Digium's business model.
>
> I fully support the idea of closer collaboration between upstream
> projects, library projects and distributions, as suggested by Faidon.
>   I believe it is workable.  The Debian Maintainer program (DM) is an
> express lane into the Debian project suitable for upstream developers
> (e.g. from Digium) who want to focus on one or two packages rather
> than Debian as a whole.  It is a win-win situation for all, as it
> means package updates can be pushed more quickly, and the upstream
> project starts to follow a path that makes packaging easier.
>
> As an initial step, I would recommend obtaining the reSIProcate source
> and running the test cases, and looking over the test cases to see how
> the stack is used.  It would then be worthwhile to write test cases
> for features that you expect to use for Asterisk, this will validate
> the stack works the way you expect, and help us all to avoid
> regressions in future.
>
> If you have specific questions about reSIProcate features, compiling,
> etc, please come and ask on the lists:
> http://list.resiprocate.org/mailman/listinfo
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCAAGBQJQolaVAAoJEOm1uwJp1aqDtlgP/2dtGFlzsoCt0OvFyHaCsH15
> k/XeP1B/+o2oO0J6xVxPrM0IZjLd4OTWKp5cSarRSubgSj7k59oueeUHKdtAHhbi
> 9eW0lyrsnHMhz9qDsvDP7X9phy2fYDSU2VVaxn7qysWVdVjY4q6ylQ2vRS/svmBE
> 1uksXXiU84xFuR8IPQ4MHgXgajRgc2S5/r0kvtx+l38CeTmkxqzGImg6LYsT/E+Q
> 9q3i+8w/dk+LDhXVjO5qJNSPrcnG9NZKJOeIfoViPsL5OXPTPO4uuafCNP/v5IKx
> hYaBzewATAKvQDVDxyVo9E1Arg0KpKQQ5tGETgcM1AvD+mqz1rj0y5HKF5Lsljg+
> a854/wKxbQ4QFsrLr2SD7S4tsPMCghEyGCQO6r4QxFwSgozsosm+oPO13pkajjJD
> jftKHV5xKXI7jzDe5NrXkVwuqQH6KCiuD7SZ4hb6y8WI57i5ScfJ6hT17vT6zZ9c
> 8rCELrF2g6eXzBEWT7+3p52pPUS4Av80NkaR5N/IHetG13s177uAgJ+TwnO+DyZG
> 14bXixoGNKg4UjDnJbIL67FwUfplpEnaPF18zWEE7VXLiN06gYMo3Owd7NqCbmEc
> Wqjc77KEVN5FugzqB6kPpDHBNomEu3Pi0wWz4HuxFwJEq17R0p2ZIUZT5vbfEcbT
> euRpaxprAp6CY/DE/x+u
> =WL4C
> -----END PGP SIGNATURE-----
>
Now this is what I am talking about.  Direct feedback from upstream 
about this process.  I'm happy to see Daniel taking the time to get 
involved and provide his feedback about his project. Thanks for doing that.

And both Daniel and Marek are right, which ever project we decided to 
use for Asterisk is going to be a big _bump_ for the other project.  So, 
like I said before, we should make sure upstream is able and willing to 
work with us in moving Asterisk forward.

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