Confirm calls hang up

General Help
1

When dialing an outside number in a ring group with “confirm calls” checked, as soon as I press 1 it hangs up the call.

Here is the log

[Apr 2 21:30:21] WARNING[12523] file.c: Unexpected control subclass ‘-1’
[Apr 2 21:30:27] DEBUG[12523] app_macro.c: Oooh, got something to jump out with (‘1’)!
[Apr 2 21:30:27] DEBUG[12523] app_dial.c: Macro exited with status 49
[Apr 2 21:30:27] VERBOSE[12527] logger.c: – Executing [h@macro-dialout-trunk:1] Macro(“Local/xxxxxxx@from-internal-182b,2”, “hangupcall|”) in new stack

Any ideas??

-Steve

2

I have tried both asterisk 1.4 and 1.6, both act the same. I have checked out the newest 2.5 trunk from svn and the problem still exists.

Here is a little bit more of the log.

[Apr 3 10:20:14] VERBOSE[16630] logger.c: – <Local/9758153@from-internal-8ca9;1> Playing ‘incoming-call-1-accept-2-decline.slin’ (language ‘en’)
[Apr 3 10:20:14] WARNING[16630] file.c: Unexpected control subclass ‘-1’
[Apr 3 10:20:17] VERBOSE[16630] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on ‘Local/RG-600-xxxxxxx#@from-internal-9af5;2’ in macro ‘dial’
[Apr 3 10:20:17] VERBOSE[16630] logger.c: == Spawn extension (from-internal, RG-600-9758153#, 1) exited non-zero on ‘Local/RG-600-xxxxxxx#@from-internal-9af5;2’
[Apr 3 10:20:17] VERBOSE[16630] logger.c: – Executing [h@from-internal:1] Macro(“Local/RG-600-xxxxxxx#@from-internal-9af5;2”, “hangupcall”) in new stack
[Apr 3 10:20:17] VERBOSE[16630] logger.c: – Executing [s@macro-hangupcall:1] ResetCDR(“Local/RG-600-xxxxxxx#@from-internal-9af5;2”, “vw”) in new stack
[Apr 3 10:20:17] VERBOSE[16630] logger.c: – Executing [s@macro-hangupcall:2] NoCDR(“Local/RG-600-xxxxxxx#@from-internal-9af5;2”, “”) in new stack
[Apr 3 10:20:17] VERBOSE[16630] logger.c: – Executing [s@macro-hangupcall:3] GotoIf(“Local/RG-600-xxxxxxx#@from-internal-9af5;2”, “1?skiprg”) in new stack
[Apr 3 10:20:17] VERBOSE[16630] logger.c: – Goto (macro-hangupcall,s,6)

Thanks for any help with this.

-Steve

3

If I uncheck “confirm calls” then I am able to answer the call without a problem.

-Steve

4

I fixed this by recording my own recordings for Remote Announce: and Too-Late Announce: Hope this helps someone else.

-Steve

5

Steve,

What version of things are you running that you are having this issue?

6

I tried different combinations of 2.5.1, the current svn, and asterisk 1.4 and 1.6. All had the same problem. As soon as I recorded my own recordings and switched the ring group to point to them it started working.

-Steve

7

something does not seem right as I have it working using asterisk 1.4 and 2.5.1.2, along with many others.

Is this a custom built system or from a Distro? details please.

It almost looks like a permissions issue.

8

This is a custom built ubuntu system. I spent a whole day trying to debug this problem. I checked and rechecked permissions since problems with Linux are almost always permissions :slight_smile: After turning on debugging I noticed this in the log…

[Apr 3 10:34:59] DEBUG[17927] app_macro.c: Oooh, got something to jump out with (‘1’)!
[Apr 3 10:34:59] DEBUG[17927] app_dial.c: Macro exited with status 49
[Apr 3 10:34:59] DEBUG[17927] channel.c: Hanging up channel ‘Local/xxxxxxx@from-internal-d163;1’
[Apr 3 10:34:59] DEBUG[17931] channel.c: Didn’t get a frame from channel: Local/xxxxxxx@from-internal-d163;2
[Apr 3 10:34:59] DEBUG[17931] channel.c: Bridge stops bridging channels Local/xxxxxxx@from-internal-d163;2 and SIP/vitel-outbound-08632ed8
[A

So I thought it might be a reinvite problem so I set canreinvite on my outbound and inbound trunk to yes. That didn’t solve the problem. Then I read http://is.gd/r06i where someone was having the same issue as myself. So I tried recording my own and it worked like a champ. Only thing I can think of is maybe it’s a Vitelity problem?

9

look in the FAQ or how-to section of the documentation. There is a page for Vitelity setup. maybe it’s something small that needs to be tweaked.

10

I’m running asterisk 1.4.24.1 with freepbx 2.5.1 and confirm calls is not working. When any input is pressed the call is immediately hung up.

The problem is with this line in [macro-confirm] from extentions_additional.conf:

exten => s,n(start),Background(${MSG1},m,${CHANNEL(language)},macro-confirm)

Asterisk is not looking at the ,macro-confirm and is passing the inputted options back the the calling context.

I do remember this working at one time so I’m not too sure if its an Asterisk problem or FreePBX.

-Steve

11

Changing macro-confirm to confirm seems to fix the problem.

-Steve

12

try going back to an earlier version of Asterisk, try 1.4.21.1 - this looks like an Asterisk bug.

13

Are you sure this is a bug with Asterisk or is it something they have changed in newer releases? Does Asterisk allow you to have both a confirm extension and a macro-confirm extension? If not then it would make sense that they have changed the usage of the Background command.

-Steve

14

I doubt it is a feature change and it also seems like there are enough variables with all the different testing to question what really got things working.

The last option to Background is appropriately “macro-confirm” and not “confirm”. This is the context that the background command should look for the digit being pressed.

It’s very possible that it started working because putting in a bogus context that does not exist (confirm) made the entire Background command fail and skip to the Read() command. However the Read() command would not work had you had a multi-part recording (made of multiple components) which is why the Background is used and the only reason that the Read() is used instead of the WaitExten() is because there is no ‘context’ option for WaitExten. (And this whole issue gets much more complex if you dig in, with the roots being that the Background() command can not normally be used within a macro because it will otherwise try to look for the pressed digits in the context where the macro was called, in this case, thus the reason for the context command at the end.)

15

There is a proposed Asterisk fix for this, if you are having this issue it would be great to try and test out the patch. You can find it here, and feedback on the Digium bug system would be great, or if you can’t, at least report back here.

http://bugs.digium.com/view.php?id=14940

thanks!

16

tested this and it appears to fix the issue:)

17

Could you please post an illustration on how to apply the patch or a link that explain how to apply the patch 14940.

Thanks!

18

mycompuerwiz,

The proper place to ask about patching asterisk is over in the asterisk forums and/or your distro provider and not here as we assume that you already have a installed and functioning copy of asterisk.

Please also realize that the patch is a patch to the base C code for asterisk and if you are like one of the many who are using a distro built system you need to consult with your distro builder/provider as some will provide what you need while others will require you to load other items before you can. So it’s almost impossible do what you ask as we know NOTHING about your setup.

19

Could you please post an illustration or link that explain how to apply the patch 14940 to freepbx.

Thanks!

20

I’m seeing this problem again. Not sure yet if it’s failing the same way. Just wanted to ping folks to see if anyone else is running into this with * v1.4.25.1

Thanks,

JPS