Macram Zaarour wrote:
>I am using ulaw as VOIP codec for internal calls between asterisk
>extensions, while using g729 for calls to the outside
>
>Setting the device OUT-BANDWIDTH on NAT side to below 128k(my download
>speed) will surely affect the internal calls voice quality knowing that ulaw
>takes up to 80k per call and all calls are proxied on the server. So two
>internal calls traffic consumption will far exceed my download speed of 128k
>
>Note that my internal asterisk extensions are on the NAT side
>
>Am I saying right, or am I missing something ?
What you are missing is that to shape the inbound WAN traffic by
controlling the outbound LAN traffic you need to configure your
shaping to allow line-speed for traffic that originated ON THE BOX
('A' in the example I gave) and constrain traffic that originated
FROM THE WAN ('B' in the example).
Since you can't take account of traffic originating from the WAN and
terminating in the box, the best you could do for that is to estimate
the maximum (ie n calls * x bps/call).
In practice I think it's probably better, and far simpler, to just
police the inbound rate on the WAN side.
>It's something I've been thinking about over the last week or two. At work I
>have a Linux box acting as a bridge and doing traffic logging, I've recently
>added traffic shaping as our VoIP was getting a bit rough at peak times. In
>this case, I'm thinking of a heirarchical setup on the internal I/F along
>the lines of :
>
>I/F (outbound)
> |
> |\ unrestricted, unprioritised queue (A)
> |
> \ HTB root (B)
> |
> |\ priority queue (B:1)
> |\ normal queue (B:2)
> \ 'slow' queue (B:3)
>
>By setting the rate limit on B to a little below the incoming line speed it
>will cause excess incoming traffic to be queued (and ultimately dropped),
>hopefully causing TCP sessions to back off. By prioritising VoIP traffic, it
>should be possible to avoid dropping the RTP traffic.
>
>Traffic generated on the box itself will be put into the unrestricted queue
>A, and since this is 100M ethernet we're unlikely to manage to saturate this
>!
And Prasanna Krishnamoorthy replied:
>You *don't* need traffic shaping on the LAN side. Typically it's very
>unlikely that you're going to saturate that link. You *must* always
>shape on the most-constrained link. And if you don't have the most
>constrained link (because of massive queues at the ISP), then you must
>reduce the incoming bandwidth and make it the most constrained link to
>be able to effectively shape the traffic.
But the discussion was about how to (approximate) traffic
shaping/control on the inbound wan link by applying controls to the
outbound queue of the lan side - as opposed to simply policing the
inbound rate and indiscriminately dropping packets. Trying to shape
traffic on a 128k link by specifying a rate of 10M isn't going to
work.
I proposed a method that I believe would work (with enough provisos)
but is harder to set up (would need a manual tcstart file). The
reason I've been contemplating it is so that I can drop packets on
the non-voip traffic and try to get it to slow down, whilst leaving
the voip traffic as intact as possible. The inbound policing
available doesn't have that capability AFAIK, and in any case, the
place to do it is at the ISP end but we don't have any control over
that.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
