<div dir="ltr">Thank you very much for the information Mathew,<div>  We've planned to upgrade our plataform's asterisk version to ast11 in 2016.</div><div><br></div><div>  For this case I've ended up figuring some of your pointer out, I was reaching the code for 603 Declined, where the sip driver would send the BUSY signalling forward using "ast_queue_control(p->owner, AST_CONTROL_BUSY);", what I did was check if the reason arrived via de Q850 "Reason" header, and if it was in a pre-defined range, if so then I used the method you mentioned "ast_queue_hangup_with_cause(p->owner, owner->hangupcause);".</div><div>  This way I ended up with the hangup code I wanted on the HANGUPCAUSE variable in the dialplan and then I used the "UserEvent" app to tell my AMI application about it.</div><div><br></div><div><font face="monospace, monospace" size="1">...</font></div><div><div><font face="monospace, monospace" size="1"> <span class="" style="white-space:pre">                               </span>case 603: /* Decline */</font></div><div><font face="monospace, monospace" size="1"> <span class="" style="white-space:pre">                                        </span>if (p->owner) {</font></div><div><font face="monospace, monospace" size="1"> <span class="" style="white-space:pre">                                             </span>sip_handle_cc(p, req, AST_CC_CCBS);</font></div><div><font face="monospace, monospace" size="1">-<span class="" style="white-space:pre">                                             </span>ast_queue_control(p->owner, AST_CONTROL_BUSY);</font></div><div><font face="monospace, monospace" size="1">+<span class="" style="white-space:pre">                                               </span>if (resp == 603 && usedQ850 == 1 && owner->hangupcause >= 123 && owner->hangupcause <= 126) {</font></div><div><font face="monospace, monospace" size="1">+<span class="" style="white-space:pre">                                                       </span>ast_queue_hangup_with_cause(p->owner, owner->hangupcause);<br></font></div><div><font face="monospace, monospace" size="1">+<span class="" style="white-space:pre">                                              </span>} else {</font></div><div><font face="monospace, monospace" size="1">+<span class="" style="white-space:pre">                                                        </span>ast_queue_control(p->owner, AST_CONTROL_BUSY);</font></div><div><font face="monospace, monospace" size="1">+<span class="" style="white-space:pre">                                               </span>}</font></div><div><font face="monospace, monospace" size="1"> <span class="" style="white-space:pre">                                      </span>}</font></div><div><font face="monospace, monospace" size="1"> <span class="" style="white-space:pre">                                      </span>break;</font></div><div><font face="monospace, monospace" size="1"> <span class="" style="white-space:pre">                         </span>case 482: /* Loop Detected */</font></div></div><div><font face="monospace, monospace" size="1">...</font></div><div><br></div><div>  I've used the 123 to 126 range that is not defined in the ISDN cause codes, so I think it wont get in the way of any other behavior.</div><div><br></div><div>Thanks again for your attention! Great piece of software.</div><div>Att.</div><div>Gabriel Ortiz</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-02 19:46 GMT-02:00 Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Dec 1, 2015 at 3:00 PM, Gabriel Ortiz Lour <span dir="ltr"><<a href="mailto:ortiz.admin@gmail.com" target="_blank">ortiz.admin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div dir="ltr">Hi all,<div><br></div><div>  Having trouble with understanding how chan_sip relates with chan_local. I know I'm using a very old asterisk version (1.8.19.0) but here is what I'm trying to do:</div><div><br></div><div>  I'm using "use_q850_reason" to transport de HANGUPCAUSE from one * box to another, as I can see in the 2nd * log:</div><div><br></div><div>">> Using Reason header for cause code: 50"<br></div><div><br></div><div>This number (50) came from the HANGUPCAUSE i've set on the 1st * box.</div><div><br></div><div>The thing is that I used the AMI to generate a call using a Local channel, and I would like to receive that number in the "Reason" field of the OriginateResponse, so I would know the HANGUPCAUSE of the 1st * box.</div><div><br></div><div>The problem is that the SIP channel in the case is never answered, I'm fighting with the code on chan_sip function "handle_response" and in the channel.c "__ast_request_and_dial", but I can't find where the two channels relate, where to get the "50" that I need...!</div><div><br></div><div>Anyone could help me with some pointers on that?</div><div><br></div></div></blockquote><div><br></div></span><div>You can't reach across channels from one channel driver to another in any kind of safe fashion. That is, code in chan_sip cannot call or set code in chan_local directly.<br><br></div><div>If one channel needs to inform another channel about some piece of information, then it needs to do so using one of the built-in mechanisms that pass information between channels. In your version, you're best off modifying the control frame AST_CONTROL_HANGUP to pass the chan_sip specific Reason code along with it. You'd do something like the following:<br></div><div>* Update ast_queue_hangup_with_cause to have a new reason parameter set by chan_sip, and pass not just the hangup cause code but also the reason code along with it. That would make f.data point to a structure containing both cause codes, and have the datalen value be set in the frame to the size of the struct.<br></div><div>* Update everyone who handles AST_CONTROL_HANGUP and extracts the cause code out of it to get it from the new structure<br></div><div>* Update the origination routines to extract the Reason code out of its handling of AST_CONTROL_HANGUP<br><br></div><div>That's probably your best path, anyway. It's important to note that another way of doing this was implemented in Asterisk 11. There's a separate control frame that handles cause code information that all channel drivers can use to pass that information along to the core, and potentially further if desired. That mechanism has a reasonable amount of work associated with it, so it wouldn't backport well. If, however, Asterisk 11 is an option, you may want to look into that functionality. The control frame that handles cause code propagation (which could reasonably be extended for more information) is AST_CONTROL_PVT_CAUSE_CODE.<span class="HOEnZb"><font color="#888888"><br></font></span></div></div><span class="HOEnZb"><font color="#888888"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></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></div>
</font></span></div></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>