Subject: Re: [AVT] RFC4788 - EVRCB RTP packet

From: "Mike Lim" <[email-masked]>
Date: Thu, 10 Apr 2008 11:23:25 -0700

Hi Hari,

I tried your rtp packet generation executable, and noticed a few things.
	- Header-free format generation works.
	- Bundled format generation works.
	- Interleaved/Bundled format generation seems like not work. I couldn't match with expected format (RFC3558 page 10).
I assumed payload type (0x62) is header-free, (0x63) is interleaved/bundled. Is it right assumption? I couldn't find payload type definition in network for these payload type 0x62 & 0x63. Where is it defined?

Also is it possible to enhance your rtp packet generation tool to support following options?
	- DTX enable/disable
	- ROHC compressed format generation

It will be easier to debug if I get the source. Can you pleas upload the source?

Thank you,
-Mike

-----Original Message-----
From: Desineni, Harikishan [mailto:[email-masked]]
Sent: Thursday, February 14, 2008 10:52 AM
To: Mike Lim
Subject: RE: [AVT] RFC4788 - EVRCB RTP packet

Attached is a tool which can convert evrc-b bit stream into RTP packets

Thanks,
Hari

> -----Original Message-----
> From: Mike Lim [mailto:[email-masked]]
> Sent: Thursday, February 07, 2008 2:03 PM
> To: Desineni, Harikishan
> Subject: RE: [AVT] RFC4788 - EVRCB RTP packet
> 
> Hi Hari,
> 
> I am working on DO RevA VOIP application. I am going to use evrc-b RTP
> packet to verify DO RevA evrc-b VOIP implementation.
> I have raw evrc-b packet data, and I need eiter tools thacan geneate
RTP
> stream, or actual RTP stream.
> 
> Do you have any available RTP bit stream? or is there any tools that
can
> generate RTP bitstream?
> 
> 
> Thank you!
> -Mike
> 
> 
> -----Original Message-----
> From: Desineni, Harikishan [mailto:[email-masked]]
> Sent: Thursday, February 07, 2008 12:40 PM
> To: Mike Lim
> Subject: RE: [AVT] RFC4788 - EVRCB RTP packet
> 
> 
> What kind of application are you using to play with evrc-b bitstream
> data?
> 
> Thanks,
> Hari
> 
> > -----Original Message-----
> > From: Mike Lim [mailto:[email-masked]]
> > Sent: Wednesday, February 06, 2008 1:32 PM
> > To: Desineni, Harikishan
> > Cc: [email-masked]
> > Subject: RE: [AVT] RFC4788 - EVRCB RTP packet
> >
> > Hi Harikishan,
> >
> > Yes. I am looking for RTP packet data, which include EVRC-B data.
> > Could you provide data? or is there any available public domain?
> >
> > Thank you!
> > -Mike
> >
> >
> > -----Original Message-----
> > From: Desineni, Harikishan [mailto:[email-masked]]
> > Sent: Wednesday, February 06, 2008 1:29 PM
> > To: Mike Lim
> > Cc: [email-masked]
> > Subject: RE: [AVT] RFC4788 - EVRCB RTP packet
> >
> >
> > Are you looking for a file (.3g2 or .evb) with EVRC-B data?
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Mike
> > > Lim
> > > Sent: Tuesday, February 05, 2008 10:10 AM
> > > To: [email-masked]
> > > Subject: [AVT] RFC4788 - EVRCB RTP packet
> > >
> > > Hello,
> > >
> > > I am looking for EVRC-B RTP packet ( with RFC4788 specified format
> ).
> > Can
> > > anyone point out if any EVRC-B RTP packet data is available in
> public
> > > domain?
> > >
> > > Thank you!
> > > -Mike
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Fri, 11 Apr 2008 11:19:49 -0400

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
a=rtcp-fb:* nack pli ack rpsi

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.

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.

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

a=rtcp-fb:* foo

is obvious.  This is also easy to deal with, though the parser doesn't know
if 'bar' is an rtcp-fb-param or and rtcp-fb-id.

a=rtcp-fb:* foo bar

But what about this:

a=rtcp-fb:* foo nack
or
a=rtcp-fb:* foo bar nack
or 
a=rtcp-fb:* foo nack bar
or 
a=rtcp-fb:* foo bar nack bar
or 
a=rtcp-fb:* foo bar nack pli bar
or
a=rtcp-fb:* foo bar nack bar ack

Is 'nack' an rfc4585 'nack', a parameter to foo, a parameter to bar, etc?
Is 'bar' an rtcp-fb-id, a 'token' expanding nack, is the following 'ack'
an ack or a parameter to (rtcp-fb-id) bar or a bytestring to (nack token)
bar? 

The parser has no way to scope which variant of rtcp-fb-param is being
used.  There's no delimitation available (like a syntax of "rtcp-fb-id [SP
bytestring] ';'" or "rtcp-fb-id['=' bytestring]".  At minimum, we'd need to
make sure in any extension of rtcp-fb that it can't match any valid prior
rtcp-fb parameter.  And if there are multiple extensions, it gets more
complicated.

I suspect strongly that existing implementations make very simple
assumptions about how to parse, and when they see a string they don't
recognize they throw it away and start parsing again after the space.
Given the ambiguous BNF, there may not be a better choice anyways.

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.
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?
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. 
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?

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