Subject: [AVT] Comments on draaft-xie-avt-compact-bundle-evrc-01

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Nov 2005 16:08:21 +0100

Hi,

1. Section 2: The first sentence could be a bit clearer that it defines 
the RTP payload format for EVRC-B, a complementing compact bundle format 
for EVRC and EVRC-B, and updates the RFC 3558 formats with DTX support

2. Section 2.2, second last paragraph:
"However, in many wireless systems such as 3GPP and 3GPP2, header
    compression/removal is only applied between the mobile station and
    the radio access network."

I didn't thought that 3GPP2 was doing header removal? My impression that 
it supported the 0-byte Link-layer assisted header compression. Because 
RTP header removal is not something that we should indicate as being 
supported. It has some serious issues for RTP receivers.

3. Section 4. To my understanding it would fully possible to define 2 
payload formats with different rate values and then do payload type 
based switching between them. Is this something that should be documented?

4. Media type registrations, section 5. First I think there should be 
the reference that these registrations/updates uses the rules and 
template in draft-freed-media-type-reg-05 and draft-ietf-avt-rfc3555bis-01.

5. Media type registrations: Then they must of course follow those, so 
please update all of the templates. The primary changes are in, encoding 
consideration, restriction on usage and author/change controller. The 
change controller should be: "IETF Audio/Video Transport working group 
delegated from the IESG."

6. Media type registrations. Please provide individual templates for 
EVRCB1, and the updated types also.

7. Section 5.3: Silence suppression parameter. As a receiver needs to 
support this I think one can change the usage of this parameter to 
instead of indicating the senders capability to indicate the receivers. 
That way one better fits into offer/answer model. And you can actually 
get three states out of it. The lack of a silence suppression parameter 
indicates no desire or support for using DTX, silence suppression=0 that 
it is supported but not desired to be received, and silence 
suppression=1 that DTX is supported and desired to be received.

8. Section 5.3: DTX max. I think it is fine to define such a parameter. 
The question is 50 a suitable default value? That would mean one silence 
description update per second.

9. Section 5.3: DTXmin: I think the definition could be more clear that 
it only applies if there only is 1/8 rate frames for that many frames. 
Secondly I do question the need for DTXmax and DTXmin. Why not a single 
parameter defining the interval between sent 1/8 rate frames when in DTX.

10. Section 5.3: The marker bit definition. This is quite a strange 
definition. Why not use the normal one, that it will be set to 1 for the 
first payload after DTX. That way the receiver gets the indication that 
it might shorten or lengthen the time scale before playing out this new 
frame.

11. Section 6. I think a reference to RFC 3558 security consideration is 
in order.

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: Qiaobing Xie <[email-masked]>
Date: Wed, 09 Nov 2005 19:38:31 -0600

Hi, Magnus,

Thank you for the detailed review and comments. Please see my response 
in-line.

> for EVRC and EVRC-B, and updates the RFC 3558 formats with DTX support

Ok. Will improve that.

> supported. It has some serious issues for RTP receivers.

Good point. I will take out the word "removal" to avoid misunderstanding.

> based switching between them. Is this something that should be documented?

Do you mean that we could define an EVRC1-Full subtype and an EVRC1-Half 
subtype and switching between them on a per RTP packet basis? That would 
work.

> template in draft-freed-media-type-reg-05 and draft-ietf-avt-rfc3555bis-01.

Good point. I will look into that.

> EVRCB1, and the updated types also.

OK. Will do.

> it might shorten or lengthen the time scale before playing out this new 

I will bring the above section 5.3 related comments to the attention of 
the 3GPP2 EVRC DTX algorithm design folks and get their opinion. They 
are in the process of finalizing the DTX algorithm and this could be 
very important input to them.

> 11. Section 6. I think a reference to RFC 3558 security consideration is 

Ok, will add.

regards,
-Qiaobing