Subject: [MMUSIC] Use of STUN for RTP keepalives

From: "Michael Slavitch" <[email-masked]>
Date: Wed, 17 Aug 2005 10:41:43 -0400

Hello,

Can I ask what the need is for using STUN rather than simple noop for
RTP keepalives?  Doesn't this create additional complexity that really
is not needed?  Likewise for SIP shouldn't a no-op be used for a
keepalive to keep the binding alive with a fallback to STUN if the
keepalive has failed?

Regards,

Michael

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Aug 2005 22:05:57 -0400

Lets look at media and signaling separately.

For media, the benefits of STUN are:

* already in use for the connectivity checks within ICE, making it 
natural to continue this
* doesnt interfere with RTCP statistics since its not RTCP
* generates a response, thus providing a true liveness check as opposed 
to just keeping nat binding alive
* works not just for RTP, but any media transport
* works for any media type or codec (although RTP no-op has the same 
benefit)
* allows for detection of network nat failures and reboots that might 
impact session liveness

For signaling, it makes sense to use RTP no-op, since there is no 
benefit to RTP over STUN, both are different than SIP. For signaling, 
the benefits are:

* generates a resposne thus allows for liveness check of the proxy with 
very low overhead, allowing it to be sent frequently, improving 
responsiveness
* allows for detection of rebooted nats between client and proxy, which 
would result in an undetectable service outage otherwise

-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

---

From: Michael Slavitch <[email-masked]>
Date: Thu, 18 Aug 2005 10:42:58 -0400

What you are saying is in conflict with what is written in the draft, which 
is the following:

"usage of STUN and TURN is at SHOULD strength to allow for provider 
variation."

But at the same time STUN is being proposed as the method for keepalives, 
which should then raise STUN to MANDATORY overall. If you are using STUN for 
keepalives because you're also using STUN for discovery then why is STUN 
usage for discovery at SHOULD strength? This is confusing because there is 
an assertion that STUN being used anyways, but it isn't, because it's a 
should, not a must. So the assertion that STUN is being used anyways is 
refuted by the draft itself. The use of STUN becomes statistical and hence 
much less useful.

And now, given this, what do you mean by STUN? Does it include all the tests 
and functions for client and server as stated in RFC 3489? If not, which 
ones are mandatory and which ones are optional? From reading the draft it 
appears that what is called STUN in ICE is in fact a peer-to-peer offshoot 
of a subset of RFC3489, not a direct literal implementation, so some care, 
feeding and detailed specifics are needed here to get it right.

One example is that authentication isn't useful in the ICE realm between 
peer endpoints, but given a literal interpretation of RFC3489 somebody may 
implement it and be correct given the RFC. But far more important and again 
in RFC3489 "STUN does not work when the STUN server is not in a common 
shared address realm." and "STUN assumes that the server exists on the 
public Internet. If the server is located in another private address realm, 
the user may or may not be able to use its discovered address to communicate 
with other users. There is no way to detect such a condition." 

But ICE uses "STUN" in a peer-to-peer mode, which doesn't reflect what's in 
the original STUN RFC. Given this what is desired in this draft is in direct 
conflict with what is stated in RFC3489, which I guarantee you will lead to 
complete confusion in implementation. Either the STUN RFC needs updating to 
support STUN servers and clients that exist behind NAT gateways or there is 
conflict (or a whole new protocol). Furthermore STUN would need to be 
updated to support both server and client in the SAME privately addressed 
domain, if indeed it is STUN that is used by ICE.

So what's being used in ICE isn't STUN, but a STUN-like peer-to-peer 
discovery and keepalive protocol. And since it's no longer STUN, why use a 
STUN-like protocol when something leaner and meaner may be adequate?

Keepalives, like symmetric RTP, are mandatory requirements for keeping 
pinholes alive for NAT traversal for both SIP signalling and for media. The 
keepalive period is a function of the NAT gateways in use, and can be very 
short, as little as 5 seconds in some cases, as I've discovered through 
testing. To put a protocol in there that does STUN discovery every five 
seconds sounds like overkill especially since the ports have already been 
opened and just need maintenance to keep alive. 

At a minimum a NO-OP with response is needed for TCP, UDP and RTP. The No-op 
works well with all RTP media and I cannot see why it cannot be used for UDP 
and TCP signaling. Now if there is a desire to piggyback a rediscovery then 
you already have much of that in the tx and rx ports of the incoming in-band 
RTP/UDP/TCP message, including the no-op, and you have the expected ports in 
the original SDP message. This is enough for many systems that do what is 
commonly called "protocol repair" without the need for STUN. 

Short keepalives over RTP and UDP with a NO-OP that has a MANDATORY response 
(also a NO-OP) both offer everything that is learned by a STUN discovery, in 
a much simpler protocol. I'm surprised that such a lean protocol isn't being 
considered, especially since what is proposed isn't STUN but a peer-to-peer 
subset that needs a specific definition in any case. 

Michael

-- 
Michael Slavitch
Ottawa, Ontario Canada