Unable to access the "My Voicemail" featurecode

Good morning. I initially started this over in the FPBX forums, believing it was an issue there. Now, I’m not so convinced, so i thought I’d let the Asterisk folks take a crack at it.

First off, we don’t use the default feature codes - they’ve all been changed to other codes that allow us to make a nicer dialplan on the phones (faster response when dialing). Obviously, none of them are duplicates or conflict.

Sometime over the weekend, something changed and now we can’t call our My Voicemail feature code. Call drops almost immediately and the phone fires back a “no response”. I’m thinking an update might have run over the weekend and possibly a newer version of Asterisk was upgraded that is causing the issue.

The feature code for Dial Voicemail is #0* (this works, as does #0*+extension).
The feature code for My voicemail is *0# (this stopped working).

Initial tests were to change the My VM code to “1234” (worked) and *0 (worked). This morning, someone in the FPBX forum suggested the fact the code ends with a # might be the issue, since all of our other codes that have a # in them, also have digits after them (# isn’t the last digit in those cases).

My concern is, this worked back on Asterisk 1.8, 11, 12, and 13. It only stopped working this weekend. Other systems we have out there, it still works, but one that I ran a Yum Update on this week, now it doesn’t work (yes, there was an Asterisk update in that bundle). That’s why I’m thinking it’s an issue with a recent Asterisk update.

Andrew N (over on the FPBX forum) said:
It’s the “#”. Asterisk is interpreting it as an include statement. I can’t recall if feature code admin allows “” but you can try *0#

Feature code admin did not permit the backslash, but I manually ended the file to include it and reloaded asterisk - didn’t have an effect.

Anyone have any thoughts on what might have caused this? In theory, it’s easily reproducable. When traced, it doesn’t look like it even finds a match to the feature code (trace below):
== Extension Changed 1602[ext-local] new state InUse for Notify User 1602
== Extension Changed 1602[ext-local] new state InUse for Notify User 1777
== Extension Changed 1602[ext-local] new state InUse for Notify User 1601
– Executing [*0#@from-internal:1] GotoIf(“SIP/1602-0000001a”, “1?hangup”) in new stack
– Goto (from-internal,*0#,3)
– Executing [*0#@from-internal:3] Hangup(“SIP/1602-0000001a”, “”) in new stack
== Spawn extension (from-internal, *0#, 3) exited non-zero on ‘SIP/1602-0000001a’
– Executing [h@from-internal:1] Macro(“SIP/1602-0000001a”, “hangupcall”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“SIP/1602-0000001a”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“SIP/1602-0000001a”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] Hangup(“SIP/1602-0000001a”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/1602-0000001a’ in macro ‘hangupcall’
== Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/1602-0000001a’
== Extension Changed 1602[ext-local] new state Idle for Notify User 1602 (queued)
== Extension Changed 1602[ext-local] new state Idle for Notify User 1777 (queued)
== Extension Changed 1602[ext-local] new state Idle for Notify User 1601 (queued)

I do understand I can just change the code, but a lot of effort went into creating these standardized dialplans (that have worked for years), and I don’t want to modify hundreds of systems simply because of an issue that could be corrected if it’s a bug.

Does anyone have any thoughts?

Thx.

I don’t see any use of a feature in your log output.

Can you do a ‘features show’ on your console and paste the output here?

Turns out this was something in FPBX. Latest module updates the following week (on this past Monday) corrected the issue.