Subject: [payload] Comment to draft-ietf-payload-rtp-opus-01

From: Tina le Grand <[email-masked]>
Date: Fri, 6 Sep 2013 14:15:06 +0200

In section 3.1.3 Discontinuous Transmission (DTX), I'm missing some text
that explains how to update the RTP packets correctly after a silent
period. How should rtp timestamp and sequence number be updated while not
sending rtp packets (silent period), to prepare for when we eventually have
data to transmit again? My thinking is that rtp timestamp should be updated
with the number of samples that were not sent, while sequence number should
only be updated when sending packets. Correct?

/Tina le Grand.

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 06 Sep 2013 15:19:39 -0400

On 09/06/2013 08:15 AM, Tina le Grand wrote:
> In section 3.1.3 Discontinuous Transmission (DTX), I'm missing some
> text that explains how to update the RTP packets correctly after a
> silent period. How should rtp timestamp and sequence number be
> updated while not sending rtp packets (silent period), to prepare
> for when we eventually have data to transmit again? My thinking is
> that rtp timestamp should be updated with the number of samples
> that were not sent, while sequence number should only be updated
> when sending packets. Correct?

That's also my understanding, but I'm far from an expert on this. Can
anyone with good knowledge of RTP confirm that it's the right thing to do?

	Jean-Marc

---

From: Roman Shpount <[email-masked]>
Date: Fri, 6 Sep 2013 15:46:50 -0400

> anyone with good knowledge of RTP confirm that it's the right thing to do?
In my experience and according to RFC 3551 this is the right thing to do.
Furthermore, the first packet of a talkspurt, that is, the first packet
after a silence period during which packets have not been transmitted
contiguously, SHOULD be distinguished by setting the marker bit in the RTP
data header to one. Also, since this is already standard behavior for all
audio codecs according to RFC 3551 there is probably no need to define this
behavior specifically for OPUS.
_____________
Roman Shpount

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 6 Sep 2013 20:10:10 +0000

That's correct. See RFC 3551 section 4.1.

Since Opus DTX mode uses receiver concealment and comfort noise, it may be good to specify that the generic CN payload (RFC 3389) should not be used with Opus.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Friday, September 06, 2013 3:20 PM
To: Tina le Grand
Cc: [email-masked]
Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01

	Jean-Marc

_______________________________________________
payload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/payload

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 06 Sep 2013 17:19:04 -0400

On 09/06/2013 03:46 PM, Roman Shpount wrote:
> In my experience and according to RFC 3551 this is the right thing
> to do. Furthermore, the first packet of a talkspurt, that is, the
> first packet after a silence period during which packets have not
> been transmitted contiguously, SHOULD be distinguished by setting
> the marker bit in the RTP data header to one. Also, since this is
> already standard behavior for all audio codecs according to RFC
> 3551 there is probably no need to define this behavior specifically
> for OPUS.

When in DTX mode, the Opus encoder will send a single "refresh" packet
every few seconds with the current noise level. Outside the encoder,
these packets are indistinguishable from normal Opus packets. Should
they have the marker bit set too or only the ones that correspond to
new voice activity. In the latter case, we'd have to figure out a way
to tell the refresh packets from the voice onset ones.

	Jean-Marc

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 6 Sep 2013 21:32:59 +0000

Only voice onset after silence should set the marker bit, to aid in adjusting playout delay buffers. This, too, is covered in RFC 3551 section 4.1.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Friday, September 06, 2013 5:19 PM
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [payload] Comment to draft-ietf-payload-rtp-opus-01

	Jean-Marc

---

From: Roman Shpount <[email-masked]>
Date: Fri, 6 Sep 2013 17:35:17 -0400

On Fri, Sep 6, 2013 at 5:19 PM, Jean-Marc Valin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
Per RFC 3551 Section 4.1:

For applications which send either no packets or occasional comfort-noise
packets during silence, the first packet of a talkspur, that is, the first
packet after a silence period during which packets have not been
transmitted contiguously, SHOULD be distinguished by setting the marker bit
in the RTP data header to one.  The marker bit in all other packets is
zero.

So according to this only the first packet in a talkspur with voice onset
should have the marker bit set. Comfort noise packets should not have it.
_____________
Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Sep 2013 16:08:07 +0200

On 2013-09-06 23:35, Roman Shpount wrote:
> On Fri, Sep 6, 2013 at 5:19 PM, Jean-Marc Valin <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> For applications which send either no packets or occasional
> comfort-noise packets during silence, the first packet of a talkspur,
> that is, the first packet after a silence period during which packets
> have not been transmitted contiguously, SHOULD be distinguished by
> setting the marker bit in the RTP data header to one.  The marker bit in
> all other packets is zero.
> 
> So according to this only the first packet in a talkspur with voice
> onset should have the marker bit set. Comfort noise packets should not
> have it.

The behavior of the marker bit is up to every RTP Payload format to
define. However, I do recommend that you use this common behavior for
any codec carrying voice.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Sep 2013 16:12:21 +0200

On 2013-09-06 21:19, Jean-Marc Valin wrote:
>> In section 3.1.3 Discontinuous Transmission (DTX), I'm missing
>> some text that explains how to update the RTP packets correctly
>> after a silent period. How should rtp timestamp and sequence
>> number be updated while not sending rtp packets (silent period),
>> to prepare for when we eventually have data to transmit again? My
>> thinking is that rtp timestamp should be updated with the number
>> of samples that were not sent, while sequence number should only
>> be updated when sending packets. Correct?
> 
> That's also my understanding, but I'm far from an expert on this.
> Can anyone with good knowledge of RTP confirm that it's the right
> thing to do?
> 

Yes, that is correct and should be easily to derive based on your
timestamp usage definition also. For voice the common rule is to
define the TS as the timestamp value corresponding to the earliest
sample present in the payload. Which is what you have done.

>From that follows in case of DTX that the packet after "skipped"
frames will have a TS field jumping to the start of the frame actually
included.

Cheers

Magnus Westerlund

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 10 Sep 2013 00:47:28 -0700

> any codec carrying voice.

Okay, sounds like we should add a normative reference to RFC 3551 
Section 4.1, then.