Recent BYOD Server Changes and QoS

[Bink]

To get the best possible VOIPo service, I have configured QoS on my router for VOIPo. I have been doing this for quite a while now and it has worked flawlessly until recently. My QoS configuration is simple—and, for the most part, I can only leverage layer 3/4 information for packet classification. Based on this, I have crudely used sip.voipwelcome.com (67.228.182.2) for my QoS—any traffic to/from this IP gets high priority, but this no longer seems to cover the traffic between VOIPo and me as of late.

In reviewing my traffic graphs/logs, initial communication is still done with sip.voipwelcome.com, but now it is highly likely that traffic might be handed off to another IP. Over the last 30 days, concerning VOIPo, I have also communicated with 174.36.46.52, 67.228.190.147 and 174.36.46.53 (all these IPs belong to SoftLayer so I assume VOIPo has some business relationship with them).

I realize that QoS configuration differs for various environments—for example, in my case, I use a softphone and don’t want to configure QoS so it simply prioritizes any traffic going to/from the phone (the phone does more than just make calls). As such, I would appreciate it if someone from VOIPo can chime in on this, provide some insight into VOIPo traffic flows and make some recommendations.

Thanks.

[claganga]

The problem with QOS is once you're on the public network the QOS is gone. So the best you can do is internally have your network prioritize the traffic. That said, assuming you use cable, upstream is your limited bandwidth and you can make some gains here. I'd suggest one of two approaches, of which I do the later.

1)IF your router supports priority by ports then set all ports to normal, SIP(udp/5060) to one notch above, and RTP(some range) to highest. Now the problem is your softphone needs to let you configure an port range for RTP and it also needs to use the same socket for inbound and outbound. Such that the UDP out has the from port the same as your QOS range.

2)If your softphone/router lets use COS or DSCP then configuring the tagging and priority that way. tag signalling medium and rtp above that. This is ideal esp if you have a more complex network then just a router and switch. Also some Access points will use DSCP or COS to prioritize as well

In the end all you will able to do is prioritize outbound traffic. Inbound traffic is trickier and you'd need a router smart enough to associate traffic because the inbound traffic will be all over the place in terms of ports and sources.

[Bink]

The problem with QOS is once you're on the public network the QOS is gone. So the best you can do is internally have your network prioritize the traffic. That said, assuming you use cable, upstream is your limited bandwidth and you can make some gains here.

I concur with this. The main reason I use QoS is to insure VoIP does not compete with other traffic leaving my network.

I'd suggest one of two approaches, of which I do the later.

1)IF your router supports priority by ports then set all ports to normal, SIP(udp/5060) to one notch above, and RTP(some range) to highest. Now the problem is your softphone needs to let you configure an port range for RTP and it also needs to use the same socket for inbound and outbound. Such that the UDP out has the from port the same as your QOS range.

I concur with this too, but my softphone does not allow me to set the UDP ports (and VOIPo appears to use a very large range).

2)If your softphone/router lets use COS or DSCP then configuring the tagging and priority that way. tag signalling medium and rtp above that. This is ideal esp if you have a more complex network then just a router and switch. Also some Access points will use DSCP or COS to prioritize as well

While my router and AP support this, and I feel this is the idea scenario, unfortunately my softphone does not.

In the end all you will able to do is prioritize outbound traffic. Inbound traffic is trickier and you'd need a router smart enough to associate traffic because the inbound traffic will be all over the place in terms of ports and sources.

I concur with this too, but mainly because the bandwidth is consumed before my router can make a queuing decision.

Thanks for taking the time to reply—everything you mentioned is spot on as it relates to VoIP and QoS.

[claganga]

What softphone are you using?

[Bink]

What softphone are you using?

I use the stock Android JB SIP client--and it has its fair share of pros and cons--though I understand serious SIP users tend to go with CSipSimple.

[claganga]

Gotcha, I use SIPDroid and it has the same limitation. I think I'm going to take a peek at the source code and see how hard it would be to add.
I'm actually in the planning stage of something similar on droid clients so it might be a good exercise anyway.

Conversely you could probably check in with the project and request the feature. If the OS supports packet tagging it's a no brainer for clients to leverage