[asterisk-dev] [Asterisk 0014810]: [patch] channel-specific hangupcauses

[Tim Ringenbach]

On Fri, Sep 11, 2009 at 4:29 AM, Olle E. Johansson <oej at edvina.net> wrote:

> It would certainly break most of Asterisk's architecture, make CDRs
> hard to parse and cause havoc in the internal bridges.
>
> Do remember that we're a multiprotocol platform. The cause codes needs
> to correlate. You can't set one cause code in a channel driver and
> have a totally different one in the bridge to the other side, which
> might use a totally different channel driver.
>
> What we can do is open up the translation tables between SIP and ISDN
> causes and add some custom codes that you can configure for your own
> use. That would be a bit more clever approach.
>
> Sorry for being harsh, but this has been discussed many times and I am
> still afraid of opening up this pandora's box. The multiprotocol
> architecture is a foundation for Asterisk's success story. If we start
> breaking it apart by allowing too much protocol specific stuff into
> the core, like the dialplan, we're not multiprotocol any more. There
> are many platforms out there that are single protocol. Many of them
> being replaced with a multiprotocol engine like Asterisk ;-)
>
>
Isn't using ISDN cause codes in the core already sort of allowing protocol
specific stuff into the core?

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.

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.

That way you have multiprotocol flexibility with single protocol power and
control.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090912/c61bb4c8/attachment.htm