Kitz Forum
Internet => General Internet => Topic started by: Weaver on August 14, 2016, 12:06:18 AM
-
I am going to some day actually get round to testing Andrews & Arnold's VoIP service properly. I notice they have expressed tips about setting a traffic limiting option so that total downstream traffic is artificially limited to a maximum of 95% of the line's capacity and are recommend this for VoIP. I don't really understand how this would work, unless the traffic limiter can recognise VoIP packets and just let them through (allowed to eat into the last 5%) when the link otherwise huts 95% utilisation. In any case, if you can recognise VoIP and treat it specially, or if you implement QoS traffic priorities properly, then why not just let VoIP queue-jump and go in at the head of the queue when the link is at 100% utilisation never mind 95%. And I don't really want to just throw away 5%, it's hard fought for, and I don't have so much to just be able to sacrifice some good bandwidth for no good reason.
As I haven't been feeling well enough to be able to do the necessary thrash testing, I've got the service set to immediately redirect incoming calls to Mrs Weaver's mobile phone. This works superbly well, is very flexible in that you can have it just simply redirect, or have an initial timeout before it then redirects on no answer.
So my questions:
* Does any else use VoIP ?
* Are you able to get it to work reliably under full load (in one or even both directions) ?
* Has anyone else used a traffic limiting policy like the 95% I mentioned?
-
In any case, if you can recognise VoIP and treat it specially, or if you implement QoS traffic priorities properly, then why not just let VoIP queue-jump and go in at the head of the queue when the link is at 100% utilisation never mind 95%.
Plusnet does something similar in that their profile is slightly lower than the BT Wholesale IP profile. The idea is to make sure that any drops are made by the ISP in line with their chosen prioritisation, rather than by BT Wholesale where they may be random. The ISP profile would need to be lower to ensure this, because they can't be sure that their timing is always going to be the same as BTW, by which I mean that even if both were using (for example) a 125ms interval, they could still be out of step. Does it need to be as low as 95%? I don't know, but I guess you could try since A&A offer a number of different options.
Regarding test, I need to test mine at home. I have set prioritisation on my router for UDP from my phone, that's about as sophisticated as the router is capable of. Ideally you'd set your top priority for the RTP traffic, and SIP signalling at a lower priority.
-
I don't see why they have marked 95% in the UI for the rate limiting feature in clueless as (for) "VoIP" or similar, seems a bit much.
How much bandwidth does VoIP need? Around 64 kbps? Anyway, I wouldn't think it needs 2.0 Mbps × 3 lines × 5% = 0.3 Mbps surely?
If they implement a priority queue system, even if only using their stated "small packets go first" strategy, rather than proper priority-marked QoS, then that surely would just do the right thing even at 100% ? (Or perhaps at some slightly lower figure, to ensure, as you point out, that AA is limiting traffic, not BT.)
They really could do with implementing QoS properly.
-
How much bandwidth does VoIP need?
For G711 it's around 87K per call, including Ethernet headers.
If they implement a priority queue system, even if only using their stated "small packets go first" strategy, rather than proper priority-marked QoS, then that surely would just do the right thing even at 100% ? (Or perhaps at some slightly lower figure, to ensure, as you point out, that AA is limiting traffic, not BT.)
When testing with a more capable router I actually found prioritising small packets was very effective in the upstream direction, allowing the acknowledgements for a download stream to jump the queue together with RTP. With that configuration I could max out the upload without either impacting voice quality or download speed.
I'll need to have a look at how A&A describe their QoS operation before commenting.
-
Sounds like it really has no excuse not to be reliable then, at or near 100%. I'll have to sort out the upload side of things too, possibly. Mind you, most users don't have a Firebrick with its upstream rate limiting abilities, and it somehow manages to work for them, presumably. So in fact they would count as "100%" scenario cases then, wouldn't they?
The system I have with the Firebrick's upstream traffic management is very random. As discussed in an earlier thread, I have to guess what the upstream link capacity of each modem is, which changes every time it resyncs, and annoyingly I _have_ to (iirc [?]) put _some_ figure into the Firebrick's config (times three, per each modem) for an upstream rate. And just using defaults (even if possible) wouldn't be a good option for me as the lines don't have anything like equal upstream sync rates ( >500 kbps vs ~ 400 Kbps for example), so I would not get a correct split. Anyway, if I push it too hard, and get my guesswork wrong, then I presume that will make a mess of the outgoing VoIP. I'm not really sure what is supposed to happen in this case, but I just have to hope that it doesn't ever drop the small packets or VoIP-prioritised packets, even in the case where they are at the head of the queue. (Perhaps I need to start using the Firebrick's back-to-back VoIP relay feature for this reason, as opposed to just letting VoIP traffic go straight through as I have it configured now.)
-
I was only briefly and peripherally involved in VoIP in my career but, so far as I recall, the biggest problem to be overcome was 'jitter'. So far as I recall...
Packets may not arrive in the sequence they are sent and so the receiver must buffer them, waiting for those that are out of the sequence. But if it waits too long, there is a noticeable audible lag and anyway they may never arrive - unlike TCP, IP does not guarantee delivery. So it becomes a compromise between giving up hope of the lost/out of sequence packets, vs audible delay.
On a completely private network things can be improved by prioritising VoIP packets, or other QOS measures. But on the public internet, all you can do is optimise your own router - but that won't change much as you can't influence the delays or mis-sequencing that happens on the external network.
I do emphasise that...
A) I was never deeply involved in VoIP.
B) It as all a few years ago (getting on for 10), whereas I'm lucky if I can recall last week with any clarity, these days.
Happy as always for somebody to explain why my comments are out of date or just plain wrong.
:)
-
I was only briefly and peripherally involved in VoIP in my career but, so far as I recall, the biggest problem to be overcome was 'jitter'. So far as I recall...
That's as true now as it was back then.
I've had a little look at A&A's documents, and it's right enough they don't explain any QoS behaviour other than prioritising small packets. I'll try to do some testing and see how it works with my profile set to 95% and then to higher figures.
Slightly by the by it's interesting that the Firebrick behaves as a high level SIP proxy, not just a media termination point. Is that how you have yours configured? Depending on the configuration and the actual SIP gateway (or end point) I've usually found it better to keep the firewall right out of the picture, for example with the Gigaset phone no firewall rules are needed other than ordinary outgoing Internet access.
-
I haven't involved the Firebrick at all. I've simply made the smallest possible targeted firewall hole for the AA voiceless server or servers.
-
I don't know what SIP gear you're using. My Gigaset phone plays a couple of little tricks to ensure that no static opening of any sort is needed in the firewall. To work around the common issue with early media, the Gigaset sends RTP as soon as it receives a 180 or 183 message with SDP media details, even though at that stage it has no actual audio to send.
-
I'm using a Siemens N300. I have no IPv4 NAT, btw.
-
Certainly NAT can be an issue in some cases, but removing NAT still leaves the issue of firewall rules. N300A is what I use, and one of the guys at work had one which we played around with on the bench, taking Wireshark traces from both inside the firewall and outside for various things like initial registration, calls in and out. I'm using SIPgate at home for incoming calls, and Localphone for some outgoing (Localphone can be set to give any valid CLI).
One think I noticed from A&A's description (apart from them not warranting it on NAT) is that they appear to cut-through audio in some cases. So your SIP signalling could be going to A&A, but when the call connects the media end point could be anywhere on the Internet. That would be another challenge for static firewall rules. I think all the commercial services that we've worked with use a single static proxy address that acts both as SIP proxy and MTP.
-
I'll play around and see what happens, but iirc there's a difference between their "voiceless" newer platform and their older systems, in that the older systems arranged for audio to be exchanged directly with arbitrary correspondents on the IPv4 Internet and your device, so that would mean that you had to have a hole wide open in your firewall. If I have understood properly, on the new system audio only goes to/from the voiceless server to your own box. Well, I'm going to find out the truth in a big way at some point.
-
... the older systems arranged for audio to be exchanged directly with arbitrary correspondents on the IPv4 Internet and your device, so that would mean that you had to have a hole wide open in your firewall. ...
That would be true if you only configured static firewall rules. The way I normally configure the firewall (speaking about SIP and VoIP only) it permits nothing inbound from anywhere, except valid replies to permitted outgoing traffic. However if your SIP system doesn't "play the game" and transmit RTP without waiting for anything incoming, then my method fails and you're back to static openings in the firewall.
I'd be interested in seeing Wireshark traces of A&A's operation. That's just for personal interest, reason being that the ITSPs we deal with are often far from clear about details of their operation, so building up knowledge of how the different platforms work helps to "guess" how an undocumented one might work.
-
So does the N300 always initiate outbound RTP packets? So as to effectively open a hole in any firewall?
I just assumed there might be situations with the remote end initating things, with an inbound packet first, since I know absolutely nothing at all about VoIP-related protocols. So, reading AA’s docs concerning the newer ‘voiceless’ system, I changed from having a static wide-open hole for inbound traffic from anywhere, to a static narrow inbound hole from the AA voiceless server only. And I've yet to see if it works.
-
So does the N300 always initiate outbound RTP packets? So as to effectively open a hole in any firewall?
Yes it does, and I'm not sure if that's a departure from SIP standard (or given the variation maybe that should be "standard"). It's a difference from Cisco gateways for example. In an outbound call, without early media and without either end using end special firewall techniques, then when the call connects both ends start sending RTP simultaneously. In this case even if the appropriate firewall hole opened only by your RTP, you're only going to lose the first incoming packet.
The issue arises with early media, where the far end sends audio to play ringback, or some other sort of audio, but in either case this is before the call connects. At that stage you have no audio to send so a Cisco gateway will sit silent waiting for the incoming RTP. In contrast the N300 will start sending RTP even though the call's not connected and it has no audio to send.
-
I'm ashamed to say that I still haven't done any testing work on this, as my health has temporarily worsened if anything, in some respects. That's my excuse anyway.
If anyone should get a chance to test or do a packet capture then let me know.
I realise that I could do a packet capture with Andrews and Arnold’s ‘clueless' server, so I wouldn't have to set up a PC with the relevant software - I'm just using an iPad all the time these days. I’m not sure if a clueless capture at the ISP end as opposed to one at the local will be a fair picture, because although my firewall settings should allow everything outbound (=upstream) to pass through, it won't show the effects of the firewall’s blocking of some inbound (=downstream) traffic and I'll just have to allow for that by filtering in my head.
-
Does anyone else use VoIP, on any ISP ?
-
Yes, Sipgate using a Grandstream GXP1400 on Plusnet.
I've been having two issues recently:
- Intermittent dreadful incoming call quality. Sometimes re-establishing the call clears it. On one occasion it went bad on a call and cleared after about 10-15 seconds.
- Sometimes people calling me get a dead line (no ring and it doesn't go to voicemail). Trying two or three times and it gets through.
-
@jelv - Are the problems to do with someone thrashing the link in one or other or both upstream or downstream directions ? Or no pattern?
Does anyone know if PlusNet supports QoS? And if your software and hardware and the other people you talk with do QoS-marking ? (Given my total ignorance of VoIP protocols, there could be obligatory QoS-marking at the IP level in the core protocols, for all I know.)
I'm just wondering if a lack of joined-up QoS is a killer, meaning that VoIP will never work in every situation.
-
@jelv - Do you have any way of testing for “buffer-bloat” in this case?
Does anyone know about buffer-bloat in general with PlusNet ? Maybe it's also about particular routers too though, now I come to think about it.
There are speed testers that can give rough buffer-bloat indicators. Can't remember which ones - thinkbroadband? DSLReports ?
-
It's definitely not due to any traffic of mine - my monthly usage on the 55/10 link is around 50GB (last month was really heavy and I reached 70GB).
At the time it goes funny there's nothing showing on the thinkbroadband quality monitor.
-
We used Sipgate for inbound, I've not observed any issues but we don't receive all that many inbound calls. I notice Sipgate doesn't set DSCP on their RTP packets. I don't know whether that would affect Plusnet's traffic management.
-
Plusnet's traffic management is meant to recognise the VoIP traffic and set the packets to high priority without the other end doing anything.