TURN simplification: sequential ports

I frequently get complaints that TURN is too complicated, so it is worth 
considering what simplifications would be useful to accept.

One such simplification proposed by Cullen Jennings was to remove the 
feature that allows you to request the port number one higher than the 
current request, for the purposes of sequential RTP/RTCP port pairing. 
The argument for removing this is that an implementation that does 
TURN/ICE will very likely be doing RFC3605 (the RTCP attribute in SDP), 
since it would need that for STUN-derived addresses anyway. If you can 
do RFC3605, and your peer supports it, there is no need for sequential 
addresses. Since you need to be prepared for doing this anyway, why not 
always do it.

The counter-argument is that, if your peer in the session doesn't do RFC 
3605 (liekly if it doesnt do ICE either), we would still get RTCP in the 
session if we retain this feature in TURN, otherwise, we lose it.

I think there would be a decent simplification if this feature were 
removed, how many pages, I'd have to see.

I'd be inclined to remove the feature. Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email protected]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com