Gxw45xx troubleshooting

#1

I bashing my head against the wall working with the local incumbent telco. I’ve been here before and think I’ve posted about but, here we go again.

GXW4504

  • Has been working perfectly for months.
  • PRI outage on Friday, service down for 7 hours.
  • PRI restored.
  • Not getting all calls. Maybe 20% of test calls are getting through.
  • Office really needs high uptime so, we swap to the cold spare. Identically programmed so, when we move the PRI cables, lan cable and power, the network sees the cold spare at the same IP address, everything should work nice. Rather than rebooting the device periodically, we will swap to the other device. Because of this history, I know that both devices are programmed correctly and the swapping process works perfectly.
  • Even though calls only started dropping after the PRI was down on Friday, the incumbent telco is telling me it’s my equipment that’s the problem. Even though I’ve swapped to the cold spare for about 18 hours and back to the primary unit since then.
  • Telco busied out the first B channel on the PRI and calls are routing correctly. I’m really at a loss at this point. They are still telling me it’s my equipment causing the issue.

So, in fairness…

  1. How can I test this? There is no function on the GXW4504 to simply disable a channel (or is there?).
  2. How can I prove what the issue actually is? I’ve looked at the various option under Signaling Troubleshooting but, I’m not sure where to start. I’m looking for something, pcap or text file or other, where I can actually look as see what’s going on.

image
image.png785x193 13.6 KB

Would anyone here consider themselves an expert on this subject matter and be interested in being hired as a consultant?

#2

Additionally, if anyone has the knowledge, I’d love to learn more about PRI in general. With SIP, yes, we talk about channels but, I don’t think one channel could go bad. I could imagine that a firewall stops routing over a certain RTP port correctly and, every time the system negotiates which port to use, the call could fail when that port is used.

But, PRI, I just get the Ethernet cable from the telco equipment and connect it. I know there are some settings I could play with but I’ve been fortunate enough that the GS equipment seems to work with Bell MTS pretty much out of the box. No problems with any of the 6510’s I’ve installed.

#3

James,

Sounds like you are experiencing some form of timing issue between the master and slave.

Telco - Ethernet --> GXW45xx --> ISDN Pri of system

Now it could be as simple as the system connected to is losing time on its ISDN clock - I have seen that in an early NEC PBX where it would lose microseconds then it would start dropping some calls before cascade failure where no calls would be able to come in or out.

If that symptom sounds similar then you may need to reboot what the 65xx is providing the ISDN to.

Kev

#4

Hey Kevin,

I’m confused which device to reboot.

Telco -> GXW4504 -> Internet -> Cloud hosted service.

The calls are not, insofar as I can see, even making it to the GXW4504.

#5

Hi James, is the GXW4504 in master or slave clock mode ? I wasnt sure how your set up was to be honest.

Until you wrote " Telco -> GXW4504 -> Internet -> Cloud hosted service."

#6

So the telco provides ISDN to you --> then to the PRI interface of the GXW4504 --> then SIP to the SIP hosting server.

So in that your GXW4504 is the slave PRI clock to the telcos master PRI clock. Still sounds like clocking is failing.

#7

Does the Telco provide ISDN over copper pairs to you direct or is it delivered over some sort of internet connection ?

#8

Over a copper pair.

#9

Would it be random problems? Seems odd that it worked for so long and only became an issue after the outage a couple days ago.

The Telco is aggressively pushing that the Grandstream equipment is at fault. But, both units having the same issue after the outage? Still, I’m more interested in resolving this.

Can you advise which device should be the master or is that a question for the Telco?

#10

The Telco - usually is the Master clock - that your device is a slave clock to - but as I said it is the clocking that seems to be slipping. Ask them to verify that the Clock is not losing time over a period. You may have to ask for GS to assist with being able to packet capture this fault.

#11

In my recent struggles with a Bell PRI on a UCM6510, the issue in my case actually ended up being the grandstream PBX. In my case the PBX was sending the wrong message back to the telco when a GXW4248 FXS port was busy, and I was able to find a workaround on the UCM (which they are still running with because grandstream engineering closed the ticket).

Anyway, run the PRI test and have a look at it. Its a lot like a wireshark and you can see calls being setup and torn down. I had the bell tech go through some of it with me which taught me some things.

There’s a channel time or packet time - i cant remember at the moment, i’ll comment further if I can find it - 20ms or 40ms that needs to match, and the PRI test can show if this is off because it will be in the messages between the 2 systems.

#12

Thanks Marty,

Looking forward to your update.

#13

Hey @martyatherton

Should I be looking at one of these options?

image
image.png793x290 16.1 KB

#14

Hey James, yeah run the pri trace, inbound, outbound, and look at the pri logs.
I’m flying to Ottawa tomorrow morning but can look at a log if you get a chance. (As a standard now when I install one I do a pri log when it’s working to save just in case as a baseline, haven’t used it yet because I just started doing it)
I’ve got a few log captures from a 6510 I could send to use as a reference, I’ve not yet installed a gxw450x…

#15

Ask provider if they change anything. Maybe their PRI got destroyed and they replaced with new and setting are not correct. As for logs: depend which one you use (i guess PRI) ? you can find it in E1/T1 settings.

You can sent me log via pm, with info which number call to what and when failed.
But signaling is very similar to SIP.

@martyatherton 45xx is basically UCM (with reduced menu).