Traffic management and VOIP

I have a Siemens Gigaset handset which has recently (since moving to Plusnet) started to lose incoming packets. Incoming voice breaks up.... Outgoing voice fine.

Is there a master list of the correct way to setup a voip handset so that it works optimally with Plusnet? I notice there's a list of games but couldn't find one for VOIP.

I've asked Plusnet - they want me to start using Wireshark and third party VOIP apps to troubleshoot...

I've set the ports to 6970-6990... and it's improved... I assume I'm now setup optimally but confirming this with Plusnet is as hard as it gets.

I have a Gigaset C460IP and it's working just fine over Plusnet's network.

It would be useful to know which Gigaset model you have, what type of router you're using, and the speed of your broadband connection. Also, do you have any problems with other traffic being lost on your broadband link?

The fact that you can set up and clear calls OK, both incoming and outgoing, and also establish a voice channel, suggests there shouldn't be any problem with port configuration. For what it's worth, my Gigaset is configured to use port 5060 for SIP signalling (that's the standard SIP port), port 5004 for RTP (that's the voice connection), and NOT to use random ports. There's not a lot else I can set up on the C460IP. I have no special configuration on my router.

With VoIP the voice is carried by RTP over UDP. So there's no guarantee of end-to-end delivery, but RTP can detect lost packets and out-of-sequence packets. The voice codec usually just inserts silence or low level white noise to cover lost packets. The question is where the packets are being lost, obviously.

If you're running Wireshark at your end and can capture the RTP stream, it will show you if there are lots of "missing" packets on the incoming stream (as well as out-of-sequence, delay, jitter, etc), but that doesn't help identify where they were lost! Also, I assume you're monitoring on the VoIP client side (LAN side) of the router, so you're just capturing visually what your ear is already telling you. I guess you should also be able to see that Plusnet is assigning the correct priority class to the RTP packets.

In my experience voice break up is usually caused by having insufficient capacity on the access link (ie your broadband circuit) because some other traffic is hogging the bandwidth. Assuming Plusnet is assigning the correct priority class to your RTP packets, that shouldn't be happening.

So the only other thing I'm wondering is whether your router is trying to do something with the VoIP packets as they go through it and isn't keeping up. Are you using a Technicolour router? I think they implement a SIP Application Level Gateway in some models, which you can turn off with the telnet commands:

connection unbind application=SIP port=5060
saveall

But if that was causing the problem, I'd expect you to have difficulty establishing VoIP calls as well.

If you have another router available, you could try that to see if it fixes the problem. If not, then the problem is obviously upstream of you.

And finally, one other possibility: if it's a cordless Gigaset handset then it uses DECT for communication with its base station. Is that sitting next to your router? It could be that the router's wifi is interfering with the Gigaset's DECT transmissions and you're losing data on the air interface. Try turning off the roter's wifi and see if that makes a difference.

Sorry this is rather long and rambling - just thinking through your problem out loud. Hope something here might help.

Thanks Robert. That's got to be one of the most complete posts I've ever received. I'm impressed!

To answer your points I have a Gigaset S685IP and I have a Fiber connection syncing at 77.4 down and 20 up. I've never used Plusnets router and started with a Billion 7800N and am now using an ASUS RT-N66U. The S686IP is connected about 15m from my router in another room and the internal LAN is entirely ethernet running at 100Mb <1ms. The ASUS doesn't have QOS running.

The voice break up occurs mostly during peak periods and during the day at weekends. During the first month with Plusnet I opted for the "Pro" addon and during that time the S685IP worked fine... My connection doesn't use P2P and at the times of these calls was hardly in use.

So down to the RTP... I did have it running on non standard ports 32500 I think... I asked Plusnet to tell me how I should configure the VOIP unit for their network, but they side stepped the issue and instead want to run packet capture etc etc. In any case without Plusnets help I changed the RTP ports to 6970 - 6998 and so far the issue appears to have disappeared.

At the weekend I'll install X-Lite on my PC and try to capture the packets from that... I just thought Plusnet would already have this worked out so they could tell me use port x but I guess not.

Thanks
Tim

There is the possiblity of congestion on the backhaul from the exchange because of the peak time and weekend issues.

I would configure the phone to use the standard ports and check if SIP ALG is disabled on the router as Robert suggested.

I have a Gigaset C475IP which has two VoIP lines set up on it with SIP signalling on ports 5060 and 5160 and RTP on ports 5004 and 5104. I also have a static IP address set up on the Gigaset, port forwarding set up for the SIP/RTP ports and QoS set to provide VoIP with guaranteed bandwidth just in case.

In reply to a post by simon194:

There is the possiblity of congestion on the backhaul from the exchange because of the peak time and weekend issues.

I would configure the phone to use the standard ports and check if SIP ALG is disabled on the router as Robert suggested.

I have a Gigaset C475IP which has two VoIP lines set up on it with SIP signalling on ports 5060 and 5160 and RTP on ports 5004 and 5104. I also have a static IP address set up on the Gigaset, port forwarding set up for the SIP/RTP ports and QoS set to provide VoIP with guaranteed bandwidth just in case.

Interesting. Re para 3. Where exactly were you able to choose these settings?

In reply to a post by trolleybus:

In reply to a post by simon194:

There is the possiblity of congestion on the backhaul from the exchange because of the peak time and weekend issues.

