<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 29, 2013 at 5:23 PM, Scott Griepentrog <span dir="ltr"><<a href="mailto:sgriepentrog@digium.com" target="_blank">sgriepentrog@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div style="color:rgb(102,0,0)">An in the long run that's probably a lot easier.  But not as cool. ;-)</div>
</div><div class=""><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 3:54 PM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div>On 29 Oct 2013, at 20:38, Scott Griepentrog <<a href="mailto:sgriepentrog@digium.com" target="_blank">sgriepentrog@digium.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr"><div style="color:rgb(102,0,0)">One I totally commiserate with... ;-)</div><div style="color:rgb(102,0,0)"><br></div><div style="color:rgb(102,0,0)">
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.</div>

</div></blockquote></div>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.</div><div><div>
<div><br></div><div>/O<br></div></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div style><snip></div><div style><br></div><div style>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.</div>
<div style><br></div><div style>(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.</div>
<div style><br></div><div style>(2) Looking at the table on the Asterisk wiki - <a href="https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings">https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings</a> - 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.</div>
<div style><br></div><div style>(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.</div>
<div style><br></div><div style>(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.</div>
<div style><br></div><div style>So what I've been thinking about is something like this:</div><div style><br></div><div style>(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.</div>
<div style><br></div><div style>(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.</div>
<div style><br></div><div style>(3) Using Sorcery, allow configuration files to override the tables. So you could use something like:</div><div style><br></div><div style>[sip_core]</div><div style>type=sip</div><div style>
404=3</div><div style>...</div><div style><br></div><div style>[core_sip]</div><div style>type=sip</div><div style>3=404</div><div style>...</div><div style><br></div><div style>[pjsip_core]</div><div style>type=pjsip</div>
<div style>404=3</div><div style>...</div><div style><br></div><div style>[core_pjsip]</div><div style>type=pjsip</div><div style>3=404</div><div style>...</div><div style><br></div><div style>[motif_core]</div><div style>
type=motif</div><div style>general-error=20</div><div style>...</div><div style><br></div><div style>And now things go a bit further:</div><div style><br></div><div style>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".</div>
<div style><br></div><div style>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. </div>
<div style><br></div><div style>Matt</div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>