atcomsystems.ca/forum Forums TDM Business Telephone Systems Toshiba Telephones & Systems DID problem

I'm relatively new as well so no worries about getting any crap from me...I'm always grateful to receive responses!

Anyway, what we've got at our "main building" if you will is a CIX 670 with two IPU cards in it. One is addressed 192.168.14.6 and the other 192.168.14.7 respectively. As far as the Stratanet goes, node 11, which is the 670 is only listed with the ip route of 192.168.14.7 which I thought was a little weird since there are two IPU's in that, but eh...maybe it doesn't matter?

At the remote sites (there are two of them) we have CIX 40's and the remote sites are networked to the main site with one Tsunami Wireless bridge each. No routers. I do have an inter vlan router I recently set up, but this problem was persisting long before. The data and voice networks are somewhat seperate. There are two vlans one for data, one for voice. All the phones are obviously all on the same subnet.

I've not seen the Tsunami's ever block any kind of traffic, but I'm not an expert with those either. I also confirmed that by setting up a phone from the main building(connecting to an IPU from the main building at the remote site) over at one of the remote sites. It worked fine. No audio loss in any case. I would have to think if it was the Tsunami blocking traffic, I would have experienced problems with audio loss.

All of the routers we have with the exception of the inter vlan one are on the data subnet, and have nothing to do with the phone systems.

It seems as though regardless Wireshark is telling me that something's not able to get through someplace. I'm left to believe it has to be the CIX 40 IPU talking to the IPU on the 670. The ICMP errors I was seeing in Wireshark and mentioned above looked like it had a lot to do with those two IPU cards. Those being 192.168.14.7 at the main site with the 670 and 192.168.14.8 at the remote site with the 40.

Andy, I had a similar problem at a multi site customer They had a cix670 and three cix40's

they would get one way audio, the problem was the wrong gateway was set on the mipu cards at the remote ends. I could take an ip phone from the remote and plug in at the main and everything worked fine.

i could ping everything and i could call the remote but would loose the audio

check all locations and make sure the gateways on the mipu/lipus are correct. just a shot

Hey, glad to see you gave wireshark a try. I'm busy packing so I can't take a lot of time to try to figure out all the information you posted, but I hope it at least points you to the cards that are having trouble talking to each other. This should give you an idea of how the communications travels from point to point.

Like Canukvoip said it is almost always something blocking the data stream. The 1st hard part is finding out what is blocking it. The harder part is fixing it.

Are your Tsunami's configurable as to whether they pass broadcast traffic? If they're blocking ARP you could get this.

It might be productive to set up a *pair* of wiresharks on each side of the bridge, and make sure their clocks are both NTP synced to something, and then compare the traffic you see.

Got all the IPU's on the same gateway. Previously they had no gateways assigned but I did assign them each the same gateway because I started testing a remote IP phone over the internet awhile back.

This problem goes back to before then, so I'm not sure it has much to do with that. I could be wrong though!

Something's not right somewhere however with the audio stream. It's fine from IPT to IPT on the calls(when both people on the call are using the receiver and not voice first announcing) over the stratanet from like the remote building to the main building and the opposite. It's just when you try to announce to an IPT extension at the remote building that you get no audio at all. BUT you CAN announce from the remote building to an IPT at the main building...which is weird.

Externally you get one way audio on DID calls to the extensions at the remote buildings. The only person who can hear anything is the outside caller.

So I'm going to sound a bit like Dr. House here but..."What causes the following symptoms?" lol

Here's a quick summary

1.Audio working fine on calls where the caller picks up the receiver on the IPT at the remote building and dials, and the other person answers. It also works the same if you dial from the main to the remote the same exact way.

2.Audio does not work at all when you dial an IPT's extension at the main building from the remote building and press TALK to "announce" to that extension. No warning tone is heard, and no audio is heard through the speaker from the other end, and no audio is heard through the IPT that was dialed/called. So basically, no audio at all. Even if you then pick up the receiver at either end you still have nothing.

3.When a DID number is assigned to an extension at a remote building and it is dialed from the outside, the phone rings and displays the caller ID with no problem, however when you answer it you can't hear the caller. However, they can hear you just fine.

