[Home]

Summary:ASTERISK-06756: chan_local support for L and S flag on app_dial won't work at all
Reporter:Nir Simionovich (atelis)Labels:
Date Opened:2006-04-11 11:12:04Date Closed:2011-06-07 14:02:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_local
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Any news about this bug, I've tried applying the above patch, but still option L still doesn't work - anybody working on it?

I've been trying to use the L parameter according to the following scenario:

1. Manager originates a call to a Local channel
2. Local channels answers and performs a Dial via a SIP channel. The Dial command has an L parameter defined with (90000:60000:30000).
3. Remote SIP end picks up the call and is passed into a MeetMe room.

Although I see that the asterisk received the information to the L parameter correctly, the call isn't hung up at 90 seconds, not even at 110 seconds. A warning sound isn't played, nothing actually happend. I trying bringing up the debug level and see what's going on, Asterisk doesn't even show anything happening at the time the warning is supposed to come out.

After this, I did a small experiment to do a simple dial using a direct IAX->SIP connection, and the problem wasn't there. Looks like that problem here is related to chan_local or something like that.



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

I've also added a typeout of my console at http://pastebin.com/653673 [^]

Which appear to show the following:

#
Apr 11 19:39:02 DEBUG[21712]: app_meetme.c:1062 conf_run: Placed channel SIP/62.90.49.50-fcf4 in ZAP conf 1023
#
   -- Stopped music on hold on SIP/62.90.49.50-35b5
#
Apr 11 19:39:02 DEBUG[21710]: channel.c:1718 ast_settimeout: Scheduling timer at 0 sample intervals
#
 == Spawn extension (macro-ngx1_originator_connect, s, 16) exited non-zero on 'SIP/62.90.49.50-35b5' in macro 'ngx1_originator_connect'
#
Apr 11 19:39:08 DEBUG[21710]: app_dial.c:1442 dial_exec_full: Macro exited with status -1
#
Apr 11 19:39:08 WARNING[21710]: res_features.c:1374 ast_bridge_call: Bridge failed on channels Local/972544482826@ngx1_call_init_originator-eafc,2 and SIP/62.90.49.50-35b5
#
Apr 11 19:39:08 DEBUG[21710]: chan_sip.c:2419 sip_hangup: update_call_counter(972544482826) - decrement call limit counter
#
Apr 11 19:39:08 DEBUG[21710]: app_dial.c:1588 dial_exec_full: Exiting with DIALSTATUS=ANSWER.
#
 == Spawn extension (ngx1_call_init_originator, 972544482826, 7) exited non-zero on 'Local/972544482826@ngx1_call_init_originator-eafc,2'
#
   -- Executing DeadAGI("Local/972544482826@ngx1_call_init_originator-eafc,2", "agiGenericWrapper.php|inC2^HandleOriginatorDisconnect") in new stack

Any idea about that warning up there?
Comments:By: Nir Simionovich (atelis) 2006-04-11 11:12:48

I wrote this originally as part of bug ASTERISK-6195, however, I've concluded that this is not and issue with the Dial application, but actually with chan_local


By: Kevin P. Fleming (kpfleming) 2006-04-11 14:49:42

This is not a bug. The L and S options to Dial() affect the bridge that gets created when the dialed channel answers; however, when you dial out via Local the local channels are destroyed and the target is bridged to the original calling channel, so the only timeout options that have any effect are the ones on the original Dial(Local/...).

The simple solution for you is to use the /n option for the local channel, so that the bridge gets built and stays around, instead of being destroyed. Any other change in this behavior would be a feature request, not a bug.
By: Nir Simionovich (atelis) 2006-04-11 16:01:09

Actually, as noted in the previous bug that I posted initially, I tried using the /n flag within the Originate request in manager, but that didn't have the desired affect.

If /n was supposed to constitute normal channel behaviour, while it didn't, it would constitute a bug - or have I got it wrong somewhere ?
By: Matt O'Gorman (mogorman) 2006-04-19 17:04:09

I tried to duplicate this several different ways in both trunk and 1.2 and was unable to if you pass the n option in the dial statement.  If you could provide a dial plan and possible manager command.
By: Nir Simionovich (atelis) 2006-04-28 14:51:42

Hi mogorman,

 Well, don't use a dial command as that's not what I'm doing. You should originate a call to the Local channel via the Manager. That will enable you to recreate the issue I believe.
