There has been some private discussion on adopting the draft on
Application Mechanisms for maintaining alive NAT mappings associated
with RTP flows (draft-marjou-behave-app-rtp-keepalive-01.txt) as an
AVT working group draft. This has previously been discussed in AVT,
BEHAVE and MMUSIC. Opinions on whether this draft should become a
working group draft, and on the appropriate home for it, are
solicited by 8 June 2007.
Colin (as AVT co-chair)
We need a document that consolidates NAT keepalive mechanisms for
UDP-based protocols, most notably RTP (and, to a lesser extent,
SIP). Currently this is spread in various documents and there
is no consolidated guidance to implementtors on the strength
or weakness of various approaches. Section 4 of Xavier's
document shows the current state of the art -- 7 different
keepalive techniques are in various levels of active use.
Most of the keepalive techniques apply to RTP, and thus AVT seems
the best home. There are a few exceptions which don't fit into
AVT, such as the keepalive technique used by SIP Outbound
(draft-ietf-sip-outbound), but I don't see the exceptions as
significant enough to resist making this an AVT WG item. If we
had an "RAIWG" (akin to TSVWG), it might fit best there, but we
don't have one. It doesn't quite fit into BEHAVE, as NATs only
care to see a UDP packet is occasionally sent to the peer and
NATs don't care what sort of UDP packet is sent; however, the
receiving peer may very much care if it's a STUN packet, a
0-byte packet, or the 5 other types of packets described in
Xavier's document.
I support adding a milestone to AVT for keepalives, and adopting
that document to meet that milestone.
-d
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt