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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 01 Jun 2006 09:48:04 +0200

Kapoor, Rohit wrote:
> Magnus,
> 
> The following line (from the 3GPP2 DTX Spec, which is reference [9] in the draft) can help to clarify this:
> 
> "The values for DTX max, DTX min, and eighth-rate hangover shall be
> represented as unsigned 8-bit integers, i.e. limited to the range
> 0-255."
> 
> Please let me know if adding this helps to address your concern.
> 

Yes, it will. Please include that range in the value description. Are 
there requirements for all entities to support the full range?

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]

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

---

From: "Kapoor, Rohit" <[email-masked]>
Date: Wed, 31 May 2006 11:53:20 -0700

Magnus,

Thanks,
Rohit

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Mon 5/29/2006 12:47 AM
To: Qiaobing Xie
Cc: IETF AVT WG; Kapoor, Rohit
Subject: Re: [AVT] Working group last call:	draft-ietf-avt-compact-bundled-evrc-04.txt
 
Qiaobing Xie wrote:
> Hi, Magnus
> 
> ...
>>>> 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.
>>>
>>>
>>> Could you elaborate a little more about this point?
>>>
>>
>> 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.
> 
> The receiver actually specifies the range with [dtxmin, dtxmax] for each 
> given session, I hope the revised text will make this more clear.

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.

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

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 05 Jun 2006 15:16:28 -0500

Hi, Magnus,

...
> there requirements for all entities to support the full range?

3GPP2 DTX spec makes this an encoder requirement. How about we add the 
following line to the draft:

"When DTX is supported, the RTP sender implementation SHOULD support 
hangover, dtxmin, and dtxmax values between 0 to 255."

Would this sufficiently address your concern?

regards,
-Qiaobing