Subject: [MMUSIC] ICE issue: STUN vs. STUN over RTP

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 20 Oct 2004 08:52:15 -0400

Since the last IETF, several folks have independently suggested to me 
that we tunnel STUN over RTP, and use that for the connectivity checks. 
The reasoning is that it avoids the ugliness of multiplexing STUN and 
RTP on the same port. There are pros and cons to doing this:

Cons:

- STUN responses would end up being in RTP packets sent in the reverse 
direction, even though RTP is not really a request/response protocol, so 
its a mismatch there

- You'd need to also tunnel STUN over RTCP somehow (app packets?), which 
is getting really ugly

- STUN packets aren't RTP, and things like statistics would get somewhat 
distorted (less severe if you don't do mid-session checks per my other 
note). There would be jumps in timestamps that don't really make sense 
since STUN really isn't real time media

- If SRTP is in use, you couldn't process the STUN packets until the 
SRTP keying had been done. Thats not a big deal, in that ICE requires 
the exchange of username portions to complete within SIP before the STUN 
packets can be processed

- makes the solution RTP specific

Pros:

+ avoids demuxing STUN and RTP on the same port

I think the cons really outweigh the pros, especially if we remove the 
mid-session checks. As such, I'd like to keep the current STUN approach.

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

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic