Mitel 3300 AX, problem with calls routing via AA and outgoing calls 1

[bigdave1980]

Hi all,

I'm looking at a Mitel AX which is using SIP trunks. 4 days ago, our customer started to have issues with incoming calls. There is a system speed call which points their main number at a VM multilevel auto attendant. There are 4 AA options, each of which points at a different ring group. When an AA option is selected it there is an announcement which says you are being transferred to xxxx department, then the call rings on the ring group member extensions. It has always worked fine but as of 4 days ago when the extensions answer the call there is just noise in both directions, white noise, like a de-tuned TV. If I point the system speed call directly at the exact same ring groups individually, by-passing the AA entirely, then it works fine. I thought therefore that the issue was with whatever is handling the AA, but they have since reported that they are also having problems with making outbound calls, and as soon as a call is answered they get the same noise. Outbound calls obviously don't traverse the AA. I can't understand why the problem would affect calls routing via the AA but not calls routing directly to the exact same ring groups. Does anybody have any suggestions as to what I may need to check here, please?

Thanks!

 

[AH64Armament]

How long has the system been running? I would restart the system and see if that resolves the issue.

If restarting the system isn't an option, you can issue the commands to stop and start the voicemail (I'm assuming that this is the Embedded Voicemail).

If the system is running MiVB 8.x and below, you can putty to RAW port 2002 and issue the following commands.
iPVM_Stop – stops the embedded Voicemail
iPVM_Start – starts the embedded Voicemail


If the system is running MiVB 9 and above, you can SSH to the controller.

issue mcdDebug to get into the RTC Shell -> command prompt and issue those same commands.

 

[bigdave1980]

How long has the system been running? I would restart the system and see if that resolves the issue.

If restarting the system isn't an option, you can issue the commands to stop and start the voicemail (I'm assuming that this is the Embedded Voicemail).

If the system is running MiVB 8.x and below, you can putty to RAW port 2002 and issue the following commands.
iPVM_Stop – stops the embedded Voicemail
iPVM_Start – starts the embedded Voicemail


If the system is running MiVB 9 and above, you can SSH to the controller.

issue mcdDebug to get into the RTC Shell -> command prompt and issue those same commands.

Hello @AH64Armament,

Thanks for those suggestions. The system was rebooted on Friday in an attempt to resolve the issue but it hasn't made any difference at all unfortunately. I was thinking it was probably something to do with the AA/embedded voicemail system as well, but strangely the problem is affecting outbound calls as well as inbound.

 

[AH64Armament]

In the SIP Peer Profile under SDP Options, Check the RTP Packetization Rate.
If you're using older Mitel telephones, you may have to adjust the rate to accommodate it.
default is 20ms
I had to make a change at one site to accommodate the older phones and/or AT&T SIP trunks. I believe AT&T had me change it to 30ms, but we were getting similar results that you are - but only on the older phones.

I just checked the setting on that site, and it is set to 20ms.

Mitel's KB article SO6942 shows a similar issue where they had it set to 40ms.

 

[bigdave1980]

In the SIP Peer Profile under SDP Options, Check the RTP Packetization Rate.
If you're using older Mitel telephones, you may have to adjust the rate to accommodate it.
default is 20ms
I had to make a change at one site to accommodate the older phones and/or AT&T SIP trunks. I believe AT&T had me change it to 30ms, but we were getting similar results that you are - but only on the older phones.

I just checked the setting on that site, and it is set to 20ms.

Mitel's KB article SO6942 shows a similar issue where they had it set to 40ms.

I've just checked that as you suggested and it's set to 20ms. Actually there are 2 SIP peer profiles as the system uses a resilient SIP endpoint, but both profiles are set to 20ms. I selected the option to override the RTP packetization rate and tried to change it to 30ms just to test it, but I got an error message saying:

"One or more errors were encountered during form validation: -->Confirmed 'Confirm Password' must match original."

But I haven't changed any of the passwords etc in the SIP peer profiles. All I've done is tried to change the RTP packetization rate as mentioned above. So I cancelled out of it without making any further changes and left the RTP rate set at 20ms for now.

 

[AH64Armament]

Some browsers, when you edit a form that contains a username and password that you have saved, it will auto-fill those fields. Clear out the saved password to the system and try again.

Some things that might also be helpful:
3300/MCD/MiVB software version - the fact that it is an AX controller isn't really helpful unless it pertains to the cards contained in the system.
SIP carrier - don't need details on account info, just the overview.
Is this going through an SBC such as MiVoice Border Gateway?
Did this issue just start? If so, when? and did anything change on the MiVB end?

 

[floppy1]

Hi

I just had the same issue It turns out the line provider Gamma migrated the endpoint to enhanced.

I Disabled Enable Mitel Proprietary SDP in SIP peer profile and this issue is now resolved. This may work for you ?

 

[bigdave1980]

Hi

I just had the same issue It turns out the line provider Gamma migrated the endpoint to enhanced.

I Disabled Enable Mitel Proprietary SDP in SIP peer profile and this issue is now resolved. This may work for you ?

Hi floppy1,

Yes that seems to have done the trick, thanks for that!

 

[The mitel guy]

Mitel is known to be a rock steady system usually when issues like these occur it's nine times out of 10 the providers fault. By that I mean the service provider that's providing your connect to the pstn. I would always bark up their asses before I look into the phone system because 9 times out of 10 it's their fault.