<div dir="ltr">That's the most sane of the alternatives I've seen ... if it must be renamed.<div><br></div></div><div class="gmail_extra"><br clear="all"><div>--<br>Russell Bryant</div>
<br><br><div class="gmail_quote">On Mon, May 6, 2013 at 12:25 PM, Bakko <span dir="ltr"><<a href="mailto:asannucci@gmail.com" target="_blank">asannucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
maybe a good channel name could be Chan_pjsip, thereby we can know that the new channel use pjsip stack (if i understand correctly).<br>
<br>
Regards<br>
<br>
<br>
El 06/05/2013 11:08, Matthew Jordan escribió:<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/06/2013 04:37 AM, jg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Compared with Mitsubishi's "Pajero" disaster<br>
(<a href="http://en.wikipedia.org/wiki/Mitsubishi_Pajero" target="_blank">http://en.wikipedia.org/wiki/<u></u>Mitsubishi_Pajero</a>), "gulp" seems to be<br>
harmless.<br>
<br>
Nevertheless, why not use a conservative approach and keep chan_sip and<br>
introduce a naming scheme for deprecated and obsolete channels, that<br>
could be used for overhauled channels in the future as well? After all,<br>
if for some reason the old tech cannot be abandoned, a variable can be<br>
used to dispatch the real name to centralize the channel selection.<br>
<br>
jg<br>
<br>
</blockquote>
I would caution against any approach that attempts to use "SIP" to refer<br>
to the new channel driver.<br>
<br>
1) Without major changes to Asterisk's channel core, it precludes<br>
running both chan_sip and chan_gulp simultaneously. The ability to run<br>
both together is of major benefit.<br>
<br>
2) With major changes to Asterisk's channel core, it will easily lead to<br>
confusing situations where someone intends to use chan_sip and instead<br>
gets chan_gulp. Those bug reports will not be fun. In addition, any<br>
'sharing' of technology prefix will inevitably add more complexity and<br>
risk to something that is already a major change.<br>
<br>
I'm perfectly fine with a name change and I'm agnostic as to what is<br>
chosen, but I think the two channel drivers need to be distinct. That<br>
implies at a minimum:<br>
* Different channel technology identifiers in the dialplan<br>
* Different prefixes for CLI commands<br>
* Different configuration file names<br>
<br>
Matt<br>
<br>
</blockquote>
<br>
<br>
--<br></div></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br></div>