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

[Tzafrir Cohen]

On Tue, Nov 13, 2012 at 12:10:08PM -0600, 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.

And distributions fork Asterisk with their own patches and distributions
fork libgsm with their own patches. However distributions will try to
avoid including two copies of the kernel, of asterisk and of libgsm.

> 
> > 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 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.
> 
> 2) Asterisk only needs the sip stack bit of of an external library, not any
> other surrounding layers.
> 
> 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)

Why are those patches not applicable upstream? If those patches are not
applicable upstream, they may be broken. Have they been properly
reviewed by Upstream?

(Same applies for a patch to chan_dahdi.c not included into Asterisk)

4) Asterisk users need to be sure they get all the patches needed for
the library, even if the problem was only reported on a different
project.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir