Subject: Re: [AVT] RFC 4585 BNF issues/problems

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Jul 2008 11:18:26 +0200

Hi Randell,

Sorry about being slow to answer this mail.

Randell Jesup skrev:
> [ 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.]
> 
> I'm resending this message from a month ago because of the gaping lack of
> any response at all.  There is a problematic hole in the BNF for rtcp-fb
> that means that people writing parsers for it will hit incompatibilities
> and/or break when faced with extensions (the first of which is probably
> the CCM RFC).
> 
> We need to decide how people should handle this, and also find out from
> anyone who has already written an RFC 4585 parser (Polycom/Tandberg/etc)
> how they handled this, and if that will cause problems with whatever
> solution we suggest.
> 
> It also points out that the SDP attribute syntax design in most drafts is
> very "loose"; there either isn't a good "example", or people don't know
> where to go to find one.  Something about this should be worked into the
> draft on "how to write an AVT payload draft".

> 
>    Randell
> 
> I was recently re-reading RFC 4585 (RTP/AVPF), and I found a possible
> problem when it's extended by future RFCs (like CCM).
> 
> The BNF is a series of items with spaces, some of which have qualifiers 
> separated by spaces.  For example:
> a=rtcp-fb:* nack
> a=rtcp-fb:* nack pli
> a=rtcp-fb:* nack ack
> a=rtcp-fb:* nack pli ack
This one is not allowed according to the BNF

> a=rtcp-fb:* nack pli ack rpsi

Neither is this one.

> 
> All of those are reasonably well-defined and parseable, modulo the "SP
> token [SP bytestring]" parameter entries for ack and nack.  What token
> would mean in this case is nowhere defined; the BNF is the only place
> 'token' appears in the RFC.

As answered before, I assume RFC 4566 token definition.

> 
> For extensions, it defines rtcp-fb-id and rtcp-fb-param.
> 
> It also says that you must ignore and remove any items you don't
> understand or aren't willing to support.

Yes, but that will be whole lines, not parts of the lines.

> 
> The problem is that rtcp-fb-param can be "SP 'app' [SP byte-string]",
> "SP token [SP byte-string]" or empty.  If a baseline rfc 4585 parser sees
> an unknown token (which matches rtcp-fb-id), how does it know how far
> ahead to skip?  For example

No, here is why this isn't as broken as you think. There is nothing 
allowing you to pile several types of feedback on the same line in the 
SDP. Thus in the below, foo will always bee the rtcp-fb-id and the next 
parameters be the type, and anything more that types parameters.

> 
> So, questions:
> 1) what does "token" mean for ack and nack?  What is the optional
>    bytestring for that case?  It appears that 'token' is there for future
>    expansion with other RFCs.

I also agree that this should be clarified as being the RFC 4566 
definition of token.

> 2) How does an earlier implementation distinguish between "token" additions
>    to ack and nack, and when it sees an rtcp-fb-id how does it know what to
>    do with following values?

As I see it one starts with the fb-id, if known, continue to the next. 
If the parameter is unknown, that whole line is non-understood and is 
removed in answer.

> 3) If we specify (or more likely document) how rfc 4585 parsers work, then
>    we can make sure there's no ambiguity in how following RFCs define their
>    syntax. 

I don't see there being any real issue here.

> 4) Can anyone who's implemented an RFC 4585 parser comment on how they'd
>    handle cases like the above examples?  How does your parser deal with
>    unknown tokens?
> 

I have no implementation, but I don't think the ABNF is broken.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Wed, 23 Jul 2008 13:33:39 -0400

>> a=rtcp-fb:* nack pli ack rpsi

I see my mistake - I assumed you could specify multiple "rtcp-fb-val"s on a
line, when in actuality the BNF shows you can only specify one.  To specify
nack and ack, you need two a=rtcp-fb lines.  I missed this line:

   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.

I was probably led astray by the requirements for many other parameters is
that there's only one of that type per payload (for example, a=fmtp).
Because of that, when starting to read it I was already assuming a single
line.

Thanks for pointing that out.

>As answered before, I assume RFC 4566 token definition.

Good.

   token-char =          %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                         / %x41-5A / %x5E-7E

   token =               1*(token-char)

>Yes, but that will be whole lines, not parts of the lines.

That makes sense, since you can no only have one type of feedback per line.

>I have no implementation, but I don't think the ABNF is broken.

I agree.  Thanks.

-- 
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)