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

Tue Nov 13 08:17:57 CST 2012

-----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-----