[asterisk-dev] Potentially naughty patch

[Olle E. Johansson]

On 29 Oct 2013, at 15:31, Mark Michelson <mmichelson at digium.com> wrote:

> On 10/29/2013 04:01 AM, Olle E. Johansson wrote:
>> Friends,
>> 
>> I did something that may cause issues today, but solved a lot of issues. I need your feedback on this.
>> 
>> 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?
> 
> I think that if those values have not been allocated by now, they aren't going to be. It's probably fine to make use of them for your own benefit.
You mean that ISDN is dead? ;-)
> 
>> - will it have side effects?
> 
> As long as you're within the valid range for a Q.850 cause code (which I believe is 7 bits), then there shouldn't be side effects directly from stealing those values.
Agree.
> 
>> - what will other channels do if they get a hangup(119) ?
> 
> This is the interesting question. I did a brief search of channel drivers and I found two different behaviors:
> 1) The Q.850 cause code is sent as-is
> 2) The Q.850 cause code is translated into a channel-specific value.
> 
> For case 1, you could have issues with far-end equipment if they do not understand the cause code. I, however, have no direct knowledge of what sort of equipment might have such issues. For case 2, usually channel drivers will have some default to use if the given cause code is unknown.
Yep. But all of this is dangerous and users should test, test, test. And know what they're doing.
> 
>> 
>> 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...
>> 
> 
> In a controlled environment where you are aware of the equipment that you are communicating with, the change you have made would probably not cause trouble. I would recommend performing tests against public ISDN networks and other equipment to be sure that sending unallocated cause codes does not cause a problem for them     though. I would not recommend this code change as a general improvement to open source Asterisk, though, but you probably already knew that :) 

Funny enough Matt asked for this code to be incorporated. You guys need to talk. :-) 
It solves a lot of interop issues we all have in various platforms. Like the famous 403/603 stuff.

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