Hi Mark,

Have you solved this yet?

It sounds suspiciously like your phones _are_ reinviting for some
reason, and that the phones don't know that they can reach each other
via the VPN tunnel.

First off, can any system on the local network ping any system on the
remote network?

The next thing I would do is start up some sniffers at strategic
points on your network. Mainly at your asterisk system, and hopefully
somewhere before the phone on the remote end.

On the asterisk system, do a tcpdump in the port range you're
expecting SIP and RTP traffic as defined in sip.conf and rtp.conf
respectively. In default setup, that would be something like:

 tcpdump -i eth0 portrange 10000-20000 or port 5060

Make sure no other calls are going on at the same time, otherwise you
will be drowned in information.

And on the remote end, simply do a tcpdump on the IP address of your
asterisk system. If you're logged into the remote end via the asterisk
system, make sure to exclude your connection (say, ssh on port 22)
from the dump:

 tcpdump -i eth0 host 192.168.x.x and not port 22

Now place a phone call. Is everything sending data to the locations
you expected?

Reza:

I'd argue that adding a properly configured VPN _decreases_ the
complexity of debugging issues in multi-office scenarios. If you've
set up a route between the two networks, you don't have to worry about
firewalls and port forwarding at all.

Something like OpenVPN.org is very simple to set up (there's a client
for it on OpenWRT), and can even give you channel bonding and
transparent & reasonably uninterrupted failover between connections.
How sweet is that?

Cheers,
spd

On 5/22/07, Reza - Asterisk Enthusiast <[EMAIL PROTECTED]> wrote:


Hello Mark:

Personally I do not recommend VOIP through a VPN.   Other's might disagree,
but I have my style.   The inability of RTP packets not flowing through is
to do strictly with how your VPN is structured.    I know of people who
implemented VOIP on a VPN.

Technically speaking, UDP can flow through a VPN.   They are just data
packets.

Your IAX routing through another Asterisk would merely allow you to easily
manage one port (4569) through which all your signaling and audio is passed
through.  It does increase the headache of managing another box though.
However with a 2nd * you would not have to worry about forwarding or
allowing a larger range of ports in your VPN and/or Firewall.

My motto has always been to keep things simple.  A VPN increases complexity
and introduces over engineering (in my humble opinion).  It definitely has
benefits, but in an office of 10 or less people -- I see VOIP on VPN, adding
more complexity to debug technical issues.    Just my 2 cents.

Cheers!
Reza.

----- Original Message -----
From: "Mark Borg" <[EMAIL PROTECTED]>
To: "Reza - Asterisk Enthusiast" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Tuesday, May 22, 2007 9:55 AM
Subject: Re: [on-asterisk] rtp working thru vpn....

>
> Hi Reza, would you have a thought as to why rtp doesn't seem to pass thru
a
> vpn tunnel? Still with this same config; it registers and I can dial the
> remote, it rings then hangs up immediate. I have reinvite=no and also
nat=yes
> so reinvite should be disabled anyways. it looks to me like the rtp route
is
> not succeeding - is it a property of vpn not to pass udp?
> some items from the sip debug log -
> "peer audio RTp is at port 192.168.0.226:3000"  - so * sees the port...
> "capabilities ...." both have ulaw/alaw avail;
> sip show peers shows monitored status at 135ms -
>
> i see no reason that rtp would not pass transparent thru vpn tunnel.
>
> in your opinion should i stick a second * at the remote site & use iax
instead
> of trying to make sip/rtp work?
> thanks for your help.
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to