Subject: Re: [AVTCORE] Additional comments: draft-ietf-avtcore-idms-02

From: Fernando Boronat Seguí <[email-masked]>
Date: Thu, 15 Dec 2011 18:21:17 +0100

Hi,

I write this mail on behalf of Mario Montagud and Fernando Boronat

Our comments are below with [F&M]

Regards

Here are some additional comments on the draft. Most of these are
suggestions for minor improvements. Items 6 and 7 represent significant
technical issues and may require discussion.

1/ Chance all occurrences of "play-out" to "playout".

[F&M] OK, we usually use playout in our papers. On the other hand, we 
are currently studying some media players and in their documentation we 
have found ‘playback’ instead of ‘playout’.

2/ First line of 1.2 "Currently, most _interactive_ multimedia applications
make use of RTP and RTCP." Streaming applications commonly use HTTP.

[F&M] Maybe we can also put: “Currently, many interactive multimedia 
applications make use of RTP and RTCP”

3/ Last paragraph in 1.2 As information on RTP packet arrival times and
play-out times can be considered reception quality feedback information,
RTCP _is the appropriate conduit for delivery and playout delay information
for IDMS._" Convert from proposal to standards language.

[F&M] We agree.

4/ Second paragraph, section 1.3. Delete "one for the RTCP XR block type
and one for the new RTCP packet type." SDP parameters make the system work
and are not closely associated with these protocols.

[F&M] We agree because both types are not defined yet. We can delete 
that sentence or use an alternative like this: “This document describes 
two SDP parameters for doing this, one for the RTCP XR block type and 
one for the new RTCP packet type (both types will described in Sections 
6 and 7, respectively, and the associated SDP parameters are presented 
in Sections 9 and 10, respectively)”.

5/ Additional paragraph to append to 1.4, "The ETSI TISPAN protocol differs
in that RTCP XR block are used to convey playout and delivery delays as
well as to send synchronization parameters to receivers. In this document,
a new RTCP packet type is defined to convey high-resolution synchronization
parameters to receivers.

[F&M] OK, although Section 12 presents the compatibility between ETSI 
TISPAN and this I-D.

6/ Packet Received NTP timestamp and Packet Received RTP timestamp
definitions in section 6 and Packet Received NTP timestamp definition in
section 7. What IDMS really wants to measure is when all data for the
indicated RTP timestamp is available to the rendering application. We'd
therefore like to know the arrival time of the last octet of the last
packet associated with this RTP timestamp.

[F&M] You are right.

There is difficulty reliably identifying the last packet. We could 
defining this as the last packet before media clock advances but this 
does not appreciate out-of-order generation and reordering by the network.

[F&M] We are not sure what you mean here. We should discuss this issue 
but we think we should define it as the last received RTP packet among 
all the sent RTP packets with the same RTP timestamp (regardless of its 
sequence number).

7/ In Packet Presented NTP timestamp definition in section 6, Clarify that
presentation time does not include any intentionally introduced delay.
Discuss presentation estimates. Suggested replacement for the
first sentence of the definition: "This timestamp reflects the wall clock
time at the earliest moment the data contained in the first octet of the
associated RTP packet could be presented to the user if no IDMS-directed
delay were introduced.

[F&M] We thought that it was implied but we agree.

In some cases, due to additional delays in external
equipment or sound propagation time through air, actual presentation time
to the user may not be accurately knowable. For a comfortable media
experience, it is preferable to delay audio with respect to video than
vise-versa. Pesimistic (longer) assumptions about playout delay should be
used for video and optimistic (shorter) ones for audio."

[F&M] We are not sure about including these sentences in the I-D but if 
you have already discussed it before, it is up to you.

8/ Clarify use of 0 value in Packet Presented NTP timestamp definition in
section 6. If _no presentation timestamp is available_ then is shall be set
to 0.

[F&M] OK

9/ Packet Presented NTP timestamp in section 7. "This timestamp reflects
the wall clock time at the reference client at the moment the data
contained in the first octet of the associated RTP packet _should be
presented_ to the user. Change to directive language.

[F&M] OK

10/ SyncGroupID definition in sections 9 and 10. Remove "in network byte
order" qualifier. This qualifier may cause confusion, is not necessary and
is not applied to attribute definitions in RFC 4566.

[F&M] OK

11/ Editorial correction and clarification in section 13: "Normally,
the processing and play-out of the same media stream by _similar_ receivers
will take roughly the same amount of time. By synchronizing on packet
arrival times, you may _lose_ some accuracy, but it will be adequate for
many applications,
[F&M] OK

Fernando and Mario

Regards
========================================================================
Dr. Fernando Boronat Seguí
Profesor Titular / Lecturer	
Dept. Comunicaciones           Tlf.-+34+962 849 300 Ext.-49341
Tlf. directo -+34+962 849 341  Fax.-+34+962 849 309 (Compartido)
UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA
Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN
========================================================================