Hi!
Don't miss RTP protocol :
pass .... proto tcp to .... port 9999 >< 20001
Alex
On 05/27/2014 07:46 PM, Dmitry Petrakoff wrote:
Sorry, that was exactly I meant ( OT probably ):
The first issue with late hang-up most likely means, that calee hung up and his UAC sent
SIP BYE within existing dialog. For some reasons either UAS on caller's side or
intermediate SIP proxy discarded that BYE. There could be the "same" issue with
a reply on that BYE, but idea is the same: something wrong with SIP header.
Anyway it is a problem of layer 7 proto but not a PF.
The second issue with speech volume is only VoIP client dependant.
If RTP works in both ways it is not an issue PF with NAT enabled again because
SDP headers already rewrote somewhere ( usually on provider's side ).
Anyway, pf can't be a point of problem here simply because L3 packets can
travel back and forth without issues.
WBR
Dimon
Sip: [email protected]
Tel: +4141 7674448
On 27 мая 2014 г., at 18:03, "Dahlberg, David"
<[email protected]> wrote:
Am Dienstag, den 27.05.2014, 14:15 +0400 schrieb Dmitry Petrakoff:
It is most unlikely the issue of pf or its rules. Simply because your
issues are related to SIP (busy issue) and RTP/phone (voice volume).
Pf does not have any SIP ALG built-in so can't affect VoIP.
Well that is not completely right. SIP negotiates parameters of a call
in one "connection", and then opens media streams in both directions.
The problem is more or less the same as with (active) FTP, and some
packets filters are L7 aware and configure the required port forwardings
dynamically some aren't. (Actually most appliances/stacks are kind of
SIP aware but then fail erraticaly, when push comes to shove.)
I am pretty sure, that pf is /not/ SIP aware. So you have the following
options:
* Get a public IP space
* Use static port rdrs, configure your SIP application accordingly.
* Get a public IPv6 space
* Use STUN and other ugly NAT traversal mechanisms
* Use an application layer gateway/proxy/PBX:
I found Asterisk in packages, FreeSWITCH from source or
siproxd in packages, which looks exactly right, but I do have no
experiences with it.
* Use IPv6, get rid of NAT. Seriously.
Cheers
David
I'd like to suggest you to check busy issue with your VoIP provider or
to check out different clients or phones.
On 27.05.14 13:59, Швецов Михаил 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)
--
David Dahlberg
Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845
Fraunhoferstr. 20, 53343 Wachtberg, Germany | Fax: +49-228-856277