4.Wireshark captures revealed that when a call placed through said DID from #3, there were ICMP errors logged and somewhere..somehow...we've got 17 instances of Type 3 Code 3 Destination unreachable (port unreachable) for these port numbers that are UDP: The source port was 20994 and the destination was 21016. This was logged from a communication between the IPU at the remote side and the IPU at the main side.

Refering to 4.
For sure, something is blocking those ports. The ICMP errors thing bugs me. I thought ICMP referred to ping...
I maintain that if you took the CIX 40 and plugged it into the same L2 switch that the CIX670 was in, or if you used a cross over cable and plugged the two MIPU cards together, it would work first time/every time.
There's something on the network blocking ports me thinks lads.

I have a stupid question.
What is the DHCP server for the phones?
And, are there any other "rogue" DHCP server devices on the site that you may or may not know about?
If the phone got an address from an incorrect device, the gateway might be wrong.
If you went to an IP phone on the CIX670 site and checked the IP address/Subnet/Gateway you could compare that to a phone on the remote site.
Might shed some light on the subject!

Canuckvoip,

The DHCP server for the phones is running off of the "backbone" switch. There are about 7 of these Adtran NetVanta managed switches total between all three buildings. Only one gives out DHCP though. It gives out IP's for 192.168.14.0/24 and then a default gateway of 192.168.14.4 which is my inter vlan router. On the other side of that router is the data network or Vlan 1, which is 192.168.4.0/24- The DHCP server for that network runs off of a Windows DHCP server.

DHCP server is off on the Tsunami wireless bridges and each has a static address on the data vlan. That seems to have no bearing because if it did my main building phone wouldn't work at the remote building.

The phones at the remote buildings would all have the same gateway because they receive it from DHCP. I programmed a phone from the remote building and I have it over here at the main building. It's aimed at the IPU from that remote building. I verified that it's gateway, etc were correct. I have tested a phone from the main building over at a remote building as well. Aiming that one at the main building's IPU. There's no audio problems meaning the problem seems to be directly with the IPU at the remote building talking to the one at the main building. Using the phone from the main building at the remote building verifies that when the IPU on the CIX 40 is out of the mix, no trouble. As soon as we need to initiate communication between the IPU's at the main building and then the ones at the remote buildings...then there's problems.

Just another thought on this....

I remember when we first put this phone system in there was somewhat of a complaint from the folks who work in these remote buildings that they didn't want anyone to be able to "yell" at them through the phone. They would have been talking about the feature to press TALK and do a voice announce. I'm not sure what became of it, but I've noticed we can do a setting on our system that will allow the voice first announce. These settings work fine here at the main building. I set the parameter under 204-05 on a phone at the remote building and its like it completely ignores it. When I dial the remote extension from the main building it still does tone first! Is there any way that this could have been completely disabled? In a sense that anyone doing a voice announce from the main building to a remote one just wouldn't be able to make it happen? It seems if you dial from one extension to another within the remote building voice announce works fine, but from the main to the remote you get silence and nothing happens, though the phone does display "CALLING 407" then "ANNOUNCE TO 1200 CONFERENCE" once the connection has been established.

Re: Just another thought on this....

Andy, I have to admit that I haven't had experience with this personally. That being said, the way Toshiba (and others) network systems together via ethernet is called Qsig.
Qsig was and still is available on PRI (TDM) and now on ethernet/Wan/extended Lan connections.
It is "kind of like Tapi" in that there are a defined/limited number of features available. Things like M/W lights, caller ID etc passed between systems.
It was meant as a way for multiple systems to "feel" as if they were on one system.
Not all features are going to be passed between systems. Period!
Each site has its own processor, so if the voice first/tone first info is not passed via Qsig it won't have any effect on the destination processor (CIX670 to CIX40).
So, (unless I'm reading this wrong), the feature enabled on the CIX40 will affect those CIX40 callers calling other CIX40 users ON THE SAME CPU/SYSTEM.
Same like same on the main CIX670 site.
This I believe has no bearing on the one way voice situation on the network overall.
I think...
Dave