[asterisk-dev] chan_sip exposing global API ???? Why?

[Mark Michelson]

On 10/12/2012 01:51 AM, Olle E. Johansson wrote:
> [svn-commits] mmichelson: branch 11 r374842 - in /branches/11: channels/ include/asterisk/ ...
>
> 11 okt 2012 kl. 17:31 skrev SVN commits to the Digium repositories <svn-commits at lists.digium.com>:
>
>> Don't make chan_sip export global symbols.
>>
> Why is a channel driver exposing global symbols at all? And why is SIP doing that?
>
> I thought everything should go through the tech_pvt interface. Why add a new channel-specific API?
>
> For me, that would break the idea behind the Asterisk Multiprotocol PBX.
> /O
>
First off, chan_sip isn't exposing global symbols any more. That's the
point behind this commit. Now the symbols are provided by the Asterisk
core, with chan_sip registering itself as a provider of those methods
when chan_sip loads.

During development of the DPMA, we ran into the limitations of not
having a specific defined API for chan_sip. There are countless APIs
defined within Asterisk itself that numerous modules implement but these
are all generic common operations. There exists additional functionality
specific to modules that have no overlap and cannot be condensed to a
generic API but that is valuable to expose to external modules.

So why did we do it this way?

First, this is the simplest, most direct way to accomplish the end goal.
We could have made it so that the DPMA calls ast_indicate() and encodes
the necessary data into a custom control frame. This is how things are
done in Certified Asterisk 1.8. We opted not to do this going forward
because going through the rigamarole of attempting to be
protocol-agnostic is pointless when the point of an operation is
obviously SIP specific. The encoding/decoding a frame only serves to
complicate what could otherwise be a simple procedure.

Second, chan_sip is the only place this could go because chan_sip is
monolithic. With other technologies, such as XMPP, we have a res module
that defines protocol operations, and the channel driver is built on top
of that. If chan_sip were built similarly, it would be easy to either
add a new API call to the res module or simply use an existing one. With
chan_sip, we do not have this luxury; if we want to be able to allow for
external driving of SIP, we have to define the operation in chan_sip
itself.

Finally, doing things this way creates a general method for allowing
vendor-specific driving of SIP code. While DPMA is the only
currently-known and supported external SIP driver, this could open the
door for other vendors to be able to use external modules to control
Asterisk's SIP stack.

With all this being said, I'm certainly up for suggestions for ways this
could be done better. If you have suggestions, please make them known.