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

[Tilghman Lesher]

On Tue, Nov 13, 2012 at 4:37 PM, Daniel Pocock <daniel at pocock.com.au> wrote:
> 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.

Actually, in many cases, the reason to use RHEL is the support for
hardware that the Debian project refuses to allow in their kernel.
So, sure, it might boot... and then refuse to mount the filesystem,
because it doesn't know anything about that disk controller.

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

Precisely my point.  Faidon's examples were explicitly contrived in
order to support his point, but modify the examples slightly, and it
all falls down.

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

Those are usually packaged as preprocessor code, not hacks to be
turned on in the API.  If that's the way it's packaged, guess how it
will likely appear in any distribution?

-Tilghman