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: 88...@sip.skirron.com
Tel: +4141 7674448
> On 27 мая 2014 г., at 18:03, "Dahlberg, David"
> <david.dahlb...@fkie.fraunhofer.de> 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
