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

[Daniel Pocock]

On 13/11/12 23:23, Tilghman Lesher wrote:
> On Tue, Nov 13, 2012 at 12:47 PM, Faidon Liambotis <paravoid at debian.org> wrote:
>> On 11/13/12 20:10, Russ Meyerriecks wrote:
>>> 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.
>>
>> Not at all. Linux is not a good comparison but since you've driven the
>> argument there:
>>
>> Among all forks of the kernel, there are no differences in userspace
>> API/ABI. Can I take a stock kernel and run it on my Debian system? Sure.
>> Can I write an application on my Debian system and expect it to work
>> (both as a source and a binary) in a RHEL system/kernel? Sure.
>>
>> Will I able to compile Asterisk against a stock pjsip? Unlikely.
> 
> Can you take a Debian kernel and run it on a RHEL system?  Unlikely.
> How about a Red Hat Enterprise package and run it on Debian?  Probably
> not without significant modifications.

Sorry to knock you on this one... but you can actually boot a RHEL
system with a Debian kernel.  Of course there may be one or two apps you
have in RHEL that expect particular kernel features, but many things
should run if you just copy the kernel file.

`alien' lets you install packages from RHEL on Debian.  If the
corresponding libraries are present, things work.  There may be things
that don't work if they depend on a really specific library version or a
hard coded file location.


>>> 2) Asterisk only needs the sip stack bit of of an external library, not any
>>> other surrounding layers.
>>
>> And what's the point then? No-one is forcing you to use 100% of all API
>> calls of a library.
> 
> Because the SIP stack is likely going to need to be modified beyond
> what the stock library provides.  The library provides a starting
> point, but it is not completely sufficient to meet the end goals of
> the applicaiton.

But why can't people make those modifications directly to the upstream
project?

If some things are Asterisk-specific, why not generalise the upstream
code, e.g. by adding callbacks to the application, instead of just
embedding Asterisk code into the SIP library?

Here is a classic example of where I took this approach with a smaller
project (dynalogin and HOTP/oath toolkit):
http://lists.nongnu.org/archive/html/oath-toolkit-help/2011-01/msg00007.html
- originally I had a copy of the library code embedded in dynalogin, but
by working with upstream, I was able to get callbacks for everything I
needed.

With C++ code it is even easier of course, as the code that you want to
hack is usually intended to be subclassed.

>>> 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)
>>
>> Is this need to support non-standard devices unique to Asterisk? I don't
>> think so, quite the contrary. How is "shared library" and "never
>> deviates from the standard" synonymous?
> 
> It is not, but as argued before, many libraries will refuse patches
> based upon implementation bugs in other hardware.  Interop is improved
> by such patches, but many projects (including Debian, I might add)
> value purity over interop.

Not at all - as long as the hacks can be turned on and off in the
library API it is usually quite acceptable.