[asterisk-dev] Potentially naughty patch

[Scott Griepentrog]

I like that idea.  A value >128 means a SIP code, and <128 means an ISDN
code, and you can then use the original native code or translate to the
desired range by using a to_sip() or to_isdn() function.

Or would it create inconsistencies that would break customer's solutions?


On Tue, Oct 29, 2013 at 11:21 AM, Tilghman Lesher <tilghman at meg.abyt.es>wrote:

> On Tue, Oct 29, 2013 at 10:43 AM, Olle E. Johansson <oej at edvina.net>
> wrote:
> >
> > 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:
> >>> 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.
>
> Speaking historically, we could just have easily chosen SIP cause
> codes as the internal representation.  Or we could have made up our
> own.  For that matter, if the issue is backwards compatibility to
> ISDN, then using values in the 128+ range would make sense, possibly
> enjoining the ISDN driver from sending those codes directly.  Assuming
> that you wouldn't want to ever send a SIP cause code lower than 128,
> using the SIP cause code directly in this field (it is, after all, a
> full integer) may be preferable.  If you would need to send lower
> values, however, then multiplying the SIP cause code by a certain
> factor (say 1,000) may be sufficient.  Changes would need to be made,
> though, to ensure that other areas of Asterisk do not assume that the
> value will fit within a single 8-bit field.
>
> -Tilghman
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
[image: Digium logo]
*Scott Griepentrog*
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com <http://www.digium.com> ·
http://asterisk.org <http://www.asterisk.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131029/ede03821/attachment-0001.html>