[asterisk-dev] Potentially naughty patch

[Olle E. Johansson]

On 29 Oct 2013, at 15:33, Tilghman Lesher <tilghman at meg.abyt.es> wrote:

> On Tue, Oct 29, 2013 at 4:01 AM, Olle E. Johansson <oej at edvina.net> wrote:
>> I have a branch that makes it possible to add custom mappings to the isdn
>> cause code to SIP codes table in chan_sip - and the opposite ones.
>> 
>> In order to a fine grained control I may want a cause code to send a very
>> specific SIP message, maybe even a custome one. And in some cases I want to
>> translate a specific SIP code to the same without affecting other calls in
>> sip2sip situations.
>> 
>> My solution was to add five custom codes to the cause table - custom1 to
>> custom5 in the range 115-119 that is not used as far as I can tell.
>> 
>> This solved the problem we worked on and also added the benefit of being
>> able to run "hangup(118)" on a SIP call to generate "498 IAX2 not supported"
>> in the SIP channel.
>> 
>> The questions are:
>> - is this too dangerous, to grab some ISDN cause codes?
>> - will it have side effects?
>> - what will other channels do if they get a hangup(119) ?
>> 
>> All of this is of course a bit dangerous and have to be used only by
>> experienced asterisk admins, but is something that have been asked for for a
>> long time. There is nothing stopping you from redefining any cause code to
>> 401, 180 or something else, like 302. But that will hurt...
> 
> The only thing I fear from such a change is that it will lead to a
> support nightmare if any of the cause codes that you've appropriated
> are eventually used in another way by the ITU.  Since that's the
> standards body involved with the definition of ISDN, I'd suggest that
> you obtain from them an assurance that such cause codes land in a
> "reserved" or "vendor-defined" state, to avoid this potential
> future-compatibility issue.  It also creates a potential future issue
> within Asterisk, whereby if the lowest cause code is allocated, and
> that custom code needs to be moved, then there will be an issue with
> "custom1" being assigned to a different integer on two different
> versions of Asterisk.  This only potentially matters when the cause
> code is transmitted externally, as we might in the ISDN driver.

Noted.

Eventually I want a core that is not based on ISDN anymore. But that's another story.

Thank you for your feedback, Tilghman!

/O
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2374 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131029/4df26460/attachment.bin>