[asterisk-dev] SIP channel X Local Channel

Gabriel Ortiz Lour ortiz.admin at gmail.com
Fri Dec 4 14:32:30 CST 2015


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 at digium.com>:

>
> On Tue, Dec 1, 2015 at 3:00 PM, Gabriel Ortiz Lour <ortiz.admin at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20151204/e37ea57f/attachment.html>


More information about the asterisk-dev mailing list