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

I looked for the Diffserv, 802.11Q and P settings, and they were already disabled.

I also tried enabling NAT no peer to peer and it made no difference.

Looks like it's back to the drawing board.
Maybe I'll give wireshark a go.

Andy,
your problem might be a firmware issue on the MIPU cards. there was some knwo issues to cause intermittent audio on Stratanet calls.

I never did figure out this problem, however I do know that the firmware was just upgraded on those MIPU's in December or so for an audio related problem. The audio isn't intermittent, there's just a lack of it completely on the caller's end meaning the caller can't hear the person they called.

This only happens on our remote IPU's at other buildings that are connected via Tsunami wireless links.

I am pretty sure this came out in november, but you want the MIPU firmware to be MIPU01_19

"Audio will no longer be lost over StrataNet IP when the MIPU firmware sends an ARP request and waits for a reply to recover the ARP table. If the packet send request generated before a receive ARP reply, the MIPU firmware reads the MAC address from ARP table with all zeroes for the destination ethernet address. (Note: In Wireshark search for the following command, “eth.dst == 00:00:00:00:00:00”) (CTXR520-0064)."

Also in the DID tables try setting the data destination and the data digits to match the audio settings, I have seen that correct some strange issues in the past.

Well the data digits thing in the DID tables did not work.

My MIPU version is MIPU01_18DA200 on all IPU cards.

Looks a bit behind what you say it should be.
Does a dealer have to update it?

Interesting update on this...

I found that there is also a one way audio problem when I try to do an "announce" to a phone on one of the remote IPU's as well. A regular call where I actually pick it up on the remote end instead of pressing TALK locally and listening for the tone and then background noise works fine.

I'm beginning to think this problem and the problem plaguing incoming DID calls to these extensions on the remote IPU's are one in the same.

I'm also trying to set up Wireshark to watch the network for this: eth.dst == 00:00:00:00:00:00
to see if it is in fact that firmware problem.

I have it running on a computer that is connected to the voice vlan only, but I don't see the packets I'm looking for. I'm kind of a novice with it, so I'm not really sure how to set it up properly to watch for what I need to see.

Anyway, if anyone has an input that would be great...

wireshark will not capture the packets unless you and the IPU are plugged in thru a true HUB, not a Switch or you have a managed switch and you set a port to "mirror" the port that the IPU card is plugged into.

Ah Ha- of course...makes sense. Thanks.

Ok I went ahead and did some tests with Wireshark and I saw something interesting in there when I tried the announcing calls, and through the DID.
I was running Wireshark from a PC connected to a mirrored switch port at the remote building. I mirrored the port connected to the IPU in the CIX 40.

I was seeing ICMP Destination unreachable (port unreachable) or Type 3 Code 3. When I initiated the call, first a large ammount of UDP packets were passed until the call was answered, and from then on I would see mixed UDP and RTP which seemed to be fine, then here and there these ICMP errors popped up. Sometimes after I ended the call, but they occurred 17 times in the few moments I was capturing packets.

Basically from what I was able to gather in the details there was some sort of communication attempt between 192.168.14.8 which is the IPU at that remote building, and then 192.168.14.7 which is one of the IPU cards at the main building with the CIX 670.

In further detail it says the frame contained the following protocols eth:ip:icmp:ip:udp:data

I noticed the following in the info about UDP:
The source port was 20994 and the destination was 21016

Under internet protocol(there are two of them) on the first it says the source was 192.168.14.7 and destination was 192.168.14.8

On the second the source was 192.168.14.8(remote building IPU) destination was 192.168.14.7(main bulding )

Whenever I saw RTP packets they were always between the IPT at the remote site and the IPU (192.168.14.8) at the remote site.

UDP packets were always between the main building IPU and the remote building IPU. 192.168.14.7 was always the source, 192.168.14.8 was always the destination. Source ports and destination seemed to change but on this capture they were 21016 for source and 20994 for destination.

It did not seem to make a difference what way I called.

A call where I pressed talk and announced to another IPT did not work while a call where I let it ring and then picked it up worked just fine. On the calls where I announced I noticed there was NO audio passing either way. On DID calls to the remote IPT there was audio passing one way from the IPT to the caller's cell phone, but words spoken into the cell phone could not be heard on the IPT.

I did NOT see any ethernet destinations for an invalid mac or 00:00:00:00:00:00

Not once in any of the captures I did.


I'm not sure if any of this means anything to anyone, but hey, I'm bouncing ideas around....

I saved my capture so I can refer to it again if need be.

Hi Andy,
I'm new here so treat me nice! ;>)
Would I be correct in assuming that you are using just one MIPU card in each site to service both IP phones and IP network trunk (Stratanet) calls?
Every time we experience one way audio, it ALWAYS turns out to be a router or Port blocking problem. I'be willing to bet that if the CIX40 and the CIX670 were in the same room, and on the same subnet, you would not be having this problem. I'll bet there's nothing wrong with the telephone equipment. Do you have routers along with the wireless gear?