I would configure the phone to use the standard ports and check if SIP ALG is disabled on the router as Robert suggested.

I have a Gigaset C475IP which has two VoIP lines set up on it with SIP signalling on ports 5060 and 5160 and RTP on ports 5004 and 5104. I also have a static IP address set up on the Gigaset, port forwarding set up for the SIP/RTP ports and QoS set to provide VoIP with guaranteed bandwidth just in case.

Interesting. Re para 3. Where exactly were you able to choose these settings?

You can set a static IP address via the Gigaset's web interface but make sure it's outside the DHCP range of the route. I have a separate DHCP server running on my network which allocates a static IP address.

Port forwarding is set up on the router, you just need to set up a few firewall rules for the ports and then point them incoming to the IP address of the Gigaset. QoS setup is also done via the router but it's availability and how it's set up varies from router to router. I'm using a Billion 8200N VDSL2 router which has pretty good QoS functionality.

In reply to a post by simon194:

congestion on the backhaul from the exchange

I had thought that might be true but it worked really well when I used the "Pro" upgrade and all unknown traffic was promoted, which is why I didn't notice it until January...

Plusnets documentation does say that traffic it doesn't know about will be put in the silver Q... which means it gets a lower prioirity coming over my link and I assume across Plusnet's network. My link is hardly used so it's unlikely to be on my network or on it's way through the BT links. When I am using the link I don't use VOIP...

I enabled the SIP ALG gateway once on my old router... but that's instant failure.

It seems to be working much better with the new ports... I'm keeping my fingers crossed.

Tim,
Interesting problem! My Gigaset (similar to yours, just an earlier version) is also connected to an Asus RT-N66U over ethernet, and in my case they are only about 1m apart. I also have QoS OFF on the router (shouldn't make a difference as it's incoming packets you're losing), and I don't have any port forwarding or other special set-up on the router (my VoIP provider's SIP proxy handles all that). My broadband is FTTC Unlimited at 73Mbit/s down, 18Mbit/s up. So an almost identical configuration which works perfectly in my case.

You've tried a different router, so I think we can eliminate that as the problem. The Asus doesn't run a SIP gateway, so it's not that either.

RTP ports... there are no "standard" RTP ports for VoIP (other than that it should always be an even numbered port). However, I'm puzzled why you've set up a range of ports. Does your VoIP provider require it? The default Gigaset configuration is to use port 5004. It might be worth reverting to that, just in case there's some strange quirk in the Gigaset's VoIP software (in the base station web configuration, Settings -> Telephony -> Advanced Settings). Otherwise, I can't think of any reason why port number should make any difference at all! Except... we don't know how Plusnet determines which traffic is VoIP. They say they use a combination of port number and DPI. Might be worth posting on the Plusnet VoIP forum to ask how they do it.

You've said the problem occurs mostly during weekday evening peaks and at the weekend. If there is definitely a correlation with time of day, that does suggest congestion somewhere, as simon194 says. And the Pro add-on made a difference, which points to traffic queues in Plusnet's network. So three things you could check:

1. Some Plusnet users seem to have had problems with high latency during peak times. There are several threads about it on the Plusnet forums. The main one is here. That sort of issue would cause your symptoms. Not sure if it affects FTTC customers (mine is fine). Seems to be related to the gateway you're on. You can check your gateway here. I'm on ptw-ag01.

2. You could set up a TBB Broadband Quality Monitor - that should show if there are any periods of high latency or packet loss on your line. You could then see if there is any correlation with your VoIP problem. You'll need a fixed IP for this to work well (or you have to create a new monitor each time your IP changes).

3. Use Wireshark to check that your VoIP traffic is being assigned the correct priority in Plusnet's network. VoIP traffic should have the Differentiated Services field set to a value of 0xa0 (Titanium priority queue). Your experience with the Pro add-on suggests it might not be.

On the other hand, if it's working OK now you could just sit back and make a phone call

I have a fixed IP and setup a broadband quality monitor some weeks ago. It looks pretty normal. I do occasionally notice those huge ping spikes and usually disconnect the router until I get one with a decent ping. ptw-ag01 is one of my favorite gateways... always a good ping.

Today I installed X-Lite softphone on the computer, but it's not as configurable as the Gigaset and there's no way of custom setting RTP ports to be at UDP 32500. In any case the DSCP field shows the traffic is in the titanium queue - so that's good.

I hope that having changed the ports on my Gigaset that it too will now be in the titanium queue. Of course there's no easy way for me to check.

As you say sit back... the quality at the moment is as good as it's ever been.

Thanks for the help.
Tim

Use Wireshark to check which queue the incoming RTP packets are in (see http://community.plus.net/library/faults/using-wires... for a guide on how to do it). If the Differentiated Service field is not 0xa0 tell them that you are seeing the same problem as has been reported on tickets 60822642 (opened 9 Oct 2012), 62006833 (opened 8 Nov 2012) and 65840525 (opened 13 Feb 2013). Also zip up the Wireshark capture and attach it to the ticket.

Don't bother trying X-lite because that is what I am using and I'm seeing the traffic in the bronze (0x00) queue. At times the call quality is terrible.

I'm getting really sick of waiting for this to be fixed - they've had a few goes already and if anything it's worse as originally it was in 0x80.