[asterisk-dev] Potentially naughty patch

Tue Oct 29 17:23:31 CDT 2013

An in the long run that's probably a lot easier.  But not as cool. ;-)

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

>
> On 29 Oct 2013, at 20:38, Scott Griepentrog <sgriepentrog at digium.com>
> wrote:
>
> 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.
>
> Or just add a SIp error code to the channel structure and use both in
> parallell. Each channel MUST provide ISDN and MAY provide a SIP error code
> to get more granularity.
>
> /O
>
>
>
>
> 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/>
>  --
> _____________________________________________________________________
> -- 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/742d7115/attachment.html>