Jseries Remote Worker Bandwidth

[RedTech443]

I have seen this before but cannot find it again.

I am looking for the recommended bandwidth needed for J179 SIP phones.

I have a customer that is experiencing SIP outages on 50+ SIP phones on one location that are all configured as a Remote Worker. Initial investigation points towards QOS issues, they seem to be all disconnecting during peak call hours on a 50Mbps link.

Looking for documentation or if anyone has run into this, my next steps are to look at the phones physically during the outages and login to the phone webpage to troubleshoot.

 

[avayaguy23]

Do you have a monitoring platform that can accept RTCP monitoring? Since these are off-pbx you can take two approaches. You can configure the SBC to send RTCP traffic to your monitoring platform or you can configure the 46xxsettings file to have the phone send the RTCP traffic directly. You would need a public IP/DNS. I would recommend putting it in the DMZ so you can then open up UDP 5005.

 

[kyle555]

Define outage. If you're maxing out 50Mbps down then it's entirely possible the signaling messages back are getting lost and having the phones marked out of service.

If they're remote workers, then there probably isn't much QOS to work with. Why not just up the link to 100Mbps?

 

[RedTech443]

No monitoring platform as of now, I am working to get a linux box stood up on prem to setup rsyslog for the phones to send debug info to, in the meantime not much else I can do for monitoring.

The customer is aware of the low bandwidth and also suspects it as an issue, they are trying to rule out the possibility of phones having a misconfig, which I do not think is the case since they register just fine and only go down during peak traffic hours.

 

[biglebowski]

Figure I use for SIP is 100 Kbps per concurrent call for G711.

On our internet connection I have 20 Mbps QoS allocated for 1000 softphone users with burst to 100 Mbps, most I've seen so far is 150 concurrent calls which used 15 Mbps

Can't see how 50x handsets could use 50Mbps unless they are all using 720p video

Peak time drops does indicate a policing issue though.

What sort of connection is it, BT provide us with QoS reports for our WAN links and netflow on the firewall lets us know the internet usage.

 

[Wanebo]

If you are not using (or improperly using) QOS at that site I could easily see 50Mbps being the bottleneck depending on what other traffic you have. First, someone should look at the QOS configurations in place and tweak them as needed. Along side of that someone should be quantifying the amount and types of traffic present throughout the day but especially during those peak times that users experince dropped calls. Maybe there are large file transfers happening between that site and corporate at those times that could be shifted to off hours. Maybe you have some users streaming high bandwidth video or performing video conferences. Maybe a ton of screen sharing via webex or teams is happening. Too many varibles in place until you get those 2 ducks in a row. At that amount of bandwidth it's not likely to be simply the amount of RTP causing the issue.

 

[RedTech443]

I am attempting to use the jseries phone and enabled debugging to a syslog server. Not sure what options to enable on the phone for syslogging, but I am starting with "qos" to see if that provides any results during a outage.

 

[biglebowski]

Ask the network guys to implement a traffic shaping policy on the internet firewall, this will essentially reserve some bandwidth just for the handsets.

As long as the handsets and Avaya servers are tagging the packets with the correct DSCP you can use EF/23 on the internet firewall to ensure they have enough bandwidth and the traffic bypasses the queues and goes straight to line.

 

[RedTech443]

Thanks biglebowski, at this time I can see in the syslog the phone going into acquiring service multiple time and disonnecting. Beyond that there is not much I can really do as I have no access to their network and can only point to the obvious issues such as disconnecting, packet loss, high latency etc..

Probably not much more I can do really.