Magix issue - random inbound calls are one-way audio.

[telewhore]

Hey, I'm servicing a Merlin Magix system that the customer reported a few weeks ago that calls would come inbound and they could not hear the caller on the other end or vice versa. This does not seem to be happening for outbound calls. I swapped out the 100 DS1 module as I received error "invalid sanity response" thinking that the card is going bad. The problem still persists after swapping out the DS1 board. Help!

Thanks in advance,
Chris

 

[Telecomboy]

1-way audio is usually a telco issue when it comes to the Magix. Those 100DS1 cards either work or don't, they don't have 1-way audio on some calls. I would contact their service provider and have them check their end.

It is possible the service provider is also programmed differently than the Magix. Make sure they are not programmed as NI2 for the PRI.

 

[telewhore]

Would the service provider make that protocol change unannounced? The customer didn't change anything nor have any change requests in queue. They had called the provider before me (PBX tech) and the provider tested clean from their end, although they didn't come out to the site location for testing.

 

[merlinman]

They shouldn't, but sometimes they do. NI1 is not used by many other systems than the LEGEND/MAGIX, so they think NI2 is ALWAYS correct. This can happen when they do a SOFTWARE Update in their Central Office or what ever they have now.

http://merlinmanswebpage.yolasite.com

 

[critchey]

I had a friend run into a somewhat similar issue. Service went down for a few days. Once it came back up it was pretty randomly working or failing. Ended up calling provider again and asked what the switch type was set and sure enough it was NI2. So even with no feedback from customer the provider can randomly change settings it does happen. Id suggest calling and asking them settings, I find if you ask is it set to this they will just say yes.

 

[Telecomboy]

Yes, as Merlinman said it usually happens during an update of their equipment. Because NI2 is the standard it ends up getting set back to NI2.

 

[telewhore]

Just verified with provider that the protocol is set to 5ESS. I'm pretty sure that is what the magix is also set with. I'm told that no change has been made on circuit since 2013.

 

[merlinman]

I'd be willing to bet they did change it, but who you're speaking with just doesn't know it. They are probably seeing that there was no SERVICE ORDER recorded to make a change and probably have no idea of a system update. That's my story and I'm sticking to it.......

http://merlinmanswebpage.yolasite.com

 

[critchey]

Did you try it after talking to them? I have, more times then I can count, had providers tell me settings are fine and they made no changes but it magically works after talking to them.

 

[Telecomboy]

I again agree with Merlinman. The person you are talking to on the phone is looking at their records of how the PRI was configured. They are not actually connecting to the current programming of the PRI or router to verify it is set properly. I have had this happen too many times to count. The first person swears it is not set as NI2. Then they get an actual engineer involved to look at the circuit and they discover it is indeed set to NI2.

 

[telewhore]

Well, I just finally spoke with an engineer and he indeed says the same thing, the setting is for 5ESS.

 

[telewhore]

I forgot to also mention that the provider came out onsite this past Thursday (today's Monday) to swap out the router, so now they are using a more updated router. The issue seemed to have still surfaced even after the new router was installed...

Also, I failed to check the system errors/alarms after putting in the new DS1 board to see if the "invalid sanity response" cleared. Not sure how much insight the answer will bring but I hope to get this info at some point tomorrow.

 

[merlinman]

Well, sometimes 5ESS is enough to make it work, sometimes not.

That being said, do clear all errors and see if it comes back to life.

Those cobwebs need to be out of there for sure........

http://merlinmanswebpage.yolasite.com

 

[Dexman]

Has anyone used a protocol analyzer to trap messages on the "D" channel to check for various errors during the entire call process

I "FEATURE 00"

http://dexman.webs.com/

 

[telewhore]

I finally have an update - All errors have been cleared as of a few weeks ago. Supposedly the occurrence of issue is happening less than it was according to the receptionist who experiences the issue. So in the course of a week, the issue surfaced 2 times on Wed, 2 times on Thurs, 0 times on Friday and Monday, and 1 time each on Tues and Wed.
So I guess the problem is somewhat tolerable but now I just got a new update from the customer - "Some calls are coming in randomly and they sound choppy. Also, calls sent to one of our extensions (3062) come in very staticky." I will be heading out to the site tomorrow to investigate these new issues. Something tells me its related to the original issue which hasn't been totally extinguished.

Dexman, can I ask the provider to do a protocol analyzation on the D Channel?

 

[Dexman]

Msny IXC/CLECs should be able to trap messages on the D channel.

I...myself...was an IXC/CLEC C.O. technician for 23 years before bring laid off due to a merger. Many was the time I wished that interconnects provided analyzers to their field techs (some did but most didn't), but, that is a discussion for another day.

I "FEATURE 00"

http://dexman.webs.com/

 

[wireboy]

one: distinctly label the channels and look for consistent channel associated complaints.
the theory being if a span is up, everything on the span works end to end. not!

two: are voip conversion,router programming or cell phones involved?

three: if a corporate entity or networked site is involved in any way, network changes (number of assigned working channels may vary between end points or c.o.)
may or may not be a part of service provider records.





42