possible dtmf issue

hmm try it with 1.4.26.1 or 2 and tell me if you have the same problem. I had a similar issue with 1.4.29 and had to switch. I think the problem may be how hunt lists deliver calls. Hunt lists invoke a series of chan_local calls which then calls chan_sip. Chan_local from time to time screws up faxing, or dtmf or other things. Is it _only_ the # that is not working? Do you have a way to verify the rest of the dtmf digits are working? # is defined in features.conf and the userexten script will invoke options that make use of features.conf.

What IAD are you using to deliver analog service to your customer?

assuming your using an IAD delivering multiple analog pair in a hunt list.... set up a direct dial to line #3,again assuming its part of the hunt list. This direct dial number that invokes 'go to user extension' does not invoke chan_local. If you get the same error it at least rules out chan_local as the culprit. It might still have the features.conf issue, or it might be specific to 1.4.24

they have linksys spa2102.

dtmf's work since you can dial * to retrieve voicemail onsite. You can do the transfers and all.

its just when they call from home and they want to check there voicemail. They press *7 to activate the voicemail. but when they push # they get an error.

could it possible be a problem with there onsite pbx/voicemail system?

I will test the direct to user extension later tonight.

Hey E:

From what I gather, when I am in the Avaya Partner Messaging system, it is asking me for the extension followed by the pound sign.

Now I am pretty sure that the asterisk interprets this as a regular # command and is sitting there listing waiting for further input, such as the ## or #* for transfers. It never passes the pound sign to the APM system. I tested by entering ## and it prompts me for transferring. So like I said, it # is getting read at the thirdlane PBX level but not passing to the APM system.

Is there any work around or anything you see that might rectify this?

Thanks,
--Herron

so your saying ## is sending a single # to the APM? In other words.. extension + ## has the effect of what extension + # should be doing?

no the way it should be is:

I call into the roll over, sends busy, APM system kicks in and starts.

I press *7 to access voicemail messages
i enter followed by the pound sign.
...

what happens now is, i press +# and it says its invalid extension

i noticed if i press ## the thirdlane pbx is asking for the transfer like normal.

so i presume the problem is that the thirdlane asterisk is not passing # to the APM system to be interpreted to retrieve voice mails.

the thirdlane asterisk is listening for the # codes and not passing them through.

I guess we need to find a work around to allow passing of # during the APM system.

well an easy way to test that is to alter your features.conf file and pick a different code set.

try this:

blindxfer => #1 ; Blind transfer
atxfer => #2 ; Attended transfer
disconnect => #0 ; Disconnect
automon => #9 ; One Touch Record

verify the change after a reload with

features show from cli

i will try this now but wont this still keep the asterisk from sending the # sign since it is still listening for # codes?

I havent tested yet because I want to ask if this would bug out polycoms/spa2102/audiocodes since they are using this programming?

is there a way to have say features.conf and have only that tenant refer to that features.conf file so we dont mess with any other tenants?

heres the skinny on the dial command sent to your ATA.. you should not be passing dial arguments:

't' 'T' 'w' 'W' 'H' 'h' 'k' 'K' otherwise features.conf is invoked and asterisk remains inserted in the call.

now heres the problem... by default tl-userexten-base sets options 'rTt' without even your input, if you have 'one touch recording' for that extension the Ww is also added to the dial command.

your huntlist is using chan_local to call the extensions the exact same way your phone calls them... which means tl-userexten-base is invoked to call phones in a ring group. So, features.conf is invoked, asterisk is still in the call, and if that doesnt compound things enough, chan_local (the unpredictable bitch that she can be) is also there screwing with things.

what really _should_ happen is hunt lists needs to be re-written to call the devices as SIP/channel NOT as Local/extension@context. this will prevent all those options unless you want to set them in the huntlist AND has the added benefit of preventing chan_local from screwing up everything included in-audio faxing.

in the short term, you can re-define the transfer digits in features.conf and join my bandwagon to petition the abolishment of chan_local wherever possible.

features.conf only affects using dtmf while on a call, the real phones like polycom use sip messages to conduct those actions. Only someone using an ATA with an analog house phone would need dtmf in order to do transfers.

I will definitely jump on your bandwagon!

But my extrapolating skills are sucking right now.

if i were to change to

blindxfer => #1 ; Blind transfer
atxfer => #2 ; Attended transfer
disconnect => #0 ; Disconnect
automon => #9 ; One Touch Record

the pbx still wont pass the # through because it is listening for a digit to follow it, right?

you can try changing it to something else for testing purposes... how about

blindxfer => 99
atxfer => 98

just for the purpose of your test... if this is the case then 9 wont work but # will.

if you can confirm that then its the 'T''t' options killing you.