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

[Marek Cervenka]

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.

-- 
---------------------------------------
Marek Cervenka

=======================================