One way talk path

[84Mike]

We are suddenly getting complaints of one way talk path. As far as I know, it is only outbound. I have narrowed the problem down to a specfic trunk group with multiple PRI's. The problem is when we dial out, we can hear the person answer, but they cannot hear us. This is not every call, but happening a good bit.

Any ideas?

Thanks in advance for your help.

Mike

 

[mikeydidit]

What I normally do is put that call on hold, and call me on another line. I can then status their station "sta sta xxxx" and see what member they are on. You can also set up a "trunk id" button on you set with console permissions and If you hit one of those trunks in trouble, hit the trunk-id button and it will tell you the trunk group and member. It may only be one member or that whole group on that span. You can take it out of service and calls will route to the rest of the group until you get it fixed and not be getting those complaint calls.

"Wise men speak because they have something to say; Fools because they have to say something."
(Plato)

 

[84Mike]

I used my CDR to figure out where the calls are going. It is multiple channels, also multiple 464's in the same trunk group. Any other suggestions as to what may be causing the one-way talk path?

 

[AramHowe]

4602SW Firmware 1.8 has this issue under CM 1.3 environment. Others like codec mismatch, firewall also can be the root cause. Sometimes the problem can be fixed by turn off the shuffling on the phone.

 

[84Mike]

The problem is system-wide. Mostly 8410's. Even when the DCP port is in the same carrier as the PRI card it is using for outside line.

 

[mojoputter]

We had this problem a long time ago and what we discovered was the trunks in the trunk group were not in the right order from the CO. We had 3 T1's and we had them in different order them the CO did. This caused some other issues also.

 

[bhanson184]

It sounds like your interface ID's may not be matching what your vendors. I have had this problem in the past. You may need to ask the vendor what circuit is on which Interface ID and them check you signal groups to match them. It sounds like you will be rearranging circuits. I suggest doing this after hours because it will cause a service outage while moving the circuits around. I hope you only have a few T1's.

BHanson

 

[84Mike]

I just did a status on the sig group, and the 'Primary D-Channel' says 'Stand-by' and the 'Secondary D-Channel' says 'In-service'. I think mojoputter and bhanson184 may be onto something here with the order of the circuits. Will try to make changes tonight and go from there. I also have a call into the carrier to verify the order.

Thanks for your help. I will update after changes.

 

[bhanson184]

I've had this happen several times. Sometimes it was me and others it was the carrier. The PBX still likes the service and all show as in-service/idle but because the caller is talking on a different interface ID the the answering party, well it's like talking and nobody is listening. Like talking to my managers.

BHanson

 

[84Mike]

Changing the order of the interfaces only made things worse. I could place a call, but neither end could hear the other.

By the way, can we not do facility test call over PRI trunks?

 

[bhanson184]

You have to match the carrier. You may need to unplug all your T1's except where your D channels are. The D channels are probably interface ID 0 for the primary and if you have secondary backup interface ID 1 for it. From that point take what you believe is the next interface ID and re-connect it to the PBX. Make sure you have an outside test number. Call it and status your station to verify you are on the suspect T1. Next have your carrier force a call down that T1. You will need to do this for each T1.

 

[simreal]

You cannot place a test call over a PRI trunk. You MUST make sure you're interface ID's match the service provider. They should be able to tell you which circuit (by circuit ID or DHEC etc) is which interface 0, , 2, 3 etc. Some vendors skip interface 1 if there is only 1 d channel.

Another thing I have seen cause this problem is a bad medpro board. Verify you're medpro boards are in the correct network region.


You'll most likely have to setup a time to troubleshoot ... tell all of the agents to raise their hand when they get a bad call or one way audio. Tell them to keep the call active as long as possible and make sure to be ready and have someone relay their station id so you can get a status of the station.

Each time you get a bad call stat the station and record the CLAN, Medpro, and trunk resources the phone is using. Start building a table of bad calls. If you want you can also do this for good calls to help balance the info. If its a medpro you'll start to notice that all the bad calls seem to be occuring on a specific medpro board.

If you find that to be tru, campon-busy0out that board then see if the problems go away. If they do you can try reseating and or reseating that medpro but I have found that doesnt usually work. I support 11 S8700 and hundreds of Medpro boards and I see this problem about once a month.

 

[84Mike]

This issue has been very difficult to diagnose. I don't think it is a med-pro problem, because a bad call has originated from the same carrier the DS1 board is in. I have also checked out the interface ID's with the LD company.

We have several buildings on our campus, and we are not a call center type application. Therefore, I have to depend on someone to call or email me.

Suddenly, after a week, and having Tier 3 involved to trace, I can't get anyone to complain about this problem.

 

[telcomwork]

I had this problem with a fiber connection for 4 circuits connecting one of our EPN's. Turned out that the vender flipped the circuits so that 2 of the circuits (let's call them A and B) were plugged into the wrong extensal CSU/DSU.