One way audio on external calls mitel 3300 4

[topazdemon]

Has anyone experienced one way audio issues with the mitel 3300 system?

We have issues with external callers not being able to hear us, or we can't hear them, but if they call back, there is no problem.

The problem occurs on both long distance and local circuits, so I definitely think this is a VOIP issue.

Does anyone have any suggested troubleshooting steps?

Thanks

 

[wireman50]

It would probably help to tell us how the lines are being delivered, the type of system and software level for a start....

 

[danramirez]

Are those SIP Trunks? If yes, are you using an MBG as a SIP Proxy? or are you using a SIP aware firewall as border controller? Please provide further description as wireman is asking

http://www.hatkana.com

http://www.wtelecom.com

 

[LoopyLou]

As wireman50 says please supply more info. Specifically the controller type and its sofware level. Then describe the type of trunking you are using and how it connects to the controller. Do you know if you use the same trunks going out as those you would recieve calls on?

It is not necessarily a VoIP problem unless you consider the network and firewall as VoIP.

In case of copper and PRI trunks all communincations on the trunks goes through the 3300 controller so it could be the controller itself. However it also could be there are routing issues on your network that are preventing audio from your sets getting to the controller. You would also experience this on calls to the embedded voicemail but might no see it on calls between IP sets.

In the case of SIP trunks once the call is setup by the controller then all audio goes from the sets to the SIP trunk gateway. This can be an MBG or a device supplied by the SIP trunk provider or simply might be your internet firewall. Many times firewall issues result in one way audio.

Have the trunks every worked properly.





I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[wireman50]

I thought that once the call was up on SIP the media streamed via RTP and therefore was between the endpoint and the trunk provider.....? The 3300 only controls in call options once the call is established?

I agree with the one way audio thing as well; wonder if someone has turned SIP awareness on and the trunks don't need it (as it often causes more problems than it solves....)

 

[LoopyLou]

Wireman50 you are correct. I thought that is what I said. Anyway we need to know more about the trunks before we can help. Step one for topezdemon is to supply more info.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[topazdemon]

Good morning everyone, apologies for my latency, I've been off for a few days.

It would probably help to tell us how the lines are being delivered, the type of system and software level for a start....


The system type is a Mitel 3300 MXe Primary/Secondary controller. We are using ASU units and Audio Codes MPX 11x VOIP gateways for our analog needs. The underlying network architecture is HP Procurve technology.

The software information is:

Release level: 5.0 SP1 PR1
Active Software Load: 11.0.1.26
Inactive Software Load: 10.1.1.11_2
System Relink: no relink has been applied
Call control relink: 41.0.1.14_SP1
Platform MXe 512 MB of RAM

I don't understand what you mean by how the lines are being delivered, but if you give some further detail I'll find out

Are those SIP Trunks? If yes, are you using an MBG as a SIP Proxy? or are you using a SIP aware firewall as border controller? Please provide further description as wireman is asking

I'm sorry telecom is not my first game, I'm a backup for someone in the military right now. The trunks are being fed from 3 smart jacks in our server room. These smart jacks plug into the controller t1/e1 cards via copper and the secondary is connected via copper as well. I think they are PRI.

No SIP firewall, this system is on it's own infrastructure and only uses an external internet connection when troubleshooting is needed.

Do you know if you use the same trunks going out as those you would receive calls on?
Yes the incoming/outgoing are the same

It is not necessarily a VoIP problem unless you consider the network and firewall as VoIP.
Sorry, I generalized this in my head, our VOIP network is an entirely separate infrastructure. I understand the issue could be the underlying data network. There is no firewall.

You would also experience this on calls to the embedded voicemail but might no see it on calls between IP sets.

To my knowledge we have not seen this issue with the Nupoint voicemail system, nor internal -> internal calls.

Have the trunks every worked properly.
Yes they didn't always do this, but the time frame is fuzzy since we have 1 person supporting 18 buildings and 300+ people, and not all incidents get reported correctly. We recently (a few months ago) upgraded the controller software to the latest version at that time. Also, we have had the system for almost 3 years now, so hardware may be failing. The issue seems to be getting progressively worse though.

Thanks to all of you for your help, and I will do my best to provide all the information you need for analysis/tips.

 

[IrwinMFletcher]

So in my mind, I picture wires coming in from the outside world and they are connected to the MCD through a CIM card. Going out of the MCD, you have some ASUs that are supplying some analog extensions. You also have the MCD connected to your internal network, and off of it, there are some Audio Codes boxes that are then connected to yet more analog extensions. Correct?

Further questions:
1. Do you have any IP phones on your system, or are they all analog?
2. Which extensions get the one-way audio? I'm guessing just the analog extensions off of the Audio Codes, correct?
3. Is this repeatable and consistent? (does it always happen)
4. Have you tried creating a conference from a phone that has the issue?

 

[wireman50]

