[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    Re: [asterisk-dev] SIP channel X Local Channel
From:       Gabriel Ortiz Lour <ortiz.admin () gmail ! com>
Date:       2015-12-04 20:32:30
Message-ID: CAJc6w1NeDLSXFwzZyRqDqqF82WZ0Qwn+de3LXC=dzaJnPpNv5Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Thank you very much for the information Mathew,
  We've planned to upgrade our plataform's asterisk version to ast11 in
2016.

  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);".
  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.

...
  case 603: /* Decline */
  if (p->owner) {
  sip_handle_cc(p, req, AST_CC_CCBS);
- ast_queue_control(p->owner, AST_CONTROL_BUSY);
+ if (resp == 603 && usedQ850 == 1 && owner->hangupcause >= 123 &&
owner->hangupcause <= 126) {
+ ast_queue_hangup_with_cause(p->owner, owner->hangupcause);
+ } else {
+ ast_queue_control(p->owner, AST_CONTROL_BUSY);
+ }
  }
  break;
  case 482: /* Loop Detected */
...

  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.

Thanks again for your attention! Great piece of software.
Att.
Gabriel Ortiz

2015-12-02 19:46 GMT-02:00 Matthew Jordan <mjordan@digium.com>:

>
> On Tue, Dec 1, 2015 at 3:00 PM, Gabriel Ortiz Lour <ortiz.admin@gmail.com>
> wrote:
>
>>
>> Hi all,
>>
>>   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:
>>
>>   I'm using "use_q850_reason" to transport de HANGUPCAUSE from one * box
>> to another, as I can see in the 2nd * log:
>>
>> ">> Using Reason header for cause code: 50"
>>
>> This number (50) came from the HANGUPCAUSE i've set on the 1st * box.
>>
>> 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.
>>
>> 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...!
>>
>> Anyone could help me with some pointers on that?
>>
>>
> 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.
>
> 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:
> * 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.
> * Update everyone who handles AST_CONTROL_HANGUP and extracts the cause
> code out of it to get it from the new structure
> * Update the origination routines to extract the Reason code out of its
> handling of AST_CONTROL_HANGUP
>
> 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.
>
> --
> Matthew Jordan
> Digium, Inc. | Director of Technology
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>

[Attachment #5 (text/html)]

<div dir="ltr">Thank you very much for the information Mathew,<div>   We&#39;ve \
planned to upgrade our plataform&#39;s asterisk version to ast11 in \
2016.</div><div><br></div><div>   For this case I&#39;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 &quot;ast_queue_control(p-&gt;owner, \
AST_CONTROL_BUSY);&quot;, what I did was check if the reason arrived via de Q850 \
&quot;Reason&quot; header, and if it was in a pre-defined range, if so then I used \
the method you mentioned &quot;ast_queue_hangup_with_cause(p-&gt;owner, \
owner-&gt;hangupcause);&quot;.</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 \
&quot;UserEvent&quot; 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-&gt;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-&gt;owner, \
AST_CONTROL_BUSY);</font></div><div><font face="monospace, monospace" size="1">+<span \
class="" style="white-space:pre">						</span>if (resp == 603 &amp;&amp; usedQ850 == \
1 &amp;&amp; owner-&gt;hangupcause &gt;= 123 &amp;&amp; owner-&gt;hangupcause &lt;= \
126) {</font></div><div><font face="monospace, monospace" size="1">+<span class="" \
style="white-space:pre">							</span>ast_queue_hangup_with_cause(p-&gt;owner, \
owner-&gt;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-&gt;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&#39;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">&lt;<a href="mailto:mjordan@digium.com" \
target="_blank">mjordan@digium.com</a>&gt;</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">&lt;<a \
href="mailto:ortiz.admin@gmail.com" \
target="_blank">ortiz.admin@gmail.com</a>&gt;</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&#39;m using a very old asterisk version (1.8.19.0) but here is what I&#39;m trying \
to do:</div><div><br></div><div>   I&#39;m using &quot;use_q850_reason&quot; to \
transport de HANGUPCAUSE from one * box to another, as I can see in the 2nd * \
log:</div><div><br></div><div>&quot;&gt;&gt; Using Reason header for cause code: \
50&quot;<br></div><div><br></div><div>This number (50) came from the HANGUPCAUSE \
i&#39;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 &quot;Reason&quot; 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&#39;m fighting with the code on chan_sip \
function &quot;handle_response&quot; and in the channel.c \
&quot;__ast_request_and_dial&quot;, but I can&#39;t find where the two channels \
relate, where to get the &quot;50&quot; 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&#39;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&#39;re best off \
modifying the control frame AST_CONTROL_HANGUP to pass the chan_sip specific Reason \
code along with it. You&#39;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&#39;s \
probably your best path, anyway. It&#39;s important to note that another way of doing \
this was implemented in Asterisk 11. There&#39;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&#39;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> &amp; <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>




-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic