pf+voip

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

pf+voip

Швецов Михаил
Does pf have specific rules for voip, may be example of working pf_rule
with voip?

Because for «standart rules» i have problems with voip.

set skip on lo

match out on pppoe0 from { em1:network } nat-to (pppoe0)

block

pass out

pass in on { em1 }

- after hanging up, the line near 3 minutes still busy (may be keep
state set to no state in rules)

- badly hear person on the phone (quiet)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: pf+voip

Stefan Sperling-8
On Tue, May 27, 2014 at 01:59:07PM +0400, Швецов Михаил wrote:

> Does pf have specific rules for voip, may be example of working pf_rule with
> voip?
>
> Because for «standart rules» i have problems with voip.
>
> set skip on lo
>
> match out on pppoe0 from { em1:network } nat-to (pppoe0)
>
> block
>
> pass out
>
> pass in on { em1 }
>
> - after hanging up, the line near 3 minutes still busy (may be keep state
> set to no state in rules)

Assuming your VOIP client is in the em1 network it might run into
problems with NAT traversal if you don't use the static-port option.

     static-port
           With nat rules, the static-port option prevents pf(4) from
           modifying the source port on TCP and UDP packets.

> - badly hear person on the phone (quiet)

I don't believe pf could have anything to do with that.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: pf+voip

Ryan Freeman
In reply to this post by Швецов Михаил
On Tue, May 27, 2014 at 01:59:07PM +0400, ???????????? ???????????? wrote:

> Does pf have specific rules for voip, may be example of working
> pf_rule with voip?
>
> Because for «standart rules» i have problems with voip.
>
> set skip on lo
>
> match out on pppoe0 from { em1:network } nat-to (pppoe0)
>
> block
>
> pass out
>
> pass in on { em1 }
>
> - after hanging up, the line near 3 minutes still busy (may be keep
> state set to no state in rules)
>
> - badly hear person on the phone (quiet)
>

Hey,

I don't use this anymore, but i still have the blurbs from my pf.conf
that had a pretty much perfect working voip connection:

Queuing: this was originally around 900kbit up when i used it (diff
isp).  i also had given the voip queue around 12% i think, left it
there as I was unsure of whether i'd still be using the voip phone
after i left that company, and just knocked it down to 2% ;)

also pre-newqueue, warning! ;)
ext01 and ext02 are aastra phone and obihai voip device, respectively.

--snip--

# hfsc queueing
altq on $ext_if bandwidth 460Kb hfsc queue \
        { voip, ack, dns, game, ssh, www_ftp, std_out }

queue voip    bandwidth 2% priority 8 hfsc(realtime 2%)
queue ack     bandwidth 15% priority 7 hfsc(realtime 15%)
queue game    bandwidth 37% priority 6 hfsc(realtime 40%)
queue dns     bandwidth  5% priority 5 hfsc(realtime  5%)
queue ssh     bandwidth 15% priority 4 hfsc(realtime 17%) {ssh_im, ssh_bulk}
queue   ssh_im     bandwidth 90% priority 4 hfsc
queue   ssh_bulk   bandwidth 10% priority 3 hfsc
queue www_ftp bandwidth  3% priority 2 hfsc(linkshare  3%)
queue std_out bandwidth 15% hfsc(linkshare  5% default)

--snip--

# NAT voip, static-port required to maintain UDP port mappings for SIP proxy
match out on $ext_if from $ext01 to any nat-to ($ext_if) static-port
match out on $ext_if from $ext02 to any nat-to ($ext_if) static-port

# queue voip, to AND from
match inet proto udp to port $rtp_ports scrub(set-tos ef) queue voip
match inet proto udp from port $rtp_ports scrub(set-tos ef) queue voip

--snip--

above here took care of the rest.  this was using both a obihai voip
device for hookup of a POTS phone, and an Aastra phone as my primary
voip phone hooked into the company directory etc (all quite easy with
asterisk!)

The above worked enough that I could take business calls including calls
that may have resulted in sales of voip service, without it sounding
like i was on a shitty link with various vocal artifacts etc.
in the end i could pretty much hammer my inet connection as hard as
i wanted while a call was in progress and never really lost anything.

YMMV :)  I found my values via hours of tweaking, hammering with
various bandwidth-intensive applications, and hammering more.

I believe we did have a form of STUN or SIP proxy, the phones we
used could be preconfigured to fetch a config from the company server,
which would include things like a STUN or SIP proxy ip.

in my setup, my normal nat line in pf does not use static-port, hence
the added line before that point to catch the voip devices and make
sure they are natted with static-port.

Cheers,

-ryan
Loading...