Subject: [AVT] RFC 4585 BNF issues/problems

From: Randell Jesup <[email-masked]>
Date: Thu, 15 May 2008 11:10:15 -0400

[ Note: I tried to send this over a week ago, and the avt reflector never
seemed to take delivery.  Eventually my MTA stopped trying and sent it
back.]

An additional two bugs/issues in RFC 4585 I just found.  Both are mostly
editing and coherency issues for the RFC, but they point (again, especially
the first item) to areas that could lead to subtly-incompatible
implementations). 

--------------------------------------
First issue:
Minor: The "wild card" for payload value for rtcp-fb:

In section 4.2, it says:
   A wildcard payload type ("*") MAY be used to indicate that the
   RTCP feedback attribute applies to all payload types.  If several
   types of feedback are supported and/or the same feedback shall be
   specified for a subset of the payload types, several "a=rtcp-fb"
   lines MUST be used.

and in Section 4.4 Example #2:
      m=video 51372 RTP/AVPF 98 99
      ...
      a=rtcp-fb:* nack
      a=rtcp-fb:98 nack rpsi

RFC 4566 never envisions "*" for a payload type in a media-level attribute,
so it doesn't mention it.  The issue is a minor one, which is that there's
an implication here that you must check them all until you find an exact
match, and if there isn't one use * (if given).  The wording above from the
RFC is ambiguous; literally it could be taken to mean that in the example,
the * entry would override the rtcp-fb:98 entry (which I'm sure was NOT the
intent).  This design has the side-effect of requiring an entirely
different parsing and checking functionality from the normal way of
processing a= values, which can stop on the first hit for the media, or
first hit for the session.

--------------------------------------
Second issue:
Minor/medium: invalid SDP in example

Section 4.4 (Examples)

Example 3 has:
      m=video 51372 RTP/AVP 98 99
      c=IN IP4 224.2.1.184
      ...
      m=video 51372 RTP/AVPF 98 99
      c=IN IP4 224.2.1.184

in the same SDP.  It says in the text:
   Note that both media descriptions use the same addresses; however, two
   m= lines are needed to convey information about both applicable RTP
   profiles.
and
   Note that these two m= lines SHOULD be grouped by some appropriate
   mechanism to indicate that both are alternatives actually conveying
   the same contents.  A sample framework by which this can be
   achieved is defined in [10].

However, barring such grouping actually being used, the SDP as given is
illegal - you have two m= lines with the same IP (c=) and port.  SHOULD
implies you don't have to.  

I realize that the upcoming, all-singing-all-dancing
(likely-to-never-work-correctly...) "capability negotiation" spec can handle
this and reduce it to one m= line.  However, that mechanism isn't being
used here either.

   Aside on capability negotiation: My apologies for the cynicism, but the
   very simple and imlementable "best-effort-srtp" effort has dissolved
   into the ongoing "capability negotiation" draft, which appears
   more-than-complex to properly (and interoperably!) implement.  Probably
   only ICE is more complex - and there's a lot more impetus to complete
   and test ICE.

   That's not to say it can't be implemented; just that as with any complex
   spec with hard-to-read syntax in the messages, I worry it's going to be
   a task to get any two implementations to reliably talk to each other
   outside of the "simple" cases.  Perhaps I'm wrong; I have not been
   following mmusic very often, and I have not been trying to track it with
   an implementation.

   Also, part of the entire point of cap negotiation was to *avoid* the
   complexity of a second-pass reINVITE/answer, and from what I've been
   reading lately that's now required or encouraged in a number of cases.
   (As it is now in ICE.)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt