[asterisk-dev] Time to rename chan_gulp?
Olle E. Johansson
oej at edvina.net
Mon Apr 29 08:13:08 CDT 2013
29 apr 2013 kl. 15:01 skrev Steve Totaro <stotaro at totarotechnologies.com>:
>
>
>
> On Mon, Apr 29, 2013 at 6:09 AM, Olle E. Johansson <oej at edvina.net> wrote:
> Friends,
>
> Now that gulp/pimp_my_sip is merged I think it's time to abandon the funny names and find a more long term solution for the channel name and the dial string identifier. I see no reason to deprecate SIP for chan_sip - I would encourage people running both channels while testing and while the new channel driver is getting stable and up to par. Having to switch between them doesn't make sense when you can run one on 5060 and another on 5080 or something similar.
>
> Just to start the discussion I propose that we rename the driver to chan_sipng
>
> and that the identifier in the dial strings become SIPNG/xxxx
>
> /O
> --
>
>
> 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)
Not possible.
>
> I haven't been following it, but is the end goal to have one sip channel driver all merged together in the end.
That will take many releases.
>
> Maybe I am way off base, but could and would it make sense for endpoints to negotiate as they would a codec?
By selecting a port, yes.
>
> 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.
You can already use global variables as a prefix instead of hard coding "SIP/" or "SIPNG/".
I would hope that the dial strings and configurations are not fully compatible. Forcing a new implementation to follow the old one would mean
less progress than we should really have, considering the broken configuration of the current chan_sip.
We can surely implement scripts to help migration, but that's another issue.
>
> 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."
Thanks for the open brainstorm :-)
Sorry to be negative...
/O
>
> Thanks,
> Steve T
>
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130429/8e4ce012/attachment.htm>
More information about the asterisk-dev
mailing list