Summary:ASTERISK-10561: Features (from features.conf) not available if call was originated by manager API or call file
Reporter:Volker Kettenbach (vsauer)Labels:
Date Opened:2007-10-17 15:35:57Date Closed:2011-06-07 14:03:23
Versions:Frequency of
Environment:Attachments:( 0) dial_by_mgr.canreinvite_no.txt
( 1) dial_by_mgr.canreinvite_nonat.txt
( 2) dial_by_normal_phone.txt
Description:Calls originated by the manager api (or by a call file, too), cannot
use features defined in features.conf (like automon#blindxfer#atxfer#parkcall#disconnect).
Every Dial() command in my diaplan has the appropriate
parameters out of {tTkWwW}and the manager api jumps
to the same context as a normal call from a phone, where these features work.
DYNAMIC_FEATURES is set globally.


I did some debugging:

vsauer@arthur: ~ > telnet localhost 5038
Action: Login
UserName: webdial
Secret: XXXXX

Response: Success
Message: Authentication accepted

Action: Getvar

Response: Success
Value: automon#blindxfer#atxfer#parkcall#disconnect

Well, that means that the global variable is known in this context (as
it should be). But if I run:

Action: Originate
Channel: SIP/cisco1
Exten: 201
Context: doLocalCalls
MaxRetries: 1
RetryTime: 15
WaitTime: 60
Priority: 1
SetLanguage: de

he called party can listen to DTMF instead of asterisk triggering
atxfer or so.

That's what the CLI says:
 == Parsing '/opt/asterisk/etc/asterisk/manager.conf': Found
 == Manager 'webdial' logged on from
      > Channel SIP/cisco1-08247f88 was answered.
   -- Executing [201@doLocalCalls:1] Goto("SIP/cisco1-08247f88", "doRemoteCalls|201|1")
+in new stack
   -- Goto (doRemoteCalls,201,1)
   -- Executing [201@doRemoteCalls:1] Goto("SIP/cisco1-08247f88","Dial-Default|XXXXXXXXXXX|1") in new stack
   -- Goto (Dial-Default,06151154260,1)
   -- Executing [06151154260@Dial-Default:1] Macro("SIP/cisco1-08247f88","Dial-Tol|XXXXXXXXXXX") in new stack
   -- Executing [s@macro-Dial-Tol:1] Set("SIP/cisco1-08247f88","CALLERID(name)=XXXXXXXXXXXX") in new stack
   -- Executing [s@macro-Dial-Tol:2] ExecIf("SIP/cisco1-08247f88","0|SIPAddHeader|Privacy: header") in new stack
   -- Executing [s@macro-Dial-Tol:3] Set("SIP/cisco1-08247f88","CDR(accountcode)=t-online") in new stack
   -- Executing [s@macro-Dial-Tol:4] Dial("SIP/cisco1-08247f88","SIP/tol/XXXXXXXXXXX||KTW") in new stack
   -- Called tol/XXXXXXXXXX
   -- SIP/tol-08240f78 is making progress passing it to SIP/cisco1-08247f88
   -- SIP/tol-08240f78 is ringing
   -- SIP/tol-08240f78 is making progress passing it to SIP/cisco1-08247f88
   -- SIP/tol-08240f78 answered SIP/cisco1-08247f88

You see I run Dial with the KTW options.
*Maybe* in this case, my phone is not the "caller" but the "called"
because it get's called  by the manager API (I don't know how one has
to see that). To check, I dialed with "ktwKTW" - same result. If I
dial with the normal phone, #2 for atxfer works. If I dial with the
manager API, it doesn't.

I even tried to set the variable in the manager API. The CLI says:
== Setting global variable 'DYNAMIC_FEATURES' to

but the result is the same. No features like #2.

I tried to use chan_local to dial to a certain context and set the Dial parameters for both channels (caller and called):

-- Executing [12@doLocalCalls:1] Macro("Local/12@doLocalCalls-94a1,2","intDial|SIP/cisco2") in new stack
-- Executing [s@macro-intDial:1] Dial("Local/12@doLocalCalls-94a1,2","SIP/cisco2||kKwWtTj") in new stack
   -- Called cisco2
-- Executing [s@macro-Dial-Tol:4] Dial("Local/12@doLocalCalls-94a1,1","SIP/tol/XXXXXXXXXXX||ktwKTW") in new stack

Now, the phone and the remote party are called with Dial with ktwKTW.
This should do it. But: nothing!

I think it used to work in older versions, but I'm not sure. At least in 1.2 from which I directly upgraded.
Comments:By: Joshua C. Colp (jcolp) 2007-10-19 12:07:14

I've confirmed that DYNAMIC_FEATURES was never meant to be used with the automon, blindxfer, etc options set. I also confirmed that in 1.2 it behaves the same as 1.4.

As for the dial options let's skim it down to the minimum to try to isolate the issue. Can you please perform an Originate to a phone that then goes to an extension that simply does a Dial to something else with the H and h options set? You should be able to hit * to disconnect the call. I have confirmed this works on my setup. If it does not on yours also enable debug output to a level of 9 and attach the complete console output as an attachment.


By: Volker Kettenbach (vsauer) 2007-10-19 15:39:12

I uploaded the requested logfiles:

dial_by_normal_phone.txt shows how it should work including logged dtmf, which does not appear in the other logs even the dtmf logging is always on (!).

dial_by_mgr.canreinvite_nonat.txt shows the test case you described (Originate to cisco2 which then dials 16@doLocalCalls which dials with hH cisco1). No dtmf is shown and neither * nor any other option does work. It's done with canreinvite=nonat which is my default setting.

dial_by_mgr.canreinvite_no.txt ist the same with canreinvite=no. Same behaviour except native bridge, same result.

Question: what do you mean by "DYNAMIC_FEATURES was never meant to be used with the automon, blindxfer, etc options set" ?? Do mean that it actually is there to activate stuff from the [applicationmap] section of features.conf? Why do have to set it activate stuff from [featuremap] (like the wiki says!?). Or am I wrong and I don't need it....?

By: Joshua C. Colp (jcolp) 2007-10-22 08:03:13

The DYNAMIC_FEATURES variable doesn't recognize automon, blindxfer, etc. It was never written to (I checked back).

As for your current issue what does the sip.conf look like for the devices in question and what DTMF mode are they using?

By: Volker Kettenbach (vsauer) 2007-10-22 10:18:44

Problem solved!!

I set dtmfmode = auto globally. The cisco documentation says the my phones require dtmfmode = inband, but for the voicemail, IVRs etc. it worked with dtmfmode = auto as well.
I've now set dtmfmode = inband for the phones and auto globally and everything is fine!

Thanks for your help and sorry forclaming that this is a bug!

By: Joshua C. Colp (jcolp) 2007-10-22 10:24:30

Closed as issue was with configuration of DTMF.