[AVT] Re: Comments on draft-basso-avt-videoconreq-01.txt

["Andrea Basso" <Andrea_Basso at nmss.com>]

Magnus, All,

thanks for the comments

>11. Section 5.2: command 4: Why is this needed. I can't fully understand
>the need for it. What purpose does it really have?

The knowledge of the bitrate at which the remote encoder will operate will
allow for example a Multi Point Control Unit or a transcoder element to
configure efficiently the available media processing resources.


>12. Section 7.4: Why is this a MUST requirement, I am lacking motivation
>for it.

The same codec control protocol should be reusable independently from the
signaling protocol used. Thus the codec control protocol should not rely on
any specific signaling protocol. I agree that the sentence is not clear
enough and will be clarified the next release.


>13. Section 7.8: Why is it a strict requirement for the codec control
>protocol to interoperate?

One of the reasons is   to keep the gateway architectures simple (i.e.
3G-324M/SIP)by making sure that both sides have a set of compatible
commands that can be used for codec control.

>And what is required to be able to call it that things interoperate.

Good question. This needs to be defined. Al least provision of reasonable
mapping between key commands (i.e. fastvideoupdate) defined H.245/ H.241
and what will be defined in IETF.


>14. Section 7.9: I don't think this requirement is possible to
>guarantee. I think one SHOULD design the protocol to try to meet it.
>However the fact is that there are cases in deployment where the losses,
>etc., will prevent it to be fulfilled.

agreed.




Andrea Basso
NMS Communications
(732) 936-2118



                                                                                                                                       
                      Magnus Westerlund                                                                                                
                      <magnus.westerlund at er        To:       Andrea Basso <Andrea_Basso at nmss.com>, oritl at microsoft.com,                
                      icsson.com>                   nismail at cisco.com, IETF AVT WG <avt at ietf.org>                                      
                                                   cc:                                                                                 
                      07/21/2004 10:10 AM          Subject:  Comments on draft-basso-avt-videoconreq-01.txt                            
                                                                                                                                       
                                                                                                                                       




Hi,

I have reviewed the draft and have the following comments:

1. The IPR statement is part of the Status of this memo section.

2. The paragraph referring to Section 10 of RFC 2026 shall be removed.

3. What's new from version 00 should be moved to after the TOC.

4. What's new section and probably other places contain forbidden
characters. Written in MS word without turning of auto replace?

5. Section 2: First paragraph: The references seems to be broken, The
first two should be 9 and 7 as I can understand it.

6. The drafts page wide is wrong. The header and also part of the text
has more than 72 columns.

7. The page header is strange. Why is it saying 4 on every page?

8. Page footer: Shouldn't it be "Basso" instead of "basso"?

9. Section 3: Last sentence: Missing space prior to the sentence.

10. Section 4: Use case 4, extra spaces in several places.

11. Section 5.2: command 4: Why is this needed. I can't fully understand
the need for it. What purpose does it really have?

12. Section 7.4: Why is this a MUST requirement, I am lacking motivation
for it.

13. Section 7.8: Why is it a strict requirement for the codec control
protocol to interoperate? And what is required to be able to call it
that things interoperate.

14. Section 7.9: I don't think this requirement is possible to
guarantee. I think one SHOULD design the protocol to try to meet it.
However the fact is that there are cases in deployment where the losses,
etc., will prevent it to be fulfilled.

15. Reference 7: It should be updated, their are several newer versions
available then the indicated one.

16. Reference 9: RFC 3550 has been available rather long time now.
Please also remember to include the STD 64 indicator in this reference.


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: magnus.westerlund at ericsson.com






_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt