atcomsystems.ca/forum Forums TDM Business Telephone Systems Nortel Telephones & Systems Nortel VMI DTMF problems

(I hope this is an acceptable topic to post...I feel like I've done nothing but make waves -- unintentionally, I assure you -- since I got here. It seems to make sense to me that this particular topic is not a sensitive one that can't be discussed publicly and that should be in the Nortel forum, but if I'm wrong, feel free to move it to Installers.)

I've got my Asterisk-based SIP-to-MICS bridge up and running using the VMI, and besides the lack of caller ID, it's working brilliantly. I can even initiate call transfers and 3-way calling/conference calling on the Nortel KSU from the VoIP line.

However, I'm having a strange problem with it both recognizing and passing DTMF tones. It appears that if I don't enter in a DTMF sequence within the first few seconds of going off-hook (say, within 10 seconds or so), it stops listening for them or recognizing them. So if, for example, I pick up a phone connected to the VMI, go off-hook, listen to the dial-tone for 10 seconds, and then try to dial something, it continues to give me dial-tone and won't actually patch the call through.

This wouldn't be a big deal except for the fact that it also seems to have an impact somehow on DTMF passthrough for calls placed within the KSU that don't hit the trunk lines. This is especially having an impact with the phone or device hanging off of the VMI being able to navigate Nortel Voice Mail. If I dial voicemail from the VMI, and then wait to enter in my password/PIN until after the voicemail system has stopped talking at me, it can't hear the password I entered into the keypad and prompts me again before it eventually hangs up the call. If I begin dialing the password IMMEDIATELY after placing the call to NVM (without waiting to be told to enter my password), NVM accepts it and gives me the main menu! But if I don't immediately then navigate the menu to get to wherever I'm trying to go (new messages, etc.), it doesn't recognize the menu options I've selected!

One thing that I've discovered that I can do to "wake up" the DTMF detection in the VMI after it has fallen asleep is to flash-hook the line to get to the enter-feature-code mode, and then flash-hook it again without entering a feature-code to return to my current call-in-progress. The DTMF passthrough then works again for a few more seconds before it "falls asleep" again. This is, of course, extremely inconvenient.

The problem with the DTMF detection "falling asleep" at the dialtone largely isn't a problem practically-speaking because I have Asterisk configured to dial immediately after it takes the FXO port off-hook. But the DTMF detection/passthrough issue is still extremely problematic for IP/Asterisk extensions who want to be able to check their voicemail on NVM.

Two other things to note: First, if I call, say, an M7310 handset from the VMI, and enter in DTMF tones on the handset connected to the VMI (even after waiting for a while before entering them), they come through to the M7310 handset just fine. No problems there. So I'm at a loss to explain why it seems to behave differently when it is talking to the NVM than if it is talking to a regular Nortel handset. Second, if the VMI is placing a call out through an analog trunk line, DTMF works perfectly during the entire call. So I can, for example, call myself through the ILEC (going out through one trunk line and looping back in through a second), access NVM, and check my voicemail without any problems.

Anybody have any insight into this problem and what I might be able to do to overcome it?

-- Nathan

I vaguely remember this issue having to do with enabling tone detector on the asterisk full time. And I think they might be some disconnect supervision issues too. You might want to do an internet search and see what comes up. The bridges never really caught on, thats why there are a lot on the secondary market. That, and the fact that the BCM came along shortly after and kind of took over that part of the market for Nortel.

This has nothing to do with enabling DTMF on Asterisk full-time (which I figured out how to do after considerable time spent beating my head against a wall thanks to lack of documentation, and which works perfectly for disconnect supervision on the VMI; I documented it here after figuring it out (post @ top): https://www.voip-info.org/wiki/index.php?page_id=567&comments_page=1 ).

In fact, it has nothing to do with Asterisk at all. This problem with the VMI box happens when I plug an analog phone into it instead of my Asterisk server. (Sorry if I didn't make this clear...I did all of these experiments with DTMF using a normal telephone and not with *, although I can reproduce the exact same symptoms with * talking through the VMI, so it's not my telephone. It's the VMI.)

-- Nathan

I feel your pain on this one. I had a similar issue with DTMF and DS. I hooked up a third party conference bridge only to find out that the ASM ports wouldn't disconnect after hangup. I am taking a shot in the dark here, but its sounds like the issue might be that the system is blocking dtmf after a call completion time out. Does this make sense?
I personally have never used a VMI for anything other than adding a third party voice mail. And I was not impressed with that. We have avoided using them because "seemless" is not an accurate description.
By the way, I read your wiki post, your head must hurt after having to go through all that!! Kudos for not giving up.

Also, to better understand your situation, can you give us a configuration of the system...stations, trunks, VOIP/SIP phones, etc...

Yeah, that kinda makes sense, I guess...but why would there even be an option to block DTMF after a timeout? Is it the VMI doing it or the KSU? And is there a way to disable that?

As far as details go, we are running an MICS on 4.1 with 15 analog trunks and roughly 30 stations (most all M7310 sets). We also have a NAM.

Right now, the VoIP-to-KSU integration is a simple one-station test setup. I have Asterisk 1.4 loaded on a little single-board computer I had laying around (MikroTik RouterBoard RB230) and the PCI slot is populated with a single-port analog FXO card (true-blue Motorola-based X100P). The port on the FXO card is wired to the terminal jack on the VMI. The Asterisk dialplan is set up to dial a SIP extension and answer and bridge the FXO port to the SIP call when it sees ringing voltage on it IF the SIP client answers. If the SIP client doesn't answer, then NVM picks up the call as usual. If the SIP client dials 3 digits, the dialplan is instructed to go off-hook with the FXO port, dial the given extension, and then bridge the FXO port with the SIP session.

But the DTMF problem, I think, really has nothing to do with Asterisk or DS or anything of that nature. Forget about the Asterisk setup -- it's a red herring -- and pretend there is no Asterisk server in the equation, and that I have a regular analog phone plugged into the terminal jack of the VMI instead. If I pick that phone up, then flash-hook it and dial *981 to get to NVM, if I wait too long before I punch in the voicemail password, NVM won't hear the DTMF. At the same time, if I call another station, wait even 5 minutes, and then start hitting buttons on the analog phone plugged into the VMI, I hear the tones come through the speaker on the other station plain as day.

Puzzling, to say the least.

Hey, as an aside...when you dial the NAM on its assigned DN, NVM answers and acts as if you did F981. Is there any way that I can assign a second DN to the NAM and have NVM answer direct calls to that DN the same way it would "answer" F980? I'm trying to figure out how I can transfer someone to NVM and have them be prompted to leave a message, and I can't use either blind or supervised transfer on the VMI to patch in a current call to a feature code, so blind-xfer to F980 isn't an option...it HAS to be a DN.

(I swear, I may just end up recommending that we pitch the Nortel and switch whole-hog over to Asterisk...this is beginning to be more trouble than it's worth...)

Thanks,

-- Nathan

The NAM already has a 2nd DN, not that it would help you. BUT, you can assign a MB to a non-existent extension's DN and it'll answer.

I don't remember seeing a reason for this whole setup. So, why are you trying to re-invent the wheel?

Reinvent what wheel, exactly?

The reason for this whole setup was to come up with a way to have remote "extensions" on our phone system (Nortel MICS) without chucking the entire system and going to something new (new handsets, new voicemail system, new training for everybody in the office...). We have a couple of people who telecommute from a few hundred miles away, and we want them to have 3-digit phone extension and a voicemail box just like anybody who is physically present in the office does. Then we can call them (and they us) just as if they worked at our headquarters, and not to mention do so without toll charges (since we'd be trunking the calls over IP). Furthermore, clients of ours who need to speak to them can call our office to get through to them (rather than calling their home-office or cell numbers direct), and they can make outgoing business calls through our trunk lines to clients rather than submitting toll reimbursement charges to payroll (either for calls to clients, or for calls to us).

If we got this working, I thought it would also be nice, at the same time, to give some of us who do work from the office a way of using a SIP phone at home that we could use just like the phone at our desk if we ever needed to work at home for a day here and there (rings when our extension is called, and with calls from the SIP phone showing up as coming from our normal extension if we call other office DNs from home, etc.). The idea is that neither clients no co-workers should need to worry about whether I'm at my desk or whether I'm at home...one extension, one number, one voicemail box, no hassle.

Last time I checked, the MICS doesn't support IP phones. Sure, we could drop in a BCM instead, but if we were going to go to that trouble, it seems to me that it would be more cost-effective and more future-proof-able at that point to go with a completely Asterisk + SIP solution and replace all of our handsets with ethernet+SIP ones and rip the MICS KSU off the wall.

Thus the whole Asterisk SIP-to-analog-FXO-to-VMI (or ATA) kludge.

Am I overlooking another option?

-- Nathan

You might want to re-think the BCM. Its fairly cost effective right now, you get to keep your digital sets, you can use soft phones at the remote sites if you want. There are also options with the Avaya IPO and its acceptance of Nortel series sets. With the Asterisk, it might come down to what type of Asterisk hardward are you going to use and what type of SIP phones? I think either choice will boil down to a cost/preference on your part.