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

[Olle E. Johansson]

12 okt 2012 kl. 20:44 skrev Mark Michelson <mmichelson at digium.com>:

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

Thanks for the explanation, I wasn't aware that the DPMA interacted with
SIP in this way (and I still don't understand why a phone needs to interact
with the driver that way).

/O