Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: VoIP and full load traffic  (Read 2982 times)

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
VoIP and full load traffic
« 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?
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #1 on: August 15, 2016, 01:31:56 PM »

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.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: VoIP and full load traffic
« Reply #2 on: August 15, 2016, 07:03:44 PM »

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.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #3 on: August 15, 2016, 07:40:40 PM »

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.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: VoIP and full load traffic
« Reply #4 on: August 15, 2016, 08:41:17 PM »

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.)
Logged

sevenlayermuddle

  • Helpful
  • Kitizen
  • *
  • Posts: 3209
Re: VoIP and full load traffic
« Reply #5 on: August 16, 2016, 12:23:49 AM »

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.
 :)
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #6 on: August 16, 2016, 12:41:20 PM »

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.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: VoIP and full load traffic
« Reply #7 on: August 16, 2016, 07:39:20 PM »

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.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #8 on: August 17, 2016, 02:46:35 PM »

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.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: VoIP and full load traffic
« Reply #9 on: August 17, 2016, 02:49:49 PM »

I'm using a Siemens N300. I have no IPv4 NAT, btw.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #10 on: August 17, 2016, 03:41:10 PM »

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.
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: VoIP and full load traffic
« Reply #11 on: August 18, 2016, 08:50:20 PM »

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.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #12 on: August 19, 2016, 06:32:21 PM »

... 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.
« Last Edit: August 19, 2016, 06:34:29 PM by aesmith »
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4004
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: VoIP and full load traffic
« Reply #13 on: August 20, 2016, 03:44:37 AM »

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.
Logged

aesmith

  • Reg Member
  • ***
  • Posts: 655
Re: VoIP and full load traffic
« Reply #14 on: August 22, 2016, 09:32:26 AM »

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.

 
Logged
Pages: [1] 2
 

anything