Subject: RE: [AVT] Re: RTP/RTCP Port Sharing -> SCTP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Jul 2001 00:17:39 -0400

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, July 21, 2001 12:53 PM
> To: Michael Thomas
> Cc: Jonathan Rosenberg; Fairlie-Cuninghame, Robert; 'Leonid 
> Rosenboim';
> Ross Finlayson; [email-masked]
> Subject: Re: [AVT] Re: RTP/RTCP Port Sharing -> SCTP
> 
> 
> 
>>    Sigh. If the end result of most media sessions is a rendezvous
>>    to a intermediary, then our bragging rights over the IN will
>>    be nullified. I know that this is the implication of NAT's, but
>>    it still depresses me.
>
>
>That said, I wonder if it wouldn't be easier to just have the client set
>up one secure tunnel to this outside entity with a real IP address, for
>all applications that are stymied by NATs, rather than inventing a new
>mechanism for each application. This does mean two relaying points, but
>avoids all the negotiation and myriad special cases. Can this be done
>with the typical VPN setups in some of the more recent OSs?

We looked at that as a possible solution. The problems are:

1. its not very viable for standalone devices, like phones, residential
gateways, etc. which are not going to be doing vpn protocols in general

2. since it works at the ip layer (providing a virtual interface), and since
you need to send your RTP out over this interface always, you effectively
need to set this up as a default interface, so that it gets all your
traffic, not just the voip stuff

3. Its TCP and always uses an intermediary, bad for voice quality.

I'll note that our proposed solution in draft-rosenberg-sip-entfw-02
effectively has clients allocating addresses off of a server in the voip
providers network. This is really a form of vpn, but happens at the
application layer, so its focused on a particular application usage (fixing
problem 2 above), and is based on udp (fixing 3). Other than that the idea
is quite similar to using a vpn server.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jul 2001 08:38:07 -0400

> gateways, etc. which are not going to be doing vpn protocols in general

I don't see that ESP or IP-in-IP are particularly difficult.

> traffic, not just the voip stuff

This wouldn't matter for IP phones, since they are not likely to do lots
of non-RTP applications.

> 3. Its TCP and always uses an intermediary, bad for voice quality.

Heh? Since when do you need to do VPNs or tunneling using TCP?

> is quite similar to using a vpn server.

Another reason not to invent a special-case solution if we can identify
a suitably lightweight tunneling solution. The term 'VPN' is probably a
misnomer in this case. What we need is basically an IP-in-IP tunnel
initiated by the inside to the outside box, with periodic refreshes to
keep up the NAT binding. I suspect that some of the multicast tunneling
approaches discussed in this neighborhood might be draftable. You need
that in any event if you want to be able to receive incoming calls.