By: Nir Simionovich (atelis) 2006-04-28 14:58:04

I think this report and report ASTERISK-6356 should be merged into one, as it sounds like the exact same problem
By: Matt O'Gorman (mogorman) 2006-04-28 15:05:42

I was using originate and what not but you still have to do a dial on the local channel to bridge it please provide a way for someone to reproduce the bug
By: Nir Simionovich (atelis) 2006-04-29 01:17:35

I'm not entirely sure I understand what you just wrote, however, here is my Originate command, as built from my PHP code:

Channel: Local/4622972542388822@ngx1_call_init_originator/n
Context: ngx1_call_init_originator
Exten: 800#4622972542388822
Priority: 1
Timeout: 45000
CallerID: 4622972542388822
Account: d41d8cd98f00b204e9800998ecf8427e444ce4f58de7f
Async: 0
ActionID: d41d8cd98f00b204e9800998ecf8427e444ce4f58de7f
Variable: null=null
Variable: targets=462297226517781;
Variable: originator=4622972542388822
Variable: recording=1
Variable: retries=3
Variable: moh_class=moh_promo1
Variable: call_limit=1200
Variable: ring_policy=ringall
Variable: meetmeroom=128

As you would notice, the channel variable actually has a '/n' parameters at the end, however, Asterisk completely disregards it for some reason.

The context the originate will send the channel to looks like this:

[ngx1_call_init_originator]
exten => _X.,1,Answer()
exten => _X.,n,Wait,0.5
exten => _X.,n,Macro(dumpvars)
exten => _X.,n,SetCDRUserField(o_${ivr_session_id})
exten => _X.,n,SET(LIMIT_PLAYAUDIO_CALLEE=yes)
exten => _X.,n,SET(LIMIT_WARNING_FILE=spy_sip)
exten => _X.,n,Dial(SIP/${originator}@62.90.49.50,120,HL(${call_limit}000:60000:30000)M(ngx1_originator_connect^${meet
meroom}^${ivr_session_id}^${originator}^${recording}^${moh_class}^${call_limit}))

exten => _283547.,1,Goto(ngx1_call_init_target,${EXTEN},1)

exten => h,1,DeadAGI(agiGenericWrapper.php,inC2^HandleOriginatorDisconnect)

exten => failed,1,DeadAGI(agiGenericWrapper.php,inC2^HandleOriginatorFailure)

The AGI are basically result code handlers, so you don't really needs thos, just put a noop in there to simulate on your box, but I'm confident you'll be able to replicate the issue with this.

I'm currently using r19008M of SVN-branch.


By: seb7 (seb7) 2006-05-17 08:19:54

I discovered this issue (L Dial option not working with chan_local except if you use /n with your chan_local - which I thought I'd try testing before reporting) independently and was about to report it when I found this issue (ASTERISK-6756).

I've found that the /n option solves my problem using both call files and the originate command and I'm using a nearly identical set-up to the reporter (atelis) (on Asterisk 1.2.7.1), except that I'm only using the L option on my Dial command and using Zap to dial out.

However this issue is definately a 'gotcha' and should be documented somewhere obvious. The amount of several hour calls I've had as a result... (fortunately they didn't cost anything material).

In my view, the L option is given on the Dial command which creates a Zap channel so the L option should apply to the Zap channel and not the Local channel which executed the Dial command. This would mean when the local channels are destroyed, the L option would be unaffected. However, that was just my assumption of how things should work without knowing much about the code architecture.
By: Serge Vecher (serge-v) 2006-05-24 12:35:40

seb7: as kpfleming said earlier, preserving the L option across the local channel is a feature request. Feel free to attach a patch to implement this. Leaving this open for any takers for a couple of days.
By: Kevin P. Fleming (kpfleming) 2006-05-24 13:55:20

I cannot see any way that the '/n' option you are supplying is _not_ getting passed to the Local channel that is being created; as the last bugnote said, other people are using this tecnnique and it is working fine. Your dialplan is so complicated, though, that it's hard to see what is actually supposed to be happening.

In any case, the behavior that requires '/n' for channel time limits to work on the Dial() operation done inside the Local channel will not be changed. The Local channel is a proxy, and if you let it drop out of the path, many of the options you specified on that Dial() operation will not have the effects they were designed to. There is no practical way to 'push' these dial options up to a higher level bridge, especially since there may not even be one.