Subject: Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 3 Jun 2008 10:42:47 +0200

This mail tries to sum-up the conversations of the WGLC and makes
proposals for a next update of the draft.

1 - 0 bytes packets:
There's a need to merge sections 4.1 and 4.2 and to generalize the
section for any RTP-capable transport protocol.

2 - static payload
There is no consensus to accept a static payload number for
rtp-keepalive, so the draft will keep a dynamic payload type.

3 - Advertisement of rtp-keepalive with SDP
There's some interest to declare support for rtp-keepalive in the SDP.
Do we want to make it mandatory or recommended?

Note that doing so requires the registration of additional media types
(like audio/rtp-keepalive, video/rtp-keepalive, and
text/rtp-keepalive, application/rtp-keepalive). In addition, it should
also be noted the indication for rtp-keepalive support within an SDP
offer is a declarative usage only, as the the local agent will use
rtp-keepalive even if the peer does not support this format in the SDP
answer.

4 - Security issues
There's a need to discuss that RTP keepalive packets may be perceived
as an attack by the peer and that the peer needs to react as described
by RFC3550 by ignoring them.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 3 Jun 2008 14:29:14 -0700

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Sunday, April 27, 2008 7:27 AM
> To: Hadriel Kaplan
> Cc: Cullen Jennings; [email-masked] WG; Dan Wing; Tom 
> Taylor; IETF AVT WG; MARJOU Xavier RD-MAPS-LAN
> Subject: Re: [AVT] Working Group LastCall: 
> draft-ietf-avt-app-rtp-keepalive-03.txt
> 
> On 26 Apr 2008, at 17:11, Hadriel Kaplan wrote:
> >> -----Original Message-----
> >> From: Colin Perkins [mailto:[email-masked]]
> >>
> >> Static payload types were deprecated over a decade ago. 
> Negotiating a
> >> no-op payload type in SDP makes sense, but I really don't want to
> >> revisit static assignments.
> >
> > Yeah, I knew you'd say that. :)
> > I'd be happy if there were at least some SDP indication.  Even if  
> > the sender ignores the lack of it in received SDP and sends empty  
> > RTP anyway, it would be useful to have it indicate support for it  
> > and its PT in the SDP it sends.
> 
> Sure, I have no argument with that.
> 
> >>> I find it odd that a WG BCP would recommend a mechanism (albeit a
> >>> fallback one), that is not itself defined in a standards track doc
> >>> anywhere.  Maybe it's just me though. :)
> >>
> >> There were also concerns about having IPR on a no-op format, if I
> >> remember correctly. https://datatracker.ietf.org/ipr/854/
> >
> > I thought that was Cisco's classic defensive patent statement,  
> > which other IETF RFC's have been OK with.  And I'm suggesting a  
> > different form of no-op: an empty one.  Regardless, if an 
> > empty RTP is covered by that IPR, then so is this keepalive 
> > draft, no?
> 
> Possibly - you'd have to ask Cisco.

I checked with our in-house attorneys about our IPR declaration
against draft-ietf-avt-app-rtp-keepalive, and we would keep that
same IPR declaration even with an empty RTP no-op.  The IPR 
declaration allows use of any of our patents necessary to
implement no-op, so long as no-op becomes a standard.

I hope that helps clarify things,
-d