I can't see how a little addon to chan_sip would break asterisk's architecture. Though being a multi protocol platform, asterisk has a lot of protocol specific features. None of them breaking the concept. I do not suggest to replace asterisk's traditional cause codes, but to add the possibility to set more specific protocol specific codes when needed.<br>
<br>I still remember discussions about this and I also remember that I was not the only one requesting that feature. Sorry for being so persistent on this one.<br><br>Anyway. You suggested another approach to achieve that goal. Do you think it's realistic? I am not sure if I understood it right, but wouldn't custom codes break compatibility with other channel drivers?<br>
<br>Marcus<br><br><div class="gmail_quote">On Fri, Sep 11, 2009 at 11: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;">
<br>
11 sep 2009 kl. 11.10 skrev Marcus Hunger:<br>
<div class="im"><br>
> Unfortunately, 13140 does not allow the user to set it's sip-hangup-<br>
> cause in the dialplan, nor does it pass the original hangupcause to<br>
> the master-chansip.<br>
><br>
> Do you think, it would be a good idea to create a patch so that<br>
> chansip uses SIP_CAUSE to generate a cause for a hangup?<br>
<br>
</div>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>
/O<br>
<br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
AstriCon 2009 - October 13 - 15 Phoenix, Arizona<br>
Register Now: <a href="http://www.astricon.net" target="_blank">http://www.astricon.net</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/mailman/listinfo/asterisk-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dipl.-Inf. (FH)<br>Marcus Hunger - <a href="mailto:hunger@sipgate.de">hunger@sipgate.de</a><br>Telefon: +49 (0)211-63 55 55-61<br>Telefax: +49 (0)211-63 55 55-22<br><br>sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf<br>
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois<br>Steuernummer: 106 / 5724 / 7147, Umsatzsteuer-ID: DE219349391<br><br><a href="http://www.sipgate.de">www.sipgate.de</a> - <a href="http://www.sipgate.at">www.sipgate.at</a> - <a href="http://www.sipgate.co.uk">www.sipgate.co.uk</a><br>