Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MOH problem on tie calls. 3

Status
Not open for further replies.

datadump

Programmer
Dec 10, 2004
154
US
I don't even know where to begin troubleshooting this one:

At main site A , MOH works fine on both internal calls and calls received externally. However, when calls are made to/from site B or C across the ties and is placed on hold, site B or C hears a "screetching sound like a lizard jumping on a hot lamp bulb", as described by one employee. Obviously the problem is at the main site because sites B and C have no problem when calling each other. Again, this problem only manifests itself over the ties. MOH otherwise works fine on external and internal calls. Anyone ever experience this or have an ideas? TIA!
 
first thing that springs to mind is tennancy. Are the tie lines set to the wrong tennancy?
 
You're speaking over my head, lol. I don't know what tennancy is , let alone how to check for it. I'm not onsite at the moment but when I get back out there , I'll look in the manuals for a clue :D Thanks for the direction!
 
to see if the problem resides within the "TIE" lines turn off all MOH and place the call on hold still same "screetching sound like a lizard jumping on a hot lamp bulb"?

If so then the trouble is probably in the tie lines Are they through a channel bank, DAX or other type of generator or spliter?

Mextera.
 
Thank you both for your suggestions. I'll be trying them out tomorrow :D
 
Tie lines can be programmed unique MOH away from internal and CO calls. Confirm CM48 but Mextera is right. What I would do is re-produce the issue and unplug the MOH source to see if it stops or continues and go from there.
 
Update for everyone:

The tie trunks are actually peer to peer using the 32ipla card. Turns out the trouble is actually over at site B. I didn't know this but when Site A places a call with Site B on hold, Site B is listening to its own MOH, not the MOH from site A. I had assumed that the MOH they were hearing was Site A's. Makes sense now. You don't want your piddly 64k bandwith getting tied up with MOH services. Hope this helps the next guy out!
 
By the way, the way we finally realized this was I followed everyone's suggestions and removed MOH physically from the mp card and also in cmd 48. Site B was still hearing the lizard when I placed them on hold from Site A. Then we had site b call another station internally and place that on hold. Sure enough, the lizard was there ;D

Thanks to everyone for the guidance!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top