Subject: Re: [AVT] Question on RTP sequence number in RFC2833 and bis-02

From: Eric Cheung <[email-masked]>
Date: Fri, 07 Mar 2003 11:25:59 -0500

Hi, I am still hoping that I can get some clarification from the WG on 
this question.  Apologies if this was discussed before, but I could not 
find anything by searching on the archive.

Thanks
Eric

Eric Cheung wrote:
> Hi Henning, Scott
> 
> Want to clarify a fine point.
> 
> In RFC2833:
> 
>    If there has been no new event
>    in the last interval, the event SHOULD be retransmitted three times
>    or until the next event is recognized.
> 
> Q1: For a device conforming to RFC2833, should the RTP sequence number 
> in the 3 packets be incremented, or should they be the same?
> 
> 
> In RFC2833bis-02, this seems to be clarified:
> 
>    If an event has ended and
>    there has been no new event in the last interval, the event SHOULD be
>    retransmitted three times at the interval used by the source for
>    updates.
> 
>    In all cases, the RTP sequence number MUST be incremented by one in
>    each RTP packet.
> 
> Q2: Can you confirm that if a device conforms to bis-02, the sequence 
> number in the 3 packets will be monotonically increasing?
> 
> Q3: In writing this, I realize that I am not sure whether there should 
> be 4 packets (1 original transmission + 3 retransmission) or 3 packets. 
>  Can you clarify this?
> 
> 
> Sorry for the nit-picking, but when testing it seems many devices do 
> many different things when it comes to 2833.
> 
> Thanks
> Eric

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

---

From: Eric Cheung <[email-masked]>
Date: Fri, 21 Mar 2003 09:10:50 -0500

Henning Schulzrinne and I discussed this at IETF 56, and I am sending 
this to close this thread.

The RTP packets sent out at the end an event should have increasing 
sequence number.  This is primarily so that the receiver can detect if 
one or more of these packets are lost.  If they all have the same 
sequence number, then there is no way for the receiver to tell.

Some implementations I have tested send out 3 packets with same sequence 
number.  This should not present a major problem in terms of receiver 
recognizing the DTMF event, but may cause inaccurate RTCP reports.

Thanks
Eric

Eric Cheung wrote:
>> be 4 packets (1 original transmission + 3 retransmission) or 3 
>> packets.  Can you clarify this?
>>
>>

---

From: Greg Herlein <[email-masked]>
Date: Fri, 21 Mar 2003 07:00:10 -0800 (PST)

To those expecting my presentation yesterday on the Speex codec,
I apologize for not being there.  I was caught out in the traffic
mess that occurred due to the anti-war protests - I could not get
to the meeting in time.

I hope that you all had a chance to look at the codec and the
profile anyway, and that if you have comments you will make them
to the list or privately.

Version 1.0 of the codec specification and implementation will be
released on Monday.  We ask that if you have concerns about the
actual codec portion (as opposed to the RTP Profile) that you
make those concerns known immediatley if you think it should
delay the 1.0 release.

Again, sorry I could not make it.  

Greg

---

From: Stephen Casner <[email-masked]>
Date: Fri, 21 Mar 2003 08:58:23 -0800 (PST)

Greg,

> mess that occurred due to the anti-war protests - I could not get

I did step through your slides so that the audience could read them,
although that is not the same as the presentation you would have
made.

> to the list or privately.

One quick correction:  your document is a "payload format" not a
"profile".  The the introduction of the RTP spec for the explanation
of the difference.

                                                        -- Steve

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 21 Mar 2003 18:55:15 -0800

Greg,

Sorry you couldn't make the meeting.  Here were some comments that I had 
planned to make about the Speex RTP packet format:

1/ It's quite common in audio payload formats to use the RTP 'M' bit to 
indicate the start of a talkspurt 
<http://www.cs.columbia.edu/~hgs/rtp/faq.html#marker>.  You might want to 
do the same (assuming, of course, that you plan to allow for senders to 
avoid sending packets during periods of silence).

2/ Having the number of frames per RTP packet indicated 'out of 
band'  (i.e., using SDP) is unorthodox, and rather inflexible.  The 
alternative, more common approach is to indicate that 'in band' - i.e., in 
the RTP packet itself.  Because Speex frames are variable-length (correct?) 
and don't have a 'sync word' to indicate their start (correct?), you could 
do this by having a 'packet length' descriptor precede each Speex frame in 
a RTP packet.

3/ Similarly, what happens if a Speex frame is too large to fit in a RTP 
packet?  Although Speex frames may be quite small, you should also allow 
for the possibility of RTP packets being even smaller.

To deal with 2/ and 3/, you might consider having a descriptor - preceding 
each Speex frame in a RTP packet - something like the following:

+-+-+-+-+-+-+-+-+
| S|E|D|    L    |
+-+-+-+-+-+-+-+-+

where:
- S (1 bit): Set to 1 iff the packet contains the start of a Speex frame 
(or one or more complete Speex frames)
- E (1 bit): Set to 1 iff the packet contains the end of a Speex frame (or 
one or more complete Speex frames)
- D (1 bit): Set to 0 if the descriptor is 1 octet (i.e., 8 bits) 
long.  Set to 1 if the descriptor is 2 octets (i.e., 16 bits) long.
- L (5 bits, or 13 bits, depending on "D"): The length of the following 
Speex frame.  As a special case, a value of zero could mean: The entire 
remainder of the RTP packet is a single Speex frame.  (Thus, if having just 
a single Speex frame per RTP packet is going to be the common case, then 
you could indicate this using just a single 0xC0 descriptor byte.)

	Ross.

---

From: Greg Herlein <[email-masked]>
Date: Sat, 22 Mar 2003 07:14:11 -0800 (PST)

The overwhelming design goal for the speex codec implementation
in RTP is "keep it as simple as possible" - at least so far.  I
know that the speex community will embrace anything that makes
sense though, so comments are very welcome.

> avoid sending packets during periods of silence).

If speek is used in VBR with VAD enabled, then I don't think this
is needed.  The "silent frame" is only 5 bits long, so while it's
not "avoiding sending packets" it is certainly saving lots of
bandwidth.  And it's totally transparent - the codec library
takes care of it.  Marker bits used this way are only hints -
there is always the timestamp too.  And, relying on a bit in a
packet that may be lost seems unwise.  The codec deals with it
internally seemingly fine.  Why make it harder?

Sending such a "silent packet" is good too, since (assuming it
arrives) it tells the decoder that there is in facta silent frame
allowing it to play CN if it wants, and to keep the jitter
playback buffer happily syncronized.

> 2/ Having the number of frames per RTP packet indicated 'out
> of band' (i.e., using SDP) is unorthodox, and rather
> inflexible.  The alternative, more common approach is to
> indicate that 'in band' - i.e., in the RTP packet itself.  
> Because Speex frames are variable-length (correct?)  and
> don't have a 'sync word' to indicate their start (correct?),
> you could do this by having a 'packet length' descriptor
> precede each Speex frame in a RTP packet.

Well, that was argued at length on the speex list.  The normal
way to use speex will be one frame per packet.  That being the
case, sending an extra octet in every frame only adds overhead
that serves no useful purpose.  Most of the speex folks seemed in
favor of requiring out-of-band means to signal the unusual.

> 3/ Similarly, what happens if a Speex frame is too large to
> fit in a RTP packet?  Although Speex frames may be quite
> small, you should also allow for the possibility of RTP
> packets being even smaller.

Hmmmm.  We'll have to think about that.  I don't think you can
split a G.723.1 frame across multiple RTP packets, so why have
that capability in Speex?  The largest single Speex frame is 110
bytes long (that's 44kbps rate sampled at 32kHz) ... so even on
networks with small MTUs that should not be a problem.  The
nominal 8000kbps (8kHz sample rate) VoIP type frame would be only
20 bytes long.  I susepct that no MTU will ever be smaller than
that!

> each Speex frame in a RTP packet - something like the following:

<snip>

Well, same concern as above - your suggestion has come up before
(remarkably similar to other proposals too - we all tend to think
a bit alike it seems) but is it really needed to add that
constant extra bits of overhead?

One argument is that it's *only* a single octet.  The other is
that any overhead not needed in a majority of the cases is
wasteful bloat.  

I'd love to hear comments from the wider AVT community on this.  

Greg

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Mar 2003 10:24:51 -0500

> internally seemingly fine.  Why make it harder?

Because M bits are useful hints to other applications that may not know 
the details of the codec format. Thus, all voice codecs should use them 
unless there's a really, really good reason not to.

One of the design goals of RTP is to allow codec-unaware entities by 
providing hints about clock rates, silence periods and the like. I see 
no reason why Speex should deviate from this well-proven design.

Henning

---

From: Greg Herlein <[email-masked]>
Date: Sun, 23 Mar 2003 13:37:42 -0800 (PST)

> unless there's a really, really good reason not to.

Well, I would argue (with all due respect) that other
applications that don't know how to decode a codec should not set
up that stream in the first place.  :)  I would argue that the
marker bit is defined in the codec profile and if you don't know
the details of the codec, you probably won't know what the marker
bit means.  It might mean something else entirely. :)

But, seriously, RFC1890 states: 

"For applications which send no packets during silence, the first
packet of a talkspurt (first packet after a silence period) is
distinguished by setting the marker bit in the RTP data header.  
Applications without silence suppression set the bit to zero.' "

It turns out that using libspeex it's implementation-specific
whether you send 5-bit frames (padded to one octet) during
silence, or whether you send nothing during silence.  You *do*
get the 5 bit value in the byte returned when you encode the
frame.  However, contrary to at least my understanding, you do
*NOT* have to send that frame for libspeex to happily cruise
along on the decoder side.  If you don't send it, libspeex still
does the right thing.  If you do send it, libspeex still does the
right thing.

But, to retain the behavior of other "well-proven designs" I
propose that we add language to the speex payload format that
states that if an implementaion sends the 5-bit silence frame (as
a one octet payload) that it SHOULD set the marker bit in the
first subsequent packet that contains valid audio (non-silence)
data.  If the implementation does not send silence frames, then
it MUST set the marker bit in the first subsequent packet that
contains valid audio (non-silence) data.

> no reason why Speex should deviate from this well-proven design.

I certainly did not intend to deviate from anything.  I was only
saying that if we send a (short) frame that is effectively a
placeholder meaning "silence" then there was no need for the
marker bit, and if there was no need, then it would be redundant
to require it to be included.  But, if it breaks other stuff to
not set that bit, then by all means let's state it must be set.

Greg

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Mar 2003 16:58:53 -0500

Among other reasons, the M bit allows codec-unaware applications to 
perform better playout delay adaptation (since you want to do those 
during silence, not talk spurts). Thus, I'm glad to hear that Speex will 
make this possible.

Also, this is *not* an 'extra' bit. You already paid for it :-)

> marker bit, and if there was no need, then it would be redundant

Assuming you know the codec. My premise was that you didn't.

---

From: Jean-Marc Valin <[email-masked]>
Date: Sat, 22 Mar 2003 12:53:36 -0500

I haven't got the full context, so I hope what I'm saying makes sense.

> internally seemingly fine.  Why make it harder?

Actually, the "silence frames" can only happen when DTX is enabled (just
VBR or VAD is not enough). Also, while in Ogg files they are encoded
with 5 bits, in network applications, there's really _no transmission_.
Note also that the way it works is that there's already a flag in the
last packet before silence that says "from now on, if you don't recieve
anything, it's noise not packet loss". BTW, although for now we're not
using the marker bit, it may still be good to set it.

> favor of requiring out-of-band means to signal the unusual.

I think I agree on your point. While if would be possible to get clever
tricks to find the number of packets from the packet length, I don't
think it's really clean.

	Jean-Marc

-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Mar 2003 14:47:55 -0500

A few comments inline - I'll skip the M bit issue, since I agree with
Henning's comments.

--> Greg Herlein writes:
...
>favor of requiring out-of-band means to signal the unusual.

The EVRC payload format addresses this by defining a simple format where
only a single frame is included in the packet, and a more complex format
which has a header and multiple frames. The signalling then selects which
of the two formats is used. This may be an acceptable solution here, too.

Alternatively, if you can tell the length of the frame by parsing the frame
data, there is no need to signal the number of frames per packet.

>20 bytes long.  I susepct that no MTU will ever be smaller than

Given the small size of the packets, it's probably acceptable to leave
fragementation to the IP layer. 

Cheers,
Colin

---

From: Greg Herlein <[email-masked]>
Date: Mon, 24 Mar 2003 12:05:13 -0800 (PST)

> of the two formats is used. This may be an acceptable solution here, too.

Is it *that* bad a thing to just let the signalling define the
number of frames in a packet in the first place, the way it's
currently defined?

> data, there is no need to signal the number of frames per packet.

That's not possible, unfortunately.

Greg

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Mar 2003 15:55:01 -0500

>number of frames in a packet in the first place, the way it's

No, it's just a little unusual.  If there's no reason why a sender would
want to change the number of frames per packet, then signaling it out of
band is entirely appropriate. 

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Mar 2003 13:37:54 +0100

>band is entirely appropriate. 

Yes, but there normally exist one very good reason why one wants to 
change the number of frames per packet, congestion control. For most low 
bit-rate codecs the simplest way of reducing the bit-rate is simple to 
reduce the number of packets sent. As the IP/UDP/RTP headers often 
represents a bit-rate  of one or more complete audio streams. By sending 
two instead of one frame per packet the rate can often be reduced by 
30%. However as this trade off often comes at the expense of less 
robustness and increased end-to-end delay one tries to avoid it if 
possible. Therefore it is reasonable to be able to change this on the 
fly. However if the Speex codec contains other mechanisms that are 
useful to change the bit-rate then it might not be necessary.

An alternative way if to actually define different payload types when 
there might be need for different packetizations.

Another point, if you have variable frame length how does one 
distinguish the end of one frame from the beginning of the next? If you 
don't have such a difference it will not be possible to demultiplex at 
the receiver.

Best Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]