I use these parameters which seem to work regardless of where the phone is (NAT 
or VPN)

nat=yes for all devices whether internal (VPN) or external
Set the RTP ports to the same as the Asterisk server or make the server range a 
superset of the device's ranges
Enable symmetric RTP
Enable keep alives on the phones - some may have a NAT keep alive option

Make sure you have defined your localnet on Asterisk for each "internal" 
subnet.  I usually put  10.0.0.0/255.0.0.0 172.16.0.0/255.240.0.0 and 
192.168.20.0/255.255.0.0 in on all Asterisks I configure - it covers most 
eventualities.

Hope this helps

Cheers
Jon


>>> 
> i have nat=no set for those devices since it's over a tunnel (i've tried
> yes and strict as well i think).
> my RTP range is 10000-20000 on the asterisk device. (and they are allowed
> through the firewall)
> at the moment i'm using a snom m9 (RTP range 49152-65534)
> but i've seen the same issues with a aastra 480 (rtp 3000-3003)
> and a digium d50 (not sure on the RTP ports)
> 
> Should any of this matter over a OpenVPN tunnel? or only over NAT?
> 
> I'm not just losing voice btw (which i assume is the RTP), I'm loosing all
> connectivity (which I'm assuming means my Sip session is down).
> 
> 
> On Mon, Oct 14, 2013 at 5:12 AM, Jon Gerdes <[email protected]> wrote:
> 
>> Are you using symmetric RTP?  if not, try that along with a keep alive
>> option.  As the RFC for it states it should be a default - shame it isn't
>> on many systems. it fixes a lot of snags for me.
>>
>> I have a phone - Cisco 504G - on my desk that can go weeks without
>> making/taking a call and yet just works.  The PBX  - Asterisk 11 - for it
>> is over 50 miles away, behind  pfSense  2.1 (formally 2.0.{1,2,3}), at one
>> stage over IPSEC and now simply NATted.
>>
>> Your problem is almost certainly the phone setting up an RTP port at
>> registration and then assuming it can carry on using it.  The state goes at
>> one end or the other and then calls fail.  By using symmetric RTP you
>> effectively fix the RTP port at both ends and the state will properly keep
>> alive - at both ends, PBX and phone.
>>
>> Also make sure that your RTP port range is the same at both ends.  There
>> are many range defaults depending on manufacturer.  Asterisk defaults to
>> 10000-20000 (check /etc/astyerisk/rtp.conf) but Cisco for example does not.
>>
>> So:
>> Get the RTP ranges fixed up
>> Use symmetric RTP
>> Use keep alives
>>
>> Cheers
>> Jon
>>
>>
>>
>> >>>
>> > Already tried that, I think they are pinged every 30sec from the asterisk
>> > side.
>> >
>> >
>> > On Thu, Oct 10, 2013 at 10:05 AM, Vick Khera <[email protected]> wrote:
>> >
>> >> Can you configure your phones to use do a keepalive ping? It sounds like
>> >> the states are timing out.
>> >>
>> >>
>> >>
>> >> On Wed, Oct 9, 2013 at 5:44 PM, palesius . <[email protected]> wrote:
>> >>
>> >>> To take a break from all the NSA talk...
>> >>>
>> >>> I'm having some trouble routing traffic over an openvpn tunnel between
>> >>> two pfsense firewalls. Asterisk server on one end, a couple of
>> different
>> >>> phones on the other side.
>> >>>
>> >>> It was working fine when we had monowall on both ends. (W/ipsec tunnel)
>> >>> Since changing to pfsense it will register with the server just fine
>> but
>> >>> will lose it's connection anywhere from a few minutes to hours later.
>> >>>
>> >>> I've tried both ipsec and openvpn tunnels and have pretty much the same
>> >>> result. I know mono and pfsense use a diffrerent firewall engine, is
>> there
>> >>> something obvious I should set/change to fix this.
>> >>>
>> >>> I had kind of dropped the issue a few months ago but wanted to take
>> >>> another stab at it. I'll try to do some packet captures but don't have
>> any
>> >>> at the moment. Just hoping there is some easy general fix for getting
>> SIP
>> >>> working that someone else has already discovered.
>> >>>
>> >>> _______________________________________________
>> >>> List mailing list
>> >>> [email protected] 
>> >>> http://lists.pfsense.org/mailman/listinfo/list 
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> List mailing list
>> >> [email protected] 
>> >> http://lists.pfsense.org/mailman/listinfo/list 
>> >>
>> >>
>>
>>
>>
>> Registered Address : Blueloop House, Ilchester Road, YEOVIL, BA21 3AA
>> Registered England & Wales - 3981322
>>
>> CONFIDENTIAL INFORMATION
>> This e-mail and any files attached with it are confidential and for the
>> sole use of the intended recipient(s).  If you are not the intended
>> recipient(s) you are prohibited from using, copying or distributing this or
>> any information contained in it and should immediately notify the sender
>> and delete the message from your system.
>>
>> Internet communications are not secure and Blueloop Limited is not
>> responsible for unauthorised use by third parties nor for alteration or
>> corruption in transmission.  Furthermore, while Blueloop Limited have taken
>> reasonable precautions to minimise the risk of software viruses, it cannot
>> accept liability for any damage which you may suffer as a result of such
>> viruses, and we therefore recommend you carry out your own virus checks on
>> receipt of any e-mail.
>>
>> _______________________________________________
>> List mailing list
>> [email protected] 
>> http://lists.pfsense.org/mailman/listinfo/list 
>>



Registered Address : Blueloop House, Ilchester Road, YEOVIL, BA21 3AA
Registered England & Wales - 3981322

CONFIDENTIAL INFORMATION
This e-mail and any files attached with it are confidential and for the sole 
use of the intended recipient(s).  If you are not the intended recipient(s) you 
are prohibited from using, copying or distributing this or any information 
contained in it and should immediately notify the sender and delete the message 
from your system.

Internet communications are not secure and Blueloop Limited is not responsible 
for unauthorised use by third parties nor for alteration or corruption in 
transmission.  Furthermore, while Blueloop Limited have taken reasonable 
precautions to minimise the risk of software viruses, it cannot accept 
liability for any damage which you may suffer as a result of such viruses, and 
we therefore recommend you carry out your own virus checks on receipt of any 
e-mail.

_______________________________________________
List mailing list
[email protected]
http://lists.pfsense.org/mailman/listinfo/list

Reply via email to