[asterisk-users] OpenVPN Clients Intermittently Cannot Call In

[Andrew Martin]

----- Original Message -----
> From: "Administrator TOOTAI" <admin at tootai.net>
> To: asterisk-users at lists.digium.com
> Sent: Friday, May 1, 2015 6:42:38 AM
> Subject: Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call In
> 
> Le 01/05/2015 00:05, Andrew Martin a écrit :
> > ----- Original Message -----
> >> From: "Administrator TOOTAI" <admin at tootai.net>
> >> To: asterisk-users at lists.digium.com
> >> Sent: Thursday, April 30, 2015 4:43:33 PM
> >> Subject: Re: [asterisk-users] OpenVPN Clients Intermittently Cannot Call
> >> In
> >>
> >>> I am running Asterisk 11.12.0 on CentOS 6.4. The asterisk server and
> >>> internal phones are located on the 10.10.32.0/21 LAN subnet. I have many
> >>> internal SIP phones, which appear to be working correctly. I have a few
> >>> external phones (Yealink SIP-T32G or other Yealink model) on
> >>> 192.168.32.0/24 which have an OpenVPN client configured on them that
> >>> connects back to the LAN network through a pfSense gateway with OpenVPN
> >>> configured on it.
> >>
> >> I faced problems with pfsense -no VPN involved- and finally installed
> >> siproxd on it. Also set the firewall mode to conservative.
> >
> > Daniel,
> >
> > Thanks for the information. Do you have an example or documentation on the
> > siproxd configuration that you used?
> 
> No, just follow the basis of the parameters given by the package. If I
> remember, SIP use the proxy siproxd and RTP is direct.
> 

Looking into it further, in my case it does not appear to be a NATing issue,
since running OpenVPN from pfSense means there's no NATing occurring between
the clients or between the clients and the asterisk server.

Although I was unable to reproduce the problems, I did notice some packet loss
and jitter in "sip show channelstats", here is a sample:
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
192.168.32.26    446613544 at 1  00:03:03 0000000094  0000004238 (97.83%) 0.0000 0000000000  0000000244 ( 0.00%) 0.0000
192.168.32.38    5b2ebdc92fd  00:03:03 0000000059  0000000001 ( 1.67%) 0.0000 0000000000  0000000091 ( 0.00%) 0.0028

I was unable to find documentation each of these columns, but the high percentage
of loss for received packets for 192.168.32.26 seems suspicious. Do these statistics
indicate a problem?

Thanks,

Andrew


>