Moving draft-marjou-behave-app-rtp-keepalive to AVT

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)


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

> 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


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

Hi,

I think that defining the keepalive for RTP that will not
break RTP is
an important work and can be done in AVT. 
I read the draft and it looks like a good start. I support
as having it
an AVT working group draft


Roni Even 

> -----Original Message-----
> From: Colin Perkins [mailto:cspcsperkins.org]
> Sent: Friday, June 01, 2007 8:15 PM
> To: IETF AVT WG; behaveietf.org; mmusic
> Cc: Even, Roni; Tom Taylor; Dan Wing ((dwing)); Cullen
Jennings; Joerg
> Ott; Xavier Marjou; Jean-Francois Mule; Magnus
Westerlund
> Subject: Moving draft-marjou-behave-app-rtp-keepalive
to AVT
> 
> 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)


_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave

On 1 Jun 2007, at 18:15, Colin Perkins wrote:
> 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.

There were several comments in favour of this proposal, and
no  
objections. Accordingly, we will take this draft as an AVT
work item.

-- 
Colin Perkins
http://csperkins.org/




_______________________________________________
Behave mailing list
Behaveietf.org
https:/
/www1.ietf.org/mailman/listinfo/behave