[asterisk-dev] Potentially naughty patch

Tue Oct 29 14:38:49 CDT 2013

One I totally commiserate with... ;-)

What I was envisioning though is a "wrapper" function which would translate
the existing value into the required format.  So you would have to do a
search/replace and wrap each reference to the error code with the
error_to_isdn() function so that everything still works correctly.  The
references in sip code could then use error_to_sip() instead, and in both
cases you set the error based on what you have (isdn or sip).  Kinda like
ulaw/alaw translation, you save what you have, and translate it from what's
there to what you need if you need to.  Difference being that since the
values don't overlap, the value also tells you if it's in ISDN or SIP.  I
think it's totally doable - and would then resolve the issue of certain SIP
error codes getting lost in translation to/from ISDN.  Also provides then a
path between SIP & PJSIP.

On Tue, Oct 29, 2013 at 2:21 PM, Olle E. Johansson <oej at edvina.net> wrote:

>
> On 29 Oct 2013, at 19:00, Scott Griepentrog <sgriepentrog at digium.com>
> wrote:
>
> 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?
>
>
> The problem is that we're still a multiprotocol PBX. Switching to SIP may
> hurt other channels
> and be as stupid as ISDN. Now, SIP has more finegrained error codes than
> ISDN, so translation
> will be better for most channels.
>
> I know that I'm contradicting myself. That's an art form you learn as you
> grow older ;-)
> /O
>
>
>
> 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/>
>  --
> _____________________________________________________________________
> -- 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
>
>
>
> --
> _____________________________________________________________________
> -- 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/baeca444/attachment-0001.html>