Subject: [AVT] Working group last call: draft-ietf-avt-compact-bundled-evrc-04.txt

From: Colin Perkins <[email-masked]>
Date: Mon, 1 May 2006 16:54:31 +0100

This is to announce a working group last call on the Enhancements to  
RTP Payload Formats for EVRC Family Codecs <draft-ietf-avt-compact- 
bundled-evrc-04.txt>. Please send any final comments on this draft to  
the mailing list by 15th May 2006. If no substantive comments are  
received by that time, we will request the IESG consider this for  
publication as a proposed standard RFC, to update RFC 3558.

Colin

On 25 Apr 2006, at 20:50, [email-masked] wrote:
> 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-04.txt
> 	Pages		: 22
> 	Date		: 2006-4-25
> 	
> This document defines several enhancements and extensions to the EVRC
> RTP payload formats defined in RFC 3558.  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-04.txt

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 May 2006 15:47:01 +0200

Hi,

I have a few WG last call comments.

1. The front page should include:
Updates: RFC 3558 (if approved)

2. I think the abstract should be reformulates slightly to clarify that 
the extensions do update RFC 3558.
OLD:

This document defines several enhancements and extensions to the EVRC
    RTP payload formats defined in RFC 3558.

NEW:
This document updates the EVRC RTP payload formats defined in RFC 3558 
with several enhancements and extensions.

3. The offer answer section is not clear on how to treat the silencssupp 
parameter. The issue I see is that although it specifies the support or 
not for the offer or answer, the meaning of support is not clear. Is it 
the capacity to send DTX, to receive DTX or both? Please clarify which 
of them it is. As the parameters is specified as declarative the 
receiving seem to be the required property.

4. The values for dtxmax, dtxmin. I have not looked at the referenced 
document, thus my question: Is the values possible specified there? 
Because with a declarative value the requirement falls on the sender to 
support what ever value the receiver specifies. Thus I wonder if it 
reasonable and specified which values a offerer or answerer provides.

5. Section 6.8: Bullet 4:
Furthermore, if both offer and answer contain the dtxmax
        parameter, the value of dtxmax in the answer MUST be less than or
        equal to the value of dtxmax in the offer.

Why is this needed. What prevent the answerer from specifying values 
that are larger than the offerer?

Cheers

Magnus Westerlund

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 May 2006 16:14:31 +0100

Thanks - this ends the working group last call period. A revised  
draft is needed to address these comments, then we will reissue the  
last call.

Colin

On 15 May 2006, at 14:47, Magnus Westerlund wrote:

> 2. I think the abstract should be reformulates slightly to clarify  
> that the extensions do update RFC 3558.
> OLD:
>
> This document updates the EVRC RTP payload formats defined in RFC  
> 3558 with several enhancements and extensions.
>
> 3. The offer answer section is not clear on how to treat the  
> silencssupp parameter. The issue I see is that although it  
> specifies the support or not for the offer or answer, the meaning  
> of support is not clear. Is it the capacity to send DTX, to receive  
> DTX or both? Please clarify which of them it is. As the parameters  
> is specified as declarative the receiving seem to be the required  
> property.
>
> 4. The values for dtxmax, dtxmin. I have not looked at the  
> referenced document, thus my question: Is the values possible  
> specified there? Because with a declarative value the requirement  
> falls on the sender to support what ever value the receiver  
> specifies. Thus I wonder if it reasonable and specified which  
> values a offerer or answerer provides.
>
> Why is this needed. What prevent the answerer from specifying  
> values that are larger than the offerer?
>
> Cheers
>
> Magnus Westerlund
>

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 23 May 2006 12:14:52 -0500

Hi, Magnus,

Thanks for the review comments. We will revise the draft. Please see my 
comments in-line.

> Updates: RFC 3558 (if approved)

ok.

> with several enhancements and extensions.

ok.

> receiving seem to be the required property.

It's both. We will clarify the text.

> document, thus my question: Is the values possible specified there? 

We will cite the values in the text.

> reasonable and specified which values a offerer or answerer provides.

Could you elaborate a little more about this point?

> that are larger than the offerer?

You are right. This restriction is not needed. We will clarify the usage 
of dtxmax and dtxmin.

regards,
-Qiaobing

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 May 2006 10:08:28 +0200

Qiaobing Xie wrote:
>> Because with a declarative value the requirement falls on the sender 
>> to support what ever value the receiver specifies. Thus I wonder if it 

My concern was that unless one actually state a specific range it is 
very difficult to ensure that one can actually support any provided 
value. As these are declarative parameters that needs to be supported by 
the sending side there would be issues if there was no limitation. A 
implementor may think supporting this feature in a particular range is 
appropriate and someone else support another range. It was an 
interoperability issue. But with a range it shouldn't be a problem.

Cheers

Magnus Westerlund

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 25 May 2006 11:59:00 -0500

Hi, Magnus

...
>>> to support what ever value the receiver specifies. Thus I wonder if 
>>> it reasonable and specified which values a offerer or answerer provides.
>>
>>

The receiver actually specifies the range with [dtxmin, dtxmax] for each 
given session, I hope the revised text will make this more clear.

Since both parameters are defined as intervals, it automatically means 
that the their value will be >= 1.

When the receiver is generous (say, declaring a wide range of [1, 
5000]), it basically tells the sender to feel free to use any value it 
likes and inter-op should be of no problem. The tightest range a 
receiver can declare at the low end is [1, 1], which is basically 
equivalent to "no DTX" and I think any sender should be able to comply 
without much difficult. In case a high value tight range, say [5000, 
5000], is given, it basically tells the sender "don't worry about 
sending any update during a silence", which should also be easy to comply.

regards,
-Qiaobing

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 May 2006 09:47:21 +0200

Qiaobing Xie wrote:
>> value. As these are declarative parameters that needs to be supported 
>> by the sending side there would be issues if there was no limitation. 
>> A implementor may think supporting this feature in a particular range 
>> is appropriate and someone else support another range. It was an 

But that is not what I am asking for. I am asking for the range of 
allowed values. In which range may dtxmin be selected, and in which 
range may dtxmax be.

> sending any update during a silence", which should also be easy to comply.

The above reasoning is exactly why I raised the issue. If you allow the 
receiver to select the values it can accept, then it is still possible 
to select values that the sender can't support unless there is a range 
of values the specification says it shall be supported. Lets assume that 
a receiver selects 300,5000 in his range while the sender only 
implements values from 1-250. Then they are not interoperable. So please 
specify which values is required to be supported so that a receiver can 
specify a range of dtx values that the sender will be guaranteed to support.

Cheers

Magnus Westerlund