I think they are PRI lines (the copper bit) being delivered over fibre (the smart jacks?) so you have two points of failure....but I suspect an issue with the way the lines are being delivered. Can you get any more info on the lines (they may be SIP being gateway'd from a SIP gateway and being delivered by copper rather than being directly programmed in as sip lines (to save on buying SIP licences when you have E1/T1 cards in the system anyway.

 

[topazdemon]

So in my mind, I picture wires coming in from the outside world and they are connected to the MCD through a CIM card.
Correct


Going out of the MCD, you have some ASUs that are supplying some analog extensions. You also have the MCD connected to your internal network, and off of it, there are some Audio Codes boxes that are then connected to yet more analog extensions. Correct?
Correct

Further questions:
1. Do you have any IP phones on your system, or are they all analog?

Yes we have several hundred IP phones

2. Which extensions get the one-way audio? I'm guessing just the analog extensions off of the Audio Codes, correct?
The extension that gets one way audio is usually random, but no, it happens on IP sets. I haven't seen it on analog sets, but they are much less common. We did get an echo on a polycom phone, which my manager (who used to be telecom) thinks is related to the syncing issue.

3. Is this repeatable and consistent? (does it always happen)
Repeatable yes, consistent no. Random extensions, random time of day, random external number. I can repeat it by calling about nine or more times on my office phone to my cell phone. On the ninth time I got the issue last I tested.

4. Have you tried creating a conference from a phone that has the issue?
Do you mean conference in another extension? If that is what you mean, then no. I can try it, what will it show (just curious)?

I think they are PRI lines (the copper bit) being delivered over fibre (the smart jacks?)
I believe the fibre comes in via fiber from the carrier (it's yellow so maybe single mode?). It hits this shelf that has cards that slide in and out. Then this shelf is tied through a "patch panel" that uses pins that have wires twisted down to them. I'm not sure what this is. Then the smart jack is tied to this and feeds the phone system via an ethernet connection out.

so you have two points of failure....but I suspect an issue with the way the lines are being delivered. Can you get any more info on the lines (they may be SIP being gateway'd from a SIP gateway and being delivered by copper rather than being directly programmed in as sip lines (to save on buying SIP licences when you have E1/T1 cards in the system anyway.

Would this information come from the phone company or is it something I can look at locally? I do know that the same setup (maybe minus the smart jacks) was used with our old PBX years ago that was analog based. A Nortel I think.

 

[kwbMitel]

My 2 Bits

Due to the randomness, I would suspect a bad channel/trunk that is only engaged during higher traffic times or if trunk selection is circular, once every X times.

My methods of troubleshooting would include:
- Turning on traffic study (compare peg counts and time for each trunk)
- Turning on SMDR (ask users to report time and date of each incidence)
- Accessing every trunk manually from 1 station (proactively test)

**********************************************
What's most important is that you realise ... There is no spoon.

 

[wireman50]

+1 with kwbMitel here. although I would start at point three (access every trunk manually).

You should be able to ask your line provider (ohone company) what/how many trunks you have and their method of delivery

 

[topazdemon]

Due to the randomness, I would suspect a bad channel/trunk that is only engaged during higher traffic times or if trunk selection is circular, once every X times.

My methods of troubleshooting would include:
- Turning on traffic study (compare peg counts and time for each trunk)
- Turning on SMDR (ask users to report time and date of each incidence)
- Accessing every trunk manually from 1 station (proactively test)

+1 with kwbMitel here. although I would start at point three (access every trunk manually).

Thanks to both of you for your input. How do I perform these 3 tests? Please bear with me, I am new to the game, and while I remember most of what I learn, there are many things I haven't learned yet.

I have asked users to report the date and time of each incidence, but so far, I only have one real instance that was reported in enough detail plus the additional times that I recreate the issue.

You should be able to ask your line provider (ohone company) what/how many trunks you have and their method of delivery
I will do this either this afternoon or tomorrow morning. I should be able to get in touch with the local techs.

 

[IrwinMFletcher]

4. Have you tried creating a conference from a phone that has the issue?
Do you mean conference in another extension? If that is what you mean, then no. I can try it, what will it show (just curious)?

The idea here was to see if there was an issue with the IP streaming. In your setup, IP phones will stream to the MCD and there it will be converted to TDM to be sent out the trunks (and vice-versa). This is the functionality of the E2T (Ethernet-to-TDM) within the controller. Conferences also connect to the controller in the same manner, all sets stream to the controller and it's mixed there. The difference being that in the conference case, the trunks are not involved. So if you try some conferences, and you get the same problem, then you know the trunks are not involved. If you can do conferences ok, then it points to the trunks.

But as others have mentioned, since it's more of a random issue, I would check the trunks first since it's an easier test. Note though that it still may be an IP issue since the ports that the E2T uses are also circular, as are the hardware echo cancellers, etc...

 

[topazdemon]

Just got off the phone with Mitel, they had me DTSTAT READ the circuits for the last 24 hours to check for "slipping", but no dice. They are setting up a vendor meet with our provider

 

[LoopyLou]

Think as others suggest it is probably in the Telco. A few years back on an SX2000 we had something similiar. We spent hours in testing but were able to get a call with one way audio between a tech on site and a tech in our office. We then called the carrier who was able to jump on the PRI channel to confirm one way audio. They then went off to trace the call and found that the issue was acutally on their link out of the CO to the next CO in line. In other words the PRI was fine it was a bad channel out in their inter CO switching gear. What a bear to find. The one way depended on how the call came to the local CO and hitting that exact bad channel.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[topazdemon]

Just for completion I wanted to let you all know this issue was in the phone system. There was no issue identified directly, but the Mitel tech recreated a one way call (by calling over and over) and placed it on hold. When he brought it back, the audio was fine and he admitted it was the system. They had me do a save/restore restart on the 3300 and it seemed to fix the issue at least for now.

Thanks for all the tips!