Subject: [AVT] I-D ACTION:draft-ietf-avt-compact-bundled-evrc-06.txt

From: [email-masked]
Date: Fri, 09 Jun 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Enhancements to RTP Payload Formats for EVRC Family Codecs
	Author(s)	: Q. Xie, R. Kapoor
	Filename	: draft-ietf-avt-compact-bundled-evrc-06.txt
	Pages		: 21
	Date		: 2006-6-9
	
This document updates the EVRC RTP payload formats defined in RFC
3558 with several enhancements and extensions.  In particular, it
defines support for the header-free and interleaved/bundled packet
formats for the EVRC-B codec, a new compact bundled format for the
EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX)
support for EVRC and EVRC-B encoded speech transported via RTP.  VoIP
applications operating over low bandwidth dial-up and wireless
networks require such enhancements for efficient use of the
bandwidth.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-compact-bundled-evrc-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-compact-bundled-evrc-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-compact-bundled-evrc-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 14 Jun 2006 21:42:59 +0100

This is to announce a new working group last call on the Enhancements  
to RTP Payload Formats for EVRC Family Codecs <draft-ietf-avt-compact- 
bundled-evrc-06.txt>. Please send any final comments on this draft to  
the mailing list before 23rd June 2006. If no issues are raised by  
that time, we will request the IESG publish this as a proposed  
standard RFC, to update RFC 3558.

Colin

---

From: "Adam Li" <[email-masked]>
Date: Fri, 16 Jun 2006 10:07:27 -0700

Overall it looks fine. A couple of comments on
draft-ietf-avt-compact-bundled-evrc-06.txt:

(1) It would be helpful to discuss how the receiver detects DTX during a
session (by detecting the gap in the stream by matching RTP header timestamp
intervals with payload duration?)

(2) It may be helpful to point out the impact of "dtxmax" setting on the
receiver buffering and delay (as it may need to wait that long to detect a
gap). The receiver may also want to save the "hangover" frames before the
gap to generate silence. That might affect buffering as well (though not
much).

Adam Li

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Mon, 19 Jun 2006 09:19:40 -0700

Adam,

Thanks for your comments. Please find our response below.

> -----Original Message-----
> From: Adam Li [mailto:[email-masked]]
> Sent: Friday, June 16, 2006 10:07 AM
> To: [email-masked]; Kapoor, Rohit
> Cc: 'Colin Perkins'; 'AVT WG'
> Subject: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt
> 

<Rohit> The receiver may not need to use RTP timestamp to detect that it
is in a DTX period. Some implementation could decide to generate comfort
noise if it sees some missing packets (either due to DTX or lost data).
This is largely an implementation choice.

