[asterisk-dev] Time to rename chan_gulp?

[Matthew Jordan]

On 04/29/2013 08:01 AM, Steve Totaro wrote:
> 
> 

<snip>

> Totally whacky idea, but why not set a variable in sip.conf in the
> general section, the 'peer' or whatever section (allow= or use=, maybe) 
> 
> I haven't been following it, but is the end goal to have one sip channel
> driver all merged together in the end.
> 
> Maybe I am way off base, but could and would it make sense for endpoints
> to negotiate as they would a codec?
> 
> I would much prefer "fixing" depricated .conf files directly related to
> the channel driver, such as sip.conf than to have to much around in
> dialplan when the time comes.
> 
> Again, I may be talking out of turn, just ideas from my understanding of
> "What it was, what it is, and what it shall be."
> 

Actually, the idea of being able to 'share' sip.conf with both channel
drivers was one of the driving factors in the creation of the new data
abstraction layer in Asterisk (sorcery). As it turned out, there's a lot
of subtle difficulties in getting this to work.

1. The sip.conf schema - to put it a bit mildly - stinks. Getting it to
map to actual SIP concepts (user agents, AORs, etc.) is non-trivial.

2. Having the new SIP channel driver consume sip.conf would preclude
running both channel drivers simultaneously. While you could conceive of
some attributes that would allow this to work, it - again - turned out
to be relatively non-trivial and subject to error.

I think we're leaning more towards one of two solutions to help with a
migration:
1. Add a CLI command to let users dump an existing sip.conf
configuration into a new SIP channel driver format.
2. Add a tool that will perform the conversion for you outside of Asterisk.

I'm open to suggestions/flames on any approach here.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org