[asterisk-dev] Potentially naughty patch

[Matthew Jordan]

On Tue, Oct 29, 2013 at 5:23 PM, Scott Griepentrog
<sgriepentrog at digium.com>wrote:

> 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
>>
>
<snip>

So I've spent some time in the past looking at Earl Grey, and thinking
about the best way to implement it in 12+. There's a number of factors that
make the implementation in 12 (and later versions) interesting - and a few
aspects in Asterisk 11 that may be interesting as well.

(1) As Josh mentioned, in Asterisk 11, there is a channel control frame
(AST_CONTROL_PVT_CAUSE_CODE) that conveys channel technology hangup cause
information to the Asterisk core. The benefit of this is that channel
drivers - when being hung up by the technology - have a way to push why
they hung up directly into the core. Currently, that information is just
reported on by the HANGUPCAUSE function, but it could conceivably let
something in the core intercept that cause information and manipulate it.

(2) Looking at the table on the Asterisk wiki -
https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings - the
internal cause codes map directly to IAX and ISDN. Earl Grey makes the SIP
(chan_sip) to internal cause codes configurable; however, that same logic
would be useful to have for XMPP (chan_motif) as well.

(3) In Asterisk 12, we now have chan_pjsip as well. It uses similar hangup
cause mapping routines to chan_sip, which means it could benefit as well
from the logic in Earl Grey. This also lends more thought towards having
hangup cause tables in the Asterisk core being a useful function.

(4) Finally, we now have Sorcery (!). This makes the dynamic realtime (and
general storage) of the cause codes relatively easy, so long as you tie the
internal objects mapping those codes together to Sorcery. That's pretty
handy.

So what I've been thinking about is something like this:

(1) Have a core API that can map technology specific codes to core hangup
cause codes. The initial default mapping values can be provided by the
channel drivers themselves. This core portion should also intercept the
control frame and manipulate it as appropriate, if needed.

(2) This API should provide facilities that channel technologies can query
to get the internal Asterisk hangup cause code given their technology cause
code, and vice versa. Unfortunately, given that we can't really dictate
that everyone use integers, this might have to use string to string
mappings (as XMPP hangup cause codes are strings), but that's not the worst
thing in the world.

(3) Using Sorcery, allow configuration files to override the tables. So you
could use something like:

[sip_core]
type=sip
404=3
...

[core_sip]
type=sip
3=404
...

[pjsip_core]
type=pjsip
404=3
...

[core_pjsip]
type=pjsip
3=404
...

[motif_core]
type=motif
general-error=20
...

And now things go a bit further:

One thing that is potentially cool about this approach is you could
conceivably have multiple configuration mappings for a single channel
driver - that is, you could have one table of mappings for one SIP
endpoint, and another table of mappings for another SIP endpoint. The
channel drivers themselves would have to be a bit "smarter" to make use of
this - you'd have to configure an endpoint/peer/whatever with the table
names it should use - but that's pretty powerful (my SIP trunk gets one set
of code, my SIP peers get another). Honestly, that much flexibility is
probably "bonus points".

As for whether or not such a feature is appropriate for mainline Asterisk:
I don't completely disagree with either Mark or Olle :-)  With this
feature, you could do some incredibly silly and dangerous things - such as
mapping an internal Asterisk hangup cause code to a 3xx SIP response. "You
aren't busy, you're just forwarded!" Eek. This should be one of those
features that no one has to know about or touch to configure Asterisk - and
if you do configure it, you better know what you're doing.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131029/61549bc5/attachment.html>