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

[Daniel Pocock]

On 13/11/12 16:23, Matthew Jordan wrote:
> On 11/13/2012 09:00 AM, Joshua Colp wrote:
>> Daniel Pocock wrote:
>>
>> I think resiprocate is awesome, and it certainly does help with
>> packaging and distribution but we can't lose sight that we have to use
>> the stack, make it easy for community members to develop using it, and
>> make a new SIP channel driver.
>>
>> Asterisk has really primarily been written in C. I would go so far as to
>> wager that the vast majority of our community members don't know C++
>> that well and don't feel comfortable with it. I have to admit though,
>> there have been a few modules written in C++ but those have essentially
>> fallen to the sidelines in recent times.
>>
>> My fear if we chose resiprocate is that the number of individuals who
>> would actively contribute to this project would dwindle to virtually
>> nothing since the burden to participate has just gone up a considerable
>> amount. This would carry over to people who want to extend the
>> functionality in the future. You need to know both C and C++. Of course,
>> we could write a C API over the C++ API but then we'd have something
>> else we would have to maintain and extend in the future as resiprocate
>> continued to be developed. Is that worth it? It also makes me wonder if
>> this could actually be achieved in the time frame required if my fear
>> comes true.
>>
>> What do others think? Am I blowing this out of proportion? As someone
>> who has been around for many years, talked to contributors, seen
>> patches, etc, that's my personal opinion.
>>
>> Tradeoffs, tradeoffs, tradeoffs.
>>
> 
> I don't see writing an API wrapper as a trivial effort.  There are
> OO/C++ idioms (inheritance, templates, etc.) that a good C++ library
> will enforce on its users that require careful thought when managed by a
> C API wrapper.
> 
> For example, in reSIProcate both TransactionUserMessage and SipMessage
> inherit from TransactionMessage (I'm ignoring the Message object at this
> point).  Let's assume for a second that we have to expose both of these
> objects through the C API. There's a number of design decisions to work
> through - do we treat them as a separate C objects with no relationship
> (thereby breaking the explicit inheritance relationship), and duplicate
> the common elements?  Do we put a separate TransactionMessage struct as
> the first element in the corresponding structs, giving us
> "pseudo-inheritance" and the ability to map a
> TransactionUserMessage/SipMessage down to a TransactionMessage?
> 
> These kinds of decisions will change how consumers of the facade
> interact, and will require careful thought.  Doing this 'organically'
> will only result in yet another SIP stack with a poor layer of abstraction.
> 
> (And this doesn't even get into templates and mapping void * to type
> safe objects)
> 
> It is certainly not impossible, but I really don't think this is a point
> to trivialize.  Beyond the difficulty involved, there is a certain
> amount of object management and translation that such a façade would
> have to provide that would not be required from a C SIP stack.  This
> does increase the technical burden - and the time involved in making
> said stack usable in Asterisk.
> 

I agree this is not a trivial thing and I didn't comment on it before
because I don't know the Asterisk internals or architecture strategy in
detail

If the channel driver is meant to be very self contained, then it is
probably more achievable.  If there is a lot of low level interaction
between the channel driver and other parts of the Asterisk system, then
I suspect there will be more effort.

That said, another project I contribute to is Ganglia, it has a dlopen
based mechanism for loading modules/plugins, much like in Asterisk.  The
core gmond agent is C, just like Asterisk.  Several people are
successfully building C++ modules that link with it, just exposing their
metrics using the expected C API.  There are many other projects that
have evolved the same way.  Having some C++ code doesn't prevent people
from contributing to other parts of a project, it is a question for the
people involved.

It may be possible to approach this problem from another angle, for
example, integrating with the TURN client code before attempting to work
with the full SIP stack.  The TURN client code is independent of the SIP
code.