$icmp_types keep state
# -end
-Original Message-----
From: Jeff Santos <[EMAIL PROTECTED]>
To: misc@openbsd.org
Subject: Re: brute force voip QoS
Date: Thu, 7 Feb 2008 14:14:57 -0500
Delivered-To: [EMAIL PROTECTED]
Hi Stuart and the others,
> > pass out queue (std_out,lowdelay)
>
> here, you place ACKs from downloads at a higher priority than
> your voip calls. this is unlikely to be what you want with priq
> over a 140Kb/s link..
>
> there are some other things you could look at too but changing
> this woul
On 2008/01/30 15:53, Rod Dorman wrote:
>
> Plus QoS isn't going to interrupt a packet currently being transmitted,
> if a large download packet is already going out your VoIP packet is
> gonna have to wait until its done.
scrub max-mss can help with this.
On Wednesday, January 30, 2008, 15:06:28, [EMAIL PROTECTED] wrote:
>> My bandwidth is very very limited. Not more than 140 Kbps on both
>> sides at any time. I use G729 as a codec in order to reduce
>> consumption. Use the pf.conf below, when VoIP is the only traffic,
>> the quality of the calls is
To: Stuart Henderson <[EMAIL PROTECTED]>
Subject: Re: brute force voip QoS
> > pass out queue (std_out,lowdelay)
>
> here, you place ACKs from downloads at a higher priority than
> your voip calls. this is unlikely to be what you want with priq
> over a 140Kb/s link..
Ac
> altq on $ext_if priq bandwidth 125Kb queue {std_out, voip_out, \
> lowdelay, lowpri_out}
> queue lowpri_out priority 1
> queue std_out priority 4 priq(default)
> queue voip_out priority 11
> queue lowdelay priority 12
priq priorities are absolute. where there are higher priority
packets waiting
> My bandwidth is very very limited. Not more than 140 Kbps on both
> sides at any time. I use G729 as a codec in order to reduce
> consumption. Use the pf.conf below, when VoIP is the only traffic,
> the quality of the calls is excelent with no voice cutting at all.
> Now if I start a download I i
Hi,
Thanks for your insights.
> - Original Message -
> From: scott <[EMAIL PROTECTED]>
> 1. Your topology: On the "inside" lan, are you hosting clients or
> service? So is this an outside-to-inside -or- an inside-to-outside
> problem?
VoIP Clients. ATAs. This is an inside-to-outside
On Wed, 2008-01-23 at 15:53 -0800, David Newman wrote:
> How you detect a VoIP flow may also be an issue. If your VoIP traffic
> uses SIP, you can classify the signaling traffic on 5060/udp -- but then
> the voice or video traffic will use RTP/RTCP and some ephemeral port
> chosen during call se
your case is an outside-to-inside scenario, then reverse the
directions, i.e. use either an inside-edge nat or a rdr instead.
/Scott
-Original Message-
From: Jeff Santos <[EMAIL PROTECTED]>
To: misc@openbsd.org
Subject: brute force voip QoS
Date: Wed, 23 Jan 2008 09:28:09 -0500
Deli
Daniel Ouellet wrote:
port use are negotiated via the control port on UDP/5050 and that's when
Should have been UDP/5060 here. Not 5050 as above. Sorry, fat finger...
Or in some cases when NAT traversal is also in use for SIP, you will
have UDP/5060 and UDP/5061.
Regardless these are and ha
David Newman wrote:
On 1/23/08 4:21 PM, Daniel Ouellet wrote:
So, you could check for UDP RTP stream from that IP's and all phones
can and are most likely preset with a fix range of ports that they can
use and if you can find that, then you have all that you need.
Gack. No.
I've seen more t
On 1/23/08 4:21 PM, Daniel Ouellet wrote:
So, you could check for UDP RTP stream from that IP's and all phones can
and are most likely preset with a fix range of ports that they can use
and if you can find that, then you have all that you need.
Gack. No.
I've seen more than one MegaCorp use
On 1/23/08 4:08 PM, Chris Cappuccio wrote:
Just use the 'tos' tag in pf.conf to match against the IP tos field.
Most equipment sets this to something predictable, like 0x68 for RTP and
0xb8 for SIP Just use tcpdump to see what your RTP traffic is tagged
as, and also prioritize SIP above R
Chris Cappuccio wrote:
Just use the 'tos' tag in pf.conf to match against the IP tos field.
Most equipment sets this to something predictable, like 0x68 for RTP and
0xb8 for SIP Just use tcpdump to see what your RTP traffic is tagged
as, and also prioritize SIP above RTP. You could also
I would like to setup PF so that, whenever an initial voip flow was
detetcted, all other non relevant traffic would be blocked, and normal
packet flow being restored only after some voip idleness be detected.
Not exactly sure why you would like to do this part.
With proper QoS setup, it doesn't
Just use the 'tos' tag in pf.conf to match against the IP tos field.
Most equipment sets this to something predictable, like 0x68 for RTP and
0xb8 for SIP Just use tcpdump to see what your RTP traffic is tagged
as, and also prioritize SIP above RTP. You could also try matching based
on IP
On 1/23/08 6:28 AM, Jeff Santos wrote:
I would like to setup PF so that, whenever an initial voip flow was
detetcted, all other non relevant traffic would be blocked, and normal
packet flow being restored only after some voip idleness be detected.
Can it be done? Can someone give some ideas of
Hi,
I would like to know if this is possible and how, regardless of what
happenned with other applications.
I would like to setup PF so that, whenever an initial voip flow was
detetcted, all other non relevant traffic would be blocked, and normal
packet flow being restored only after some voip id
19 matches
Mail list logo
