[Asterisk-Users] NAT Far End Traversal

[Greg Hill]

On Wed, 9 Mar 2005, Michael Graves wrote:

> On Wed, 09 Mar 2005 12:54:34 +0400, Jean-Michel Hiver wrote:
>
> >Leo Ann Boon wrote:
> >
> >>
> >>>
> >>> Another question... Are you aware of a SIP ATA or phone that has some
> >>> kind of VPN (i.e. PPTP) client embedded in? This would make the NAT
> >>> problem go away nicely and provide added security...
> >>
> >>
> >> The Zulty's phones support VPN. Then again, many firewalls don't pass
> >> through VPN traffic nicely. Would be cool if we can have a phone that
> >> supports SSL VPNs like OpenVPN.
> >
> >Agreed. In my experience, OpenVPN is a breeze to work with.
>
> Forgive my lack of depth in this area, but aren't SSL based VPNs
> fundamentally IP centric? Whereas RTP & IAX2 streams are UDP? I had
> read some time ago about a company that was planning to revolutionize
> voip through SSL based VPNs, they met with much scorn from those who I
> thought were knowledgable people.

TCP. IP carries both tcp and udp protocols. RTP, IAX, and many other
media-type services use udp. This is because udp doesn't use
acknowledgements for every packet, which means some may get lost and the
sender may never know. With media streams, especially live streams, by the
time you notice a packet got lost it's already too late to try to recover
it. Life goes on and the codec deals with the loss gracefully (or not,
depending). TCP is used by SSL and other data-oriented services where the
bits received absolutely must match those sent, and must also be complete.
TCP provides for acknowledging that packets have been received and
re-transmitting those that got lost.

So, except for the minor slip of using the wrong acronym, you've got the
right idea. Putting media streams through tcp is probably not a good idea
unless you can somehow guarantee that the link will have _extremely_ low
lost or out-of-order packet rates.

Greg