<div class="gmail_quote">On Fri, Sep 11, 2009 at 4:29 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net">oej@edvina.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It would certainly break most of Asterisk's architecture, make CDRs<br>
hard to parse and cause havoc in the internal bridges.<br>
<br>
Do remember that we're a multiprotocol platform. The cause codes needs<br>
to correlate. You can't set one cause code in a channel driver and<br>
have a totally different one in the bridge to the other side, which<br>
might use a totally different channel driver.<br>
<br>
What we can do is open up the translation tables between SIP and ISDN<br>
causes and add some custom codes that you can configure for your own<br>
use. That would be a bit more clever approach.<br>
<br>
Sorry for being harsh, but this has been discussed many times and I am<br>
still afraid of opening up this pandora's box. The multiprotocol<br>
architecture is a foundation for Asterisk's success story. If we start<br>
breaking it apart by allowing too much protocol specific stuff into<br>
the core, like the dialplan, we're not multiprotocol any more. There<br>
are many platforms out there that are single protocol. Many of them<br>
being replaced with a multiprotocol engine like Asterisk ;-)<br>
<br></blockquote></div><br>Isn't using ISDN cause codes in the core already sort of allowing protocol specific stuff into the core?<br><br>A user editable translation table might be useful in some circumstances but it seems like a lot more way to accomplish what was asked for. <br>
<br>Why not just let the user specify the hangup cause in whatever protocol specific format they want? The channel drivers already have code to translate that into ISDN codes or ISDN codes to protocol specific. You could add function pointers to ast_channel_tech to expose that translation functionality to the core. The hangup cause then becomes a struct with both protocol specific and protocol neutral hangup causes, and channel drivers ultimately call something like ast_hangup_cause_translate(cause, "SIP") that returns the native version if it's in SIP, otherwise takes the neutral version and translates it to SIP and returns it.<br>
<br>That way you have multiprotocol flexibility with single protocol power and control.<br>