Stuttery embedded voicemail issue - 3300 v9

[fissure]

Hi there,

at a few different customer sites, we have a stuttery voicemail issue, that we believe only arose in version 9, but is present, it seems, right across 9.0.1.17 / 9.0.2.28 / 9.0.2.31_1 (9.0 UR2 PR2)

Recorded messages, whether emailed with advanced voicemail, or listened to, through the phone, contain stutters. Even the pre-recorded system prompts do.

We have it on sites with BRI and sites with PRI (ISDN2 / ISDN30) and even on internal 'IP Networking' calls.

The weird thing is, there have been absolutely no issues with actual phone calls, just with voicemail, so it doesn't seem like an IP / QoS / network or trunk issue.

Calling in across a trunk, or calling voicemail internally, you can hear stutters in the default prompts.

We've replaced hard disks to no avail, and opened a case with Mitel, to no avail, as yet.

We can't rule out a config issue, but, we use a standard config, and have never experienced it v8, there are no alarms or netsync issues and Mitel haven't been able to identify a config issue (having been sent a copy of the database).

It 'feels' like a buffering issue when it reads the voicemails/prompts from the disk (there is some debate whether if you listen to the same message repeatedly, the stutters fall in different places. Every 10 seconds or so).

Would like to hear if anyone else has experienced it or has any suggestions.

Thanks, Neil.

 

[IrwinMFletcher]

Neil, one quick test would be to listen to voicemail on an ONS port. That would quickly eliminate any IP issues.

If you want to get a bit more complicated, you could play a tone into a recording and then pull that message off of the system and see if the suttering is in the record as well. Listening to that recording would be a good subjective way of determining the rate of the suttering. The voicemail application reads and sends 1 second buffers to the dsps, that then play it out onto the TDM bus.

I've used voicemail quite a bit and have only heard stuttering when the system is under heavy load and the voicemail task is contending for cpu.

What type of system (platform, MMC modules) and how many voicemail ports do you have?

 

[fissure]

Thanks Irwin,

the majority of the systems we're seeing it on are 3300 CXs, with either 1 x Quad BRI or 1 x ISDN30/PRI, and the default 4 voicemail ports.

I'd be surprised if more than 1 voicemail port was ever in use, and the issue had been experienced on a freshly booted system, out-with working hours (so system should have been near idle).

Some of the systems have no other MMC modules, and nothing fancy/complicated setup.

The person calling in, over ISDN2/ISDN30, can hear stutter in the outgoing default system prompts, at which point there is no IP involvement (other than within the Mitel chassis itself perhaps).

The key thing is, no audio issues are experienced whatsoever in actual phone calls, at any of the affected sites, implying the trunks/IP network are all working fine.

we'll try listening to, and recording some messages via ONS and see if/how they are affected


are there any CPU hogging tasks I can check for?

on one system, with PRI card at PLID 6 1 2 1
and:
Edt show tsp dbflags 6 1 2 1
said:
Debug flags disabled for link 1

which I believe means no 'edt trace' commands are running for example?

Neil.

 

[IrwinMFletcher]

That's right, there is no IP involvement within the chassis when dealing with digital trunks. Using the ONS though is the most direct route with the least number of variables.

There are a lot of tasks that run at the same or higher priority than voicemail, so it's not an easy thing to nail down, but if you experience it on an idle system then it shouldn't be a problem. There could however still be some initial misconfiguration that is causing some process to hog the processor every 10 seconds or so.

You could also try to install another dsp mmc module to 'move' the voicemail onto another physical dsp to eliminate that as a potential problem.

 

[fissure]

The solution to this......

unplug the serial cable from the maintenance port

At all the sites we'd upgraded to v9, and encountered the issue at, we'd used a serial cable to observe the upgrade (due to an FTP failure at one site, which we identified through the serial log, but which the Java Software Installation tool's log window didn't log), and we'd left the cable in place for future use.

Not expecting it to cause any issues..........

(kudos to Roger at Mitel who asked if we had a MAP or serial cable attached)

 

[kwbMitel]

you've got to be sh**ting me!

A serial cable causes voice distortion on embedded mail.

Well that's a new one for sure.

*******************************************************
Occam's Razor - All things being equal, the simplest solution is the right one.

 

[IrwinMFletcher]

It depends on what you have connected to the serial port, and the application that you use to monitor the port. The serial port runs at a very high priority and constant polling on it can cause delays in the system. I don't seem to have that problem with a PC and hyperterm but have heard of cases when a serial->IP dongle is attached.

You should however also heard the same stuttering when using group page or conferencing (i.e. any IP to TDM connections on the system). As I think it's priority is even higher than the E2T.

Just curious, did you do a ps of the system when you had the serial port connected?

 

[fissure]

Hi Irwin,

we hadn't done a ps but I had been wondering about the ability to do ps or top commands.

At one site, I believe we had a regular serial cable, to a Windows server, with Hyperterminal (I'd have doubted Hyperterminal was running all the time).

At other sites, we had our own wired RJ45 to DB9 adapters so the Mitels were plugged into AUX ports of Cisco routers (so we could 'reverse telnet' to the Cisco on a specific TCP/IP port, and be connected its AUX port, and hence to the Mitel, to observe the Mitel's maintenance output, particularly during software updates).

maybe we need to check what pins we had wired in terms of RTS / CTS in case that was exacerbating the issue

Neil.

 

[IrwinMFletcher]

The ps and top aren't what you think in terms of standard linux, but are VxWorks 'equivalents'.

The ps will show you the software components and the cpu usage in each. The top will create a 15 second event log that shows all the tasks in the system and what is running when. You'll need Tornado (VxWorks build environment) to view it, so it's typically something only the product support can analyze.

It could be the pin-out. I know some modems connected caused some problems as well.

 

[steveycarr]

Hi,

This might be a shot in the dark, but I'm in the UK and had a similar problem, are your sure your using the correct Country in the License Option Ass. Form. I left mine as US and had all kinds of speech stuttering issues. uLaw or aLaw options cause stuttering issues if not set correctly.

Steve

!ExtraDunce

 

[fissure]

Thanks Steve,

we did encounter that issue once, on ISDN30 calls in the UK, when the system was set to US, causing poor voice calls (due to alaw/ulaw as you say).

This time though, only voicemail was affected, and unplugging the serial cable from the maintenance port immediately resolved the issue.

Neil