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

Howdy,
In general I like the draft - it's short and to the point. :)
I have the following comments:

1) The recommended "fallback" mechanism of using an RTP packet with an unknown payload format has issues.  I *know* there are devices which can't handle it.  I know this because SBC's have been specifically requested by operators to block such packets, because they were causing issues for some RTP devices.  We can argue that RFC 3550 said a receiver MUST ignore such packets, but there is a big difference between handling error cases, and *testing* for such compliance by using it actively for a "feature".  For example on some devices it causes error logs to be generated. (on others, worse)

I recognize that this is probably unavoidable for any mechanism we pick, because the requirements are that it not be negotiated in SDP (right?).  But I think it warrants certain changes in the text of the draft, which I note here:
        a) Section 4.7 Recommendation section currently implies this is the recommendation, but that's not really true.  It should say "This method is recommended as a fallback, only if explicitly signaled methods such as [DRAFT-RTP-RTCP] or STUN through [DRAFT-ICE] are not possible."
        b) Section 5, page 8, last sentence should be changed from "...as it will always work." to "...as it will usually work."
        c) Security section 8 is wrong - it *does* imply security issues, clearly.  So I recommend you add "Using the mechanism in Section 4.7 could be perceived as an attack by the peer.  [RFC3550] explicitly stated devices MUST ignore unknown payload formats, however security devices may block such packets."  Or something like that I guess.

2) In some ways, the recommended fallback of RTP with an unknown payload type is simply the draft-ietf-avt-rtp-no-op packet, just without SDP negotiation, and no 4-byte payload - right?  One of the things I liked about that draft was it negotiated it in SDP. :)  I realize you're trying to not make that necessary, so can we at least give this a fixed defined payload type number??  I think giving up one of the few left (are there any?) is worth it for this, because we're not negotiating it in SDP.

3) I also still think there should be optional SDP for the empty RTP keeaplive, just so that "evil" middleboxes trying to protect devices can know they can let these things past.  I realize that can't be done in a BCP, so I think draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP keepalive, and define the SDP. (I'm not sure why it expired)

4) This is basically a nit: like Remi, I'm not quite clear why Sections 4.1 and 4.2 UDP and DCCP transports are separate from each other or others, for zero-byte "packets".  With TCP, obviously a 0-byte segment is not exactly the same as a TCP keepalive, and for SCTP it has a native heartbeat, so maybe those differences explain it. (and I'm not sure how one forces a TCP stack to send a 0 byte segment from above the socket)  But as far as I know, all of them can handle receiving a 0-byte payload.  A nit, anyway.

-hadriel

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Tom
> Taylor
> Sent: Wednesday, April 23, 2008 2:56 PM
> To: IETF AVT WG; behave@ietf.org
> Cc: Cullen Jennings; MARJOU Xavier RD-MAPS-LAN
> Subject: [AVT] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-
> 03.txt
>
> This is to announce Working Group Last Call for
> draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes well, the Last
> Call
> period will end on May 7.
>
> Given the subject matter, the BEHAVE list is also copied on this message.
>
> Tom Taylor for the Chairs.
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave