Date: Wed, 2 Jan 2002 20:47:37 -0800 (PST) From: Tom Samplonius <tom@sdf.com> To: Adrian Gonzalez <adrianbsd@globalpc.net> Cc: freebsd-isp@FreeBSD.ORG Subject: Re: VoIP and PPP question Message-ID: <Pine.BSF.4.05.10201022024180.29300-100000@misery.sdf.com> In-Reply-To: <3.0.6.32.20020102181635.0100da70@globalpc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Jan 2002, Adrian Gonzalez wrote: > Hello > > I've been doing tests with a couple of Multitech MVP200 V/IP gateways > (http://www.multitech.com/PRODUCTS/MultiVOIP/). Basically it's a gateway > with 2 fxs/fxo/e&m ports and an ethernet port. > > The idea is to get v/ip going between two offices, with the following setup > on both: > > Multitech V/IP Gateway connected via ethernet to a FreeBSD 4.4-STABLE box. > Each FBSD box is running user ppp to connect to us (ISP) via a 3com ISDN > modem. We receive them on our pm3's. > > Everything works great, but the real issue is QoS. A simple ftp download > is enough to disrupt voice quality. > > I've toyed around with the "set urgent" option in user ppp, which is either > being ignored or is not enough to fix the problem. I tried lowering the > MTU on the link but that seems to break things for them. It probably isn't effective because the ISDN TA is probably buffering. You are probably running the TA at 230.4Kbps async, and the line is 128Kbps sync. FreeBSD can't reorder packets if there are never (or rarly) more than one in its send buffer. The TA can probably buffer most of a TCP send window. > I'm considering trying dummynet for queuing, but I wonder if the problem > has more to do with the packet size. I imagine it has to do with the big > 1500ish byte packets clogging the 128k isdn connection for more than 100ms > at a time, but I'm not sure why lowering the MTU from 1500 to 500 causes > problems. When I lowered the MTU they started complaining about Ftp's > suddenly hanging, and link slowdown in general. The most common problem with MTU breaking file transfers is that ICMP is incorrectly filtered somewhere between the client and server and path MTU detection is being used (default on most TCP/IP stacks). The gateways that are transitioning from MTU 1500 to MTU 500 don't fragment traffic when Path MTU detection is on. They throw it away, and send a ICMP "could not fragment" message back to the sender of the packet. That ICMP is not getting through. dummynet would likely help. You can put all the non-VoIP traffic into a pipe that is can't use more than 50% of the ISDN link, leaving 50% of the bandwidth for VoIP. Not the most efficient use of the bandwidth, but should resolve the issue. > Anyone out there tried a similar setup? Any help greatly appreciated > > -Adrian Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10201022024180.29300-100000>