Hello everyone,

I have onsite a CIX 670 system with a few 16 port IP Cards. Our remote site connected via Site To Site VPN has about 20 IP phones (IP5022) connected. We had some speed issues on the remote end earlier today and it turns out within a matter of just a few minutes several of the Toshiba IP phones connected to there perspective IP cards here at the main site and transferred a bunch of data. Around 10 phones transferring 6 gigs in just a few minutes. Pulling logs from the firewall I see the most significant data traffic was over TCP port 2944 which looks to be part of the telephony system as mentioned here. https://wiki.wireshark.org/H248/MEGACO . Anyone have any idea what could be causing this ? Perhaps some type of firmware upgrade trying to be pushed by the system? I doubt its phone(talk) traffic since I usually see that on upper UDP ports. I changed all the codecs for those phones in emanager from G711 to G729A in hopes that it helps. Which I doubt since again the phone traffic should be UDP not TCP. Anyway I was hoping maybe some otehrs have had similar issues and could give me some info on what to do troubleshoot or correct it. There are no Vlans or QOS in place to prioritize any of the traffic so that could also cause problems.

Thank you in advance for any help.

TCP 2944 is the Megaco protocol for IPT handset key data (this gives you all the handset DSS/Line key information only)
Changing the codec to G729 will not make any difference to the TCP 2944 traffic.

I cannot see that they would have used 6GB of data in a few minutes are you sure that is correct?

I have seen a lot of Toshiba wireshark captures, and the amount of data on port 2944 is very minor, and and typically used when the phone first registers. The data sent is no more then about 700 Bytes total. Even with a larger (50+) phone deployment I the data traffic this port isn't much more then a few KB when rebooting all the phones at the same time. Once registered the phones barely send any more data using this port.

Port 2944 doesn't have anything to due with the actual VoIP audio, so G.711 and G.729A won't change the amount of data it uses.

I have to believe that something doesn't add up at all with this firewall report. Can you do a pcap capture of the data coming from the phones? I would be extremely surprised if this port uses more then a few KB after a phone reboot.

Thank you both for your replies! It is an intermittent issue not a constant one. I got the port and usage information from Sonicwall Analyzer and it wouldn't be the first time I questioned the accuracy of the analyzer software. Users have complained that sometimes when we use paging on the main site that the phones dropout and restart at the remote site. All of the phones at the remote site are powered directly and not via POE so that rules that out as a possible issue. We have other IP phones here at the main site and they don't drop out at the same time (If ever) so I don't think its the IP card itself in the Strata. As far as the amount of bandwidth used by the port, I also find it odd that there would be that much data from the phones themselves. Perhaps they keep restarting over and over and are having some issue connecting that causes the data to send over and over but again if the data is so minimal I still don't see why starting even over and over in a couple minutes would be that much. I will take your advice and check into it further. One other bit of information just in case the question were to arise is that the vpn between sites is connected via a 15 Meg MPLS connection. I am only mentioning that because I know people have told me in the past that wireless (Or as our backup service provider tries to pass it off - Fiber to Wireless) Service often times has to much latency for the Voip system to function well and I wanted to make sure that is ruled out.

Happened again this morning. Not nearly as much data but still 500mb in a minute is quite significant for 5 phones (Initiator IP's) the 3 responder addresses are the ip cards in the strata. I also dropped an image of the whole days activity at the bottom from that location but none of the activity peaks like the phone traffic for those ports this morning.

[img]https://ibb.co/wWrnT1P[/img]

If you do a page to all the remote handsets you will chew up loads of bandwidth the same as all the phones in use at the same time as well as TCP 2944 traffic as this is the Megaco information to all the handsets including the LCD display information.
The handsets should not be resetting themselves do you have the IPU mode set to "broadcast or manual" on the handsets?

Broadcast.

Change them to "manual" and they should stop resetting themselves.
Are you able to monitor the bandwidth used at the firewall before and after an all call page?

Yes I can monitor this on the firewall. I will test it. I bet you hit the nail on the head with your answer.

So I ran a test of 3 pages this morning and didn't see any significant TCP traffic even on port 2944. I did manage to capture significant UDP traffic (PORT 16XXX PORTS) during the paging. But it was less than 600 KBPS. I will be going over to the remote site make the changes from auto to manual on the IPT mode.

[img]https://ibb.co/pn00bMj[/img]

I went from 10 phones at the remote location that were part of the paging group down to 3 and again during paging no traffic on port TCP/2944. The UDP traffic did drop down from the previous from around 600kbps to 200kbps(Shown below) I also set all phones to manual IPU mode set. So far no drops today. I'll let you know if there are any further issues. Thank you everyone for all your help

[img]https://ibb.co/CmRBQbP[/img]

The "broadcast" setting for the IPU should only be used for handsets connected to the LAN and remote handsets connected via a WAN or VPN should be set to "manual"
The TCP2944 is not used for any updating of handsets as this is done using FTP on TCP ports 20 and 21.
Hopefully reducing the amount of handsets in the page group will stop the peak usage of the bandwidth which was probably causing the handsets to disconnect and reconnect.

Let us know how it goes.

The UDP 16xxx ports will be the audio ports that you are seeing using the bandwidth during the page.

If you do a Wireshark capture you will see the IP addresses that are using the TCP2944 and then sort it by size to narrow down what device is using more than the rest.

Mcflyster
You better send these guys a gift card or $$$ they have gone WAY BEYOND what the support this board normally supplies. Your are a smart cookie I can tell by your reply so you know what I'm talking about. Good support isnt cheap and cheap support isnt good.