[asterisk-dev] Time to rename chan_gulp?

[Olle E. Johansson]

29 apr 2013 kl. 17:39 skrev Matthew Jordan <mjordan at digium.com>:

> 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.
Yes, there is no reason to base something new on a poor architecture.
The peers/users/friends doesn't belong in SIP and should be abandoned.
We've been patching it so much that even if it made sense to someone
at start it no longer makes any sense at all.

> 
> 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.
Both works for me. But neither will hopefully be complete as there should
be no 1-to-1 mapping. A new channel driver should be new, fresh
and start with new bugs instead of inheriting the old ones. ;-)

/O
> 
> 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
> 
> 
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev