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

Tue Nov 13 12:57:25 CST 2012

On 13/11/12 19:10, Russ Meyerriecks wrote:
> On Tue, Nov 13, 2012 at 07:28:08PM +0200, Faidon Liambotis wrote:
>> On 11/13/12 18:40, Matthew Jordan wrote:
>>> So let's just say that having the SIP stack as a separate package is a
>>> highly desirable attribute for package maintainers, and that should
>>> receive sufficient weight when making a decision.
>>
>> Forking & embedding libraries within your project hurts free software
>> and hurts the community. It's a very uncathedral (and uncommon in this
>> world) way of running a project and shows that the project cares more
>> about retaining control than contributing back to the community and its
>> work that is based upon.
>>
> I don't know if any of this applies to the distribution model but as a kernel
> developer, this is almost exactly the kernel's development process.
> 
> Most distributions fork the linux kernel, add their own patches, release their
> own kernel, then submit patches back upstream. This has led to a very healthy
> ecosystem for the kernel. I guess I just don't see why this wouldn't work
> userspace libraries as well.

Although the process is similar, there are big differences in the impact

For example, if an upstream kernel is released with a security fix, each
distribution has to re-apply patches and rebuild their kernels, this is
taken for granted

But imagine if that is a user space library embedded in 50 different
packages in Debian, another 30 packages in Fedora, etc.  That is a lot
of code that needs rebuilding.  It is even more painful if the libraries
are all forked at different places and there is no easy way to apply the
patch.

This is why distributions draw a line in the sand with this issue.

>> And besides this giving you a bad community karma
> Why? If relavant patches are posted back upstream, everybody benefits. Also,
> any asterisk specific cruft is left out.

I accept that Digium has good intentions of passing patches upstream.

What Faidon is suggesting though is that Digium, as leaders in the
deployment of SIP, need to be actively involved in the upstream library
of your choice, collaborating with other users of the library to commit
the patches in a way that is good for the wider community and not just
doing the minimum that is necessary for Asterisk and throwing the patch
to somebody else to integrate.

If you just send a patch upstream, and don't invest the time to
integrate it, make it work for users other than Asterisk, etc, then
don't assume other people will invest that effort.  Your code will
eventually diverge.  This also means more effort for you keeping track
of patches/upgrades from upstream - and eventually they will start
conflicting with your own code.

>> I do believe it results in a technically inferior solution, for the same
>> reasons a closed source development model results in inferior results than an
>> open source one.
> Why is it technically inferior? It's been identified that:
> 
> 1) User experience is a big deal. Asterisk devs would like to keep the
> time-to-patch minimal.

This is another reason for Asterisk developers to become involved in an
upstream project - whether you start a pjsip spin-off of your own, or
whether you join reSIProcate, you would be able to tag a release when it
is necessary to do so.

If you are not `in' the project, and you just send patches, then I agree
they won't get released as quickly as your users need them.

Ultimately, if upstream releases a security fix, your code has diverged,
upstream's patch conflicts, it takes you longer to integrate, test and
release.  So the approach you propose can actually make things slower.

> 2) Asterisk only needs the sip stack bit of of an external library, not any
> other surrounding layers.

I'm not sure this is an issue with any of the products mentioned.  E.g.
I've never used the reSIProcate TURN client, I've never modified that
code, but the presence of that code in the tree doesn't impact my work
with other parts of the library.

The Debian packages are split: so if somebody installs resiprocate as
part of Asterisk, they won't automatically have the repro package using
up disk space too.  If they want that, they install it separately.

> 3) Asterisk may need to modify the sip stack in non-standard ways, in order to
> be compliant with non-standard devices. (to enhance user experience)

This was my first experience of contributing to reSIProcate: supporting
non-standard URIs from Cisco devices, and supporting the SER format of
nonce in DIGEST.  Rather than hacking a fix that everybody else would
have screamed about, I submitted generalized solutions:

http://list.resiprocate.org/archive/resiprocate-devel/msg03409.html
 (officially, # should be encoded in a Uri, but some Cisco devices don't
like that)

http://list.resiprocate.org/archive/resiprocate-devel/msg03373.html

The resiprocate stack is built on nice object oriented code that is
quite good for this type of approach, as the NonceHelper and it's
subclasses demonstrate:

https://svn.resiprocate.org/viewsvn/resiprocate/main/resip/stack/NonceHelper.hxx?view=markup

> These points in mind, it seems like modifying and embedding an existing sip
> stack would be technically superior?
> 

Those are valid points, but I feel that I've demonstrated that they
don't have to lead to the same conclusion that you reached.

It really is important to think about the wider community of SIP users
and developers out there.  Having a strong SIP stack used by many
projects will greatly boost compatibility between products, which is
absolutely essential if we are not all going to be squashed by Microsoft
with their Skype/Lync monopoly.  You can already see them merging MSN
into Skype, and cutting off Asterisk.  They must have been rubbing their
hands in glee when they saw this:

http://fsfe.org/news/2012/news-20120920-01.en.html

This is an area where the Digium and Asterisk community can show some
leadership, whether you choose reSIProcate or not doesn't bother me so
much, but I would strongly urge you not to choose an embedded version of
any product.

If you can't control an upstream product the way you want to, then
please release a fork of the product under a new name rather than
embedding it.  This is a healthy approach that won't upset anybody in
packaging.