[Home]

Summary:ASTERISK-11812: variables utilized with Dial command and parameter L, appear to be neglected when utilizing a chan_local combo
Reporter:Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech)Labels:
Date Opened:2008-04-09 16:31:46Date Closed:2011-06-07 14:03:19
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Ok, this is a little complex, so please bear with me for the explanation:

I have a script operating with the AMI, simply originating calls to chan_local, and then once chan_local picks up, they will connect the calls to an extension. Up till now, this is very simple. The call is originated to the callback_dummy context, using the combo Local/1234567890@callback_dummy

Once the call to the extension had been picked up by Asterisk, the dialplan directs the extension to dial to an outbound number, using the call_originator context, which appears in the Exten/Context part of the originate request.

Once the target "originator" had been contacted, Asterisk will then transfer both channels in to the call_target_dummy context, hanging up the local channel, and directing the "real" channel in to the call_target context. Once in call_target, Asterisk would then dial the "target" number.

As you can see in the dial plan below, I've defined the L parameter, in order to limit the duration of the call. The funny part of this is that while the call time is being limited correctly, the warning sounds that are supposed to be played, are not played - to any of the parties.

I was under the impression that this is a chan_local issue, or something that can't be done. However, after consulting punopvut@#asterisk-bugs, he indicated that a bug should be opened.

The following may also shed some light here, I've also tried replacing the dialing at call_target to a backgroundDetect, and it would appear as if Asterisk isn't even aware that an RTP stream is available for background detection.

* I've marked the severity on this as "major", as I'm currently in the process
 of developing an application that require heavy usage of chan_local, and it
 would appear that it may cause issues.

* If additional information is required, please direct me to what needs to be  
 done in order to gather the information, and I'll post it.


****** ADDITIONAL INFORMATION ******

[callback_dummy]
exten => _X.,1,Answer
exten => _X.,n,Wait(120)

[call_originator]
exten => _X.,1,Set(__LIMIT_PLAYAUDIO_CALLEE=yes)
exten => _X.,n,Set(__LIMIT_PLAYAUDIO_CALLER=yes)
exten => _X.,n,Set(__LIMIT_WARNING_FILE=beep)
exten => _X.,n,Dial(${originator},120,rRG(call_target_dummy^${origin_e164}^1)L($[${timelimit}+30]000,91000,16000))

[call_target_dummy]
exten => _X.,1,Hangup
exten => _X.,n,Goto(call_target,${EXTEN},1)

[call_target]
exten => _X.,1,Answer
exten => _X.,n,Set(__LIMIT_PLAYAUDIO_CALLEE=yes)
exten => _X.,n,Set(__LIMIT_PLAYAUDIO_CALLER=yes)
exten => _X.,n,Set(__LIMIT_WARNING_FILE=beep)
exten => _X.,n,Dial(${target},120,rRL(${timelimit}000,61000,16000)g)
Comments:By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2008-04-10 17:42:16

Please close this issue, this is was a dialplan issue - not a bug.
Sorry for the mistake.
By: Jason Parker (jparker) 2008-04-11 10:23:16

Closing, per reporter.

For completeness, I'd be interested in what the problem ended up being.  Could you contact me on IRC?