[asterisk-dev] Potentially naughty patch

[Olle E. Johansson]

On 29 Oct 2013, at 17:21, 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.

That is indeed an interesting concept. Good food for thought.

We could also implement a channel interface function that asks for a specific format and implement
the translation in the core. Somehow I loose too much information in SIP -> ISDN -> SIP conversions
in most of my calls and I need to get rid of that. I am patching to get around instead of fixing the
real problem.

Your idea may be a good way forward.


/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/ca0c8726/attachment-0001.bin>