> gap to generate silence. That might affect buffering as well (though
not

<Rohit> Again, receivers could use hangover frames in lots of different
ways.
Some receivers could reconstruct comfort noise even if no hangover
frames were ever received. This also is an implementation choice.

The issues pointed above really refer to implementation choices. We
would like to avoid putting any unnecessary restrictions in this
document on the design choices unless there is an inter-op ramification
or significant performance impact, which we don't see is the case here.

Thus, our proposal would be to not add further text to the draft. Please
let us know what you think.

Thanks,
Rohit

---

From: "Adam Li" <[email-masked]>
Date: Mon, 19 Jun 2006 09:50:50 -0700

Hi Rohit,

> This is largely an implementation choice.

How does one detect missing packets without looking at the SN of the next
received RTP packet? Also, is there a way to detect discontinuity in an
asynchronous stream by other methods than looking at the time stamps? Maybe
you can clarify in the draft on how those are achieved in RTP instead of the
synchronous environment in the wireless networks.

"How to detect DTX" is a protocol issue when the specification supports DTX.
"What to do after it is detected" is an implement issue.

Adam

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 19 Jun 2006 13:43:05 -0500

Hi, Adam,

...
>>>session (by detecting the gap in the stream by matching RTP header
>>>timestamp intervals with payload duration?)
>>

Detecting discontinuity in a RTP stream using timestamp is a common 
operation of any RTP endpoint and there is absolutely no intention to 
change that here. I think what Rohit meant to say was that the RTP 
receiver in this case does not have to know whether it is in a DTX.

> "What to do after it is detected" is an implement issue.

The DTX algorithm was worked out in 3GPP2 TSG-C and for backward 
compatibility reasons it was deliberately made so that the receiver does 
not need to know whether DTX is in force. In other words, it is NOT a 
requirement by the design of the DTX algorithm for the receiver to 
detect DTX. (Of cause, a given implementation is free to build DTX 
detection in its receiver if it feels that's something good to do).

regards,
-Qiaobing

---

From: "Adam Li" <[email-masked]>
Date: Mon, 19 Jun 2006 13:35:22 -0700

Hi Qiaobing,

I understand that DTX is backward compatible with EVRC decoders not
implementing it (Note here you talked about EVRC decoders).

However, we are here talking about RTP sender/receivers of EVRC stream. If
you want to add DTX features in the RTP payload protocol, it is natural that
you will need to define how DTX is used and detected in the RTP
sender/receivers.

It makes little sense to have DTX in RTP but do not say anything about how
it is used in the RTP sender and how it detected in the RTP receiver, just
because the EVRC decoder after the RTP receiver can always decode it even
without knowing DTX.

In my opinion: if we define a feature in the protocol, specify how it is
used and maybe discuss the impact of its usage. Arguing that the decoder
will work without using the feature is irrelevant.

Adam

> From: Qiaobing Xie [mailto:[email-masked]]
> Sent: Monday, June 19, 2006 11:43 AM
> To: Adam Li
> Cc: 'Kapoor, Rohit'; 'Colin Perkins'; 'AVT WG'
> Subject: Re: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt
> 
> Hi, Adam,
> 
> ...

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Mon, 19 Jun 2006 16:31:50 -0700

Adam,

In order to address your concern, we propose to add the following text
for detection of DTX, at the end of Section 1.3.

"An RTP receiver can detect that it is in a DTX period using information
from RTP sequence number and timestamp, since RTP sequence number
increments for each transmitted packet, whereas RTP timestamp increments
regardless of whether frame is transmitted or dropped due to DTX [RFC
3550]".

Please let us know if this addresses your concern.

Thanks,
Rohit

> Sent: Monday, June 19, 2006 1:35 PM
> To: 'Qiaobing Xie'
> Cc: Kapoor, Rohit; 'Colin Perkins'; 'AVT WG'
> Subject: RE: Comments on draft-ietf-avt-compact-bundled-evrc-06.txt
> 
> Hi Qiaobing,
> 
> you want to add DTX features in the RTP payload protocol, it is
natural
> that
> > >>>(1) It would be helpful to discuss how the receiver detects DTX
> during
> > a
> > >><Rohit> The receiver may not need to use RTP timestamp to detect
that
> it
> > > How does one detect missing packets without looking at the SN of
the
> > next
> > > received RTP packet? Also, is there a way to detect discontinuity
in
> an
> > > asynchronous stream by other methods than looking at the time
stamps?
> > Maybe
> > > you can clarify in the draft on how those are achieved in RTP
instead
> of
> > the
> > > "How to detect DTX" is a protocol issue when the specification
> supports
> > DTX.

---

From: "Adam Li" <[email-masked]>
Date: Tue, 20 Jun 2006 08:19:41 -0700

Rohit,

Personally I would like a little more detailed explanation for the clarity
for the reader. Section 1.3 is the only place talks about DTX, and it makes
it not so easy to connect the parameters (dtxmax, dtxmin, and hangover) to
the brief description in Section 1.3. Maybe we can move some descriptions of
those parameters to 1.3 to make the DTX process easier to understand from
reader's perspective. This is up to you.

A little more detail for the other issue I mentioned in original comments:
In the asynchronous stream, a default dtxmax of 32 may imply a necessary
buffer of 0.64 seconds. That's more than 1.2 seconds round trip. I would
suggest maybe you can define a default dtxmax different from the 3GPP2
default (which I believe is set with synchronous operation is mind, based on
changing of the silence characteristics). And I think definitely it would be
helpful to point out the impact of dtxmax on the detection delay, which some
text such as "Note that the dtxmax parameter will affect the amount of delay
the RTP receivers have to have for detecting DTX in the stream" in
corresponding places in Section 6.

Hope it helps.

Adam

> From: Kapoor, Rohit [mailto:[email-masked]]
> Sent: Monday, June 19, 2006 4:32 PM
> To: Adam Li; Qiaobing Xie
> Cc: Colin Perkins; AVT WG

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Tue, 20 Jun 2006 09:52:02 -0700

Adam,

Please see some of my answers below.

> Sent: Tuesday, June 20, 2006 8:20 AM
> To: Kapoor, Rohit; 'Qiaobing Xie'
> the brief description in Section 1.3. Maybe we can move some
descriptions
> reader's perspective. This is up to you.

<Rohit> Good suggestion. At the end of this last call, we can make a
small editorial change to move some descriptions of the parameters to
1.3.

> default (which I believe is set with synchronous operation is mind,
based
> on
> changing of the silence characteristics).

<Rohit> Since 3GPP2 will be the primary user of this RFC, we'd like to
leave the default value to the 3GPP2 value. But we will add a sentence,
as you suggested below, to inform the reader of the impact of dtxmax
(more below).

> And I think definitely it would
> be
> helpful to point out the impact of dtxmax on the detection delay,
which
> some

<Rohit> We propose to add the following sentence (a small change to your
proposed sentence): "Note that if the RTP receiver elects to detect DTX
using dtxmax, the dtxmax parameter will affect the amount of delay the
RTP receiver sees before detecting DTX in the stream".

Please let us know if this would sufficiently address your concerns.

Thanks,
Rohit

> > > Subject: RE: Comments on
draft-ietf-avt-compact-bundled-evrc-06.txt
> > > It makes little sense to have DTX in RTP but do not say anything
about
> > how
> > > it is used in the RTP sender and how it detected in the RTP
receiver,
> > just
> > > because the EVRC decoder after the RTP receiver can always decode
it
> > even
> > > without knowing DTX.
> > >
> > > In my opinion: if we define a feature in the protocol, specify how
it
> > is
> > > > Subject: Re: Comments on
draft-ietf-avt-compact-bundled-evrc-06.txt
> > > > >>is in a DTX period. Some implementation could decide to
generate
> > > comfort
> > > > >>noise if it sees some missing packets (either due to DTX or
lost
> > data).
> > > > operation of any RTP endpoint and there is absolutely no
intention
> > to
> > > > compatibility reasons it was deliberately made so that the
receiver
> > does
> > > > not need to know whether DTX is in force. In other words, it is
NOT

---

From: "Adam Li" <[email-masked]>
Date: Tue, 20 Jun 2006 10:33:28 -0700

Rohit,

That looks alright with me.

Adam

> Sent: Tuesday, June 20, 2006 9:52 AM

---

From: Colin Perkins <[email-masked]>
Date: Fri, 23 Jun 2006 21:02:47 +0100

This working group last call has ended. A revised draft is needed to  
address Adam Li's comments, then the working group last call will be  
reissued.

Colin

On 14 Jun 2006, at 21:42, Colin Perkins wrote:
> This is to announce a new working group last call on the  
> Enhancements to RTP Payload Formats for EVRC Family Codecs <draft- 
> ietf-avt-compact-bundled-evrc-06.txt>. Please send any final  
> comments on this draft to the mailing list before 23rd June 2006.  
> If no issues are raised by that time, we will request the IESG  
> publish this as a proposed standard RFC, to update RFC 3558.
>
> Colin
>
>
>