Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

From: "Roni Even" <[email-masked]>
Date: Sun, 17 Jun 2012 19:04:38 +0300

Hi,

I would like to start a WGLC on
http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for
inter-destination media synchronization.

The WGLC will end on July 10th, 2012

Please review the draft and send comments to the list.

For the draft authors;  Are you aware of any IPR that applies to
draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?
The above question is needed for the document write-up when sent to
publication.

Thanks

Roni Even

AVTcore  co-chair

---

From: "Stokking, H.M. (Hans)" <[email-masked]>
Date: Mon, 18 Jun 2012 07:14:45 +0000

Roni,

To our knowledge, there is no IPR that applies to draft-ietf-avtcore-idms-05.

Best, Hans & Ray

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: zondag 17 juni 2012 18:05
To: [email-masked]
Cc: [email-masked]
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization.

For the draft authors;  Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so,

has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

The above question is needed for the document write-up when sent to publication.

Thanks

Roni Even
AVTcore  co-chair

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jun 2012 16:01:16 +0200

Hi,

As the SDP rtcp-xr attribute is defined RFC 3611, I guess the offer/answer aspects of that RFC apply also for the extension. If so, it would be good to mention that.

However, as the SDP rtcp-idms attribute is defined in this document, you also need to define the offer/answer aspects. There is some text in section 11, but the section name talks about "TISPAN compatibility". You should have a section named "Offer/Answer", or something.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 17. kesäkuuta 2012 19:05
To: [email-masked]
Cc: [email-masked]
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

Thanks

Roni Even
AVTcore  co-chair

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Thu, 21 Jun 2012 09:48:54 +0000

Hi Christer,

Thanks for your comments. We will include your suggestions in the next version of the draft.

Regards,

Ray

From: Christer Holmberg [mailto:[email-masked]]
Sent: maandag 18 juni 2012 16:01
To: Roni Even; [email-masked]
Cc: [email-masked]
Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

Regards,

Christer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 17. kesäkuuta 2012 19:05
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

Thanks

Roni Even
AVTcore  co-chair

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jun 2012 15:52:31 +0200

Hi,

This is my WG last call review as an individual. I think there is quite
a lot to address before this document is ready for publication request.

1. This document has 6 authors listed. This is one more than the policy
allows:
http://www.rfc-editor.org/policy.html#policy.authlist

2. Abstract:
"This document gives information on an RTCP Packet Type and RTCP XR
   Block Type including associated SDP parameters for Inter-Destination
   Media Synchronization (IDMS)."

Doesn't it define these packet/block types?

3. Section 3:

The ladder diagrams first line is wrongly indented.

3. Section 3. Ladder diagram, maybe this diagram should have some
handle, like figure 1 with a label.

4. Section 3.
I am missing discussion on the overview level of clocks. Yes it is
present later, but I think the topic should be introduced already here
is section 3.

5. Section 6. I think this section should make it clear how an SC can
include multiple report blocks for different received sources. In
general I think this may be a topic that needs to be lifted into the
overview. The issue I see is the following ones.

a) Within a multi-party communication session different media senders
include different reference clocks. Thus creating multiple
synchronization groups within the context of one multi-media
communication session.

b) even if they can agree on using the same clock reference they still
need to enable the fact that an end-point is acting as MSAS for some
media sources and SC for others. This should be made more clear.

6. Section 6 appears to be a normative definition of RTCP XR block type
12. That block type is registered by IANA as belonging to ETSI 183 063
specification. Unless we have a formal liasion assigning the change
right to IETF I don't see how we can make an updated normative
specification of this XR block type. I see two options.

a) IETF are given the change right over the block type

b) IETF makes a normative reference to the ETSI specification of the
block type and then simply makes it clear that they only uses SPST=1.

7. Section 6. Assuming that the normative definition will remain and
possibly also as a clarification to the ETSI specification: This section
is not making it sufficient clear that what an SC is supposed to do is
to pick one RTP packet it recevied, then report the values for this
particular packet. I think one should clarify this and also making it
clearer what the selection criteria for such a packet is. Should one
focus on using maximum delayed packets, media delayed packets or simply
random selection? In addition we have the rules about picking packets
when multiple RTP sequence numbers have the same TS value. I would
recommned that one add some paragraphs before the actual figure
definition to discuss this.

8. Section 6, PT field definition. This is not making clear that one
shall report the PT of the packet one is reporting on.

9. Section 6.
   Media Stream Correlation Identifier: 32 bits.  This identifier is
   used to correlate synchronized media streams.  The value 0 (all bits
   are set "0") indicates that this field is empty.  The value 2^32-1
   (all bits are set "1") is reserved for future use.  If the RTCP
   Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then the Media
   Stream Correlation Identifier maps on the Synchronization Group
   Identifier (SyncGroupId) to which the report applies.

It is not clear what "maps" means here. Considering that the field
appears to carry the full syncgroupID I think another formulation shall
be used.

10. Section 6.
"To solve
   this, an SC SHOULD report on RTP packets in which a certain RTP
   timestamp shows up for the first time."

Does this means with the lowest sequence number or the packet first to
arrive with that TS?

11. Section 7 Title
"RTCP Packet Type for IDMS (IDMS report)"

Why is the packet used to distribute the intended playout timing called
a "report". This is very confusing considering that the XR is a report also.

12. Section 7.

   SSRC: 32 bits.  The SSRC of the media source SHALL be set to the
   value of the SSRC identifier carried in the RTP header [RFC3550] of
   the RTP packet to which the RTCP IDMS packet relates.

First of all I assume this field definition is for "SSRC of media
source" field.

a. What isn't clear is if it is at all valid that another SSRC "SSRC of
packet sender" than the "SSRC of media source" is allowed and shall be
considered valid.

b. Secondly, when an end-point has multiple sources in the same RTP
session to send it appears they need to send multiple RTCP packets.

13. Section 7.

It is not clear if there are any restrictions on the values to be
included in the RTCP packet. Must the sender of it include information
for a already sent packet, a future packet or can it even be a virtual
packet that is never sent?

I understand that one can scale the figures in this packet to determine
what the correct value should be given a received RTP packet and its
timestamp. But, are I allowed to calculate a correct time value a year
into the future that is then expected to be scaled back. Or is the RTP
timestamp value included in the packet in itself an indication for when
this information was current?

14. Section 8.
   [I-D.draft-williams-avtcore-clksrc] defines a set of SDP parameters
   for signaling the clock synchronization source or sources available
   to and used by the individual receivers.  Using these paramenters, an
   SC can indicate which synchronization source is being used at the
   moment, the last time the SC synchronized with this source and the
   synchronization frequency.  An SC can also indicate any other
   synchronization sources available to it.  This allows multiple SCs in
   an IDMS session to use the same or a similar clock source for their
   session.

So the clksrc draft appear to indended to define the usage of a=ssrc to
make it clear which clock source a particular SSRC uses. What isn't
clear from this text is that when providing reporting that all nodes
sending a report or a configuration must use their view of that
particular clock source. I think the implications of having multiple
clock sources in an RTP session must be made clearer. As the used clock
comes into play both when configuring, reporting and adjusting time
scales for playout.

15. Section 9:

   SyncGroupId = 1*DIGIT ; Numerical value from 0 through 4294967294

As the syncgroupID is limited to 10 digits, why not make that clear in
the ABNF also using 1*10DIGIT as the definition.

Applies also to Section 10.

16. Section 11.

As someone else noted. This section really needs to be split into
Offer/Answer rules and one on TISPAN interop.

16. Section 11. Offer/Answer rules
It is not clear how one deals with the potential existence of multiple
sync groups or how the ID is negotiated. Especially when you in a
multi-party negotiate with an application server.

I also think it should make clear how it works in declarative cases,
like RTSP SDPs.

17. Section 14.

This IANA registration is insufficient. It needs to be more precise in
which regestries that are to be used.

To my understand the following actions are required:

register a media level SDP attribute: This is okay considering the
template but one could clarify that the registry intended is the one
titled "att-field  (media level only)"
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-9

One RTCP Control Packet types (PT):
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-3

And if the XR block type is to be normatively defined by this document
then two registrations are needed:

- New or update of RTCP XR Block Type
http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml
- Add the XR SDP parameter:
http://www.iana.org/assignments/rtcp-xr-sdp-parameters/rtcp-xr-sdp-parameters.xml

18. References. Should [I-D.draft-gross-leap-second] be normative?
It is not written in a RFC 2119 style an requirement to take this
document into account, so maybe informative is correct.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Glen Zorn <[email-masked]>
Date: Fri, 22 Jun 2012 04:40:12 +0700

>From that document: "There is no rigid limit on the size of this set,
but there is likely to be a discussion if the set exceeds five authors,
in which case the right answer is probably to list one editor."  It is
perfectly reasonable to disagree with the final (arbitrary) statement,
however; for example, in the case where a long-lived document has an
equally long list of actual authors.  Note also that the purpose of the
policy is to both manage the size of the front page header and to
discourage "corporate name-dropping".  In this case, 6 authors is only
marginally excessive; whether or not corporate name-dropping is involved
is a question that can only be answered by the authors.

...

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Jun 2012 10:32:30 +0200

Glen,

Yes, I know it is a recommendation. The WG chair still need to motivate
the exception. But, yes I should have been clearer that it is possible
to have 6 authors. But from my perspective as a WG chair, although not
shepherd of this doc, I do like the authors to consider if they really
should be all six, or if some are more suitable on a contributors list
inside the document. Especially if not all authors are going to be
responsive in dealing with the comments and especially AUTH48.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 25 Jun 2012 12:15:42 +0000

Hi Magnus,

Many thanks for the very thorough review. You will find my comments inline.

Ray

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: donderdag 21 juni 2012 15:53
To: [email-masked]; [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

This is my WG last call review as an individual. I think there is quite a lot to address before this document is ready for publication request.

RvB: See my other mail.

2. Abstract:

RvB: We will change the abstract to reflect the contents more accurately. The draft defines the RTCP Packet Type and mandates the use of the ETSI-defined XR Block Type, which is included in the draft for sake of completeness.

3. Section 3:

RvB: OK.

3. Section 3. Ladder diagram, maybe this diagram should have some handle, like figure 1 with a label.

RvB: OK.

4. Section 3.
I am missing discussion on the overview level of clocks. Yes it is present later, but I think the topic should be introduced already here is section 3.

RvB: Good idea. We will include a short section to discuss this.

5. Section 6. I think this section should make it clear how an SC can include multiple report blocks for different received sources. In general I think this may be a topic that needs to be lifted into the overview. The issue I see is the following ones.

a) Within a multi-party communication session different media senders include different reference clocks. Thus creating multiple synchronization groups within the context of one multi-media communication session.

b) even if they can agree on using the same clock reference they still need to enable the fact that an end-point is acting as MSAS for some media sources and SC for others. This should be made more clear.

RvB: I agree that these are both valid scenarios. However, I'm not sure whether they pose a problem. In the case where an SC has to report on multiple groups, it will just send multiple report blocks (possibly concatenated using RTCP rules). Do I miss something here?

6. Section 6 appears to be a normative definition of RTCP XR block type 12. That block type is registered by IANA as belonging to ETSI 183 063 specification. Unless we have a formal liasion assigning the change right to IETF I don't see how we can make an updated normative specification of this XR block type. I see two options.

b) IETF makes a normative reference to the ETSI specification of the block type and then simply makes it clear that they only uses SPST=1.

RvB: I fully agree with the problems of trying to change the specification. When starting this work, we have therefore decided to go for your route B).

7. Section 6. Assuming that the normative definition will remain and possibly also as a clarification to the ETSI specification: This section is not making it sufficient clear that what an SC is supposed to do is to pick one RTP packet it recevied, then report the values for this particular packet. I think one should clarify this and also making it clearer what the selection criteria for such a packet is. Should one focus on using maximum delayed packets, media delayed packets or simply random selection? In addition we have the rules about picking packets when multiple RTP sequence numbers have the same TS value. I would recommned that one add some paragraphs before the actual figure definition to discuss this.

RvB: Good point. In theory it shouldn't really matter. Up to now, we have been assuming random selection, just picking a packet when the RTCP rules allow you to send a report. I will check with my co-authors to see whether they still think this is good enough. I will come back to you on this one.

8. Section 6, PT field definition. This is not making clear that one shall report the PT of the packet one is reporting on.

RvB: Ok.

9. Section 6.

It is not clear what "maps" means here. Considering that the field appears to carry the full syncgroupID I think another formulation shall be used.

RvB: We will rephrase this paragraph to make it more clear.

10. Section 6.
"To solve

Does this means with the lowest sequence number or the packet first to arrive with that TS?

RvB: The lowest sequence. We will clarify this sentence.

11. Section 7 Title

Why is the packet used to distribute the intended playout timing called a "report". This is very confusing considering that the XR is a report also.

RvB: Sorry, you're right. We'll come up with a better name.

12. Section 7.

First of all I assume this field definition is for "SSRC of media source" field.

RvB: Correct

a. What isn't clear is if it is at all valid that another SSRC "SSRC of packet sender" than the "SSRC of media source" is allowed and shall be considered valid.

RvB: We have always assumed the SSRC of Media Source scenario. Do you think there is a good reason to support 'SSRC of packet sender' as well?

b. Secondly, when an end-point has multiple sources in the same RTP session to send it appears they need to send multiple RTCP packets.

RvB: Do you mean a scenario where one source sends multiple RTP streams (e.g. audio and video). In that case, it is only necessary to do IDMS for one stream. The rest is lip-sync. The Media-level SDP part describes which stream to perform IDMS for. I will check with my co-authors whether they think it is useful to recommend either audio or video streams here for this purpose. 

13. Section 7.

It is not clear if there are any restrictions on the values to be included in the RTCP packet. Must the sender of it include information for a already sent packet, a future packet or can it even be a virtual packet that is never sent?

I understand that one can scale the figures in this packet to determine what the correct value should be given a received RTP packet and its timestamp. But, are I allowed to calculate a correct time value a year into the future that is then expected to be scaled back. Or is the RTP timestamp value included in the packet in itself an indication for when this information was current?

RvB: Good point. Because RTP timestamps wrap around, choosing a time far into future may cause problems. So indeed, the timestamp chosen needs to be a (relatively) current one. We will change the section to reflect this. 

14. Section 8.

So the clksrc draft appear to indended to define the usage of a=ssrc to make it clear which clock source a particular SSRC uses. What isn't clear from this text is that when providing reporting that all nodes sending a report or a configuration must use their view of that particular clock source. I think the implications of having multiple clock sources in an RTP session must be made clearer. As the used clock comes into play both when configuring, reporting and adjusting time scales for playout.

RvB: I'm not completely following you here. The synchronization source mentioned here is a wall clock source (e.g. NTP), and not a media clock source. The reference to the clcksrc document is just to provide the reader with the means to perform clock synchronization (and thus improve the accuracy of IDMS). Does this help? 

15. Section 9:

As the syncgroupID is limited to 10 digits, why not make that clear in the ABNF also using 1*10DIGIT as the definition.

RvB: Ok.

16. Section 11.

As someone else noted. This section really needs to be split into Offer/Answer rules and one on TISPAN interop.

RvB: Agree. We will change this in the next iteration.

16. Section 11. Offer/Answer rules
It is not clear how one deals with the potential existence of multiple sync groups or how the ID is negotiated. Especially when you in a multi-party negotiate with an application server.

I also think it should make clear how it works in declarative cases, like RTSP SDPs.

RvB: We will take up this point in the new version (see previous comment). 

17. Section 14.

This IANA registration is insufficient. It needs to be more precise in which regestries that are to be used.

RvB: Ok. Thanks for you examples. 

register a media level SDP attribute: This is okay considering the template but one could clarify that the registry intended is the one titled "att-field  (media level only)"
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml#sdp-parameters-9

And if the XR block type is to be normatively defined by this document then two registrations are needed:

18. References. Should [I-D.draft-gross-leap-second] be normative?
It is not written in a RFC 2119 style an requirement to take this document into account, so maybe informative is correct.

RvB: I propose going for informative. The leap-second draft is just a way of increasing the accuracy of IDMS. And since it is meant as an update to RFC3550, can be considered part of RTCP and not specifically targeted at IDMS.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Wed, 27 Jun 2012 09:04:29 +0000

Hi Glen/Magnus,

As author of the draft, all I can say is that all the authors who are on the draft right now (we've removed some people between the -01 and -02 version for exactly this reason) have made significant contributions and are actively involved, whether that allows us to expand the number of authors beyond the limit of 5, I can't say. I will leave that decision up to the document shepherd and the WG chairs.

Thanks,

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: maandag 25 juni 2012 10:33
To: Glen Zorn
Cc: [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Glen,

Yes, I know it is a recommendation. The WG chair still need to motivate the exception. But, yes I should have been clearer that it is possible to have 6 authors. But from my perspective as a WG chair, although not shepherd of this doc, I do like the authors to consider if they really should be all six, or if some are more suitable on a contributors list inside the document. Especially if not all authors are going to be responsive in dealing with the comments and especially AUTH48.

Cheers

Magnus

On 2012-06-21 23:40, Glen Zorn wrote:
>> This is my WG last call review as an individual. I think there is 
>> quite a lot to address before this document is ready for publication request.
>>
> but there is likely to be a discussion if the set exceeds five 
> authors, in which case the right answer is probably to list one 
> editor."  It is perfectly reasonable to disagree with the final 
> (arbitrary) statement, however; for example, in the case where a 
> long-lived document has an equally long list of actual authors.  Note 
> also that the purpose of the policy is to both manage the size of the 
> front page header and to discourage "corporate name-dropping".  In 
> this case, 6 authors is only marginally excessive; whether or not 
> corporate name-dropping is involved is a question that can only be answered by the authors.
> 
> ...

-- 

Magnus Westerlund

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Jun 2012 11:36:52 +0200

On 2012-06-27 11:04, Brandenburg, R. (Ray) van wrote:
> Hi Glen/Magnus,
> 
> As author of the draft, all I can say is that all the authors who are
> on the draft right now (we've removed some people between the -01 and
> -02 version for exactly this reason) have made significant
> contributions and are actively involved, whether that allows us to
> expand the number of authors beyond the limit of 5, I can't say. I
> will leave that decision up to the document shepherd and the WG
> chairs.
> 

If that is the case, I don't see any significant problem with continuing
with 6 authors on the list. But it is Roni's decision as Shepherd.

Cheers

Magnus

> Thanks,
> 
> Ray
> 
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund Sent:
> maandag 25 juni 2012 10:33 To: Glen Zorn Cc: [email-masked] Subject:
> Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05
> 
> Glen,
> 
> Yes, I know it is a recommendation. The WG chair still need to
> motivate the exception. But, yes I should have been clearer that it
> is possible to have 6 authors. But from my perspective as a WG chair,
> although not shepherd of this doc, I do like the authors to consider
> if they really should be all six, or if some are more suitable on a
> contributors list inside the document. Especially if not all authors
> are going to be responsive in dealing with the comments and
> especially AUTH48.
> 
> Cheers
> 
> Magnus
> 
>>> 1. This document has 6 authors listed. This is one more than the
>>>  policy allows: 
>> From that document: "There is no rigid limit on the size of this
>> set, but there is likely to be a discussion if the set exceeds five
>> long-lived document has an equally long list of actual authors.
>> Note also that the purpose of the policy is to both manage the size
>> of the front page header and to discourage "corporate
>> name-dropping".  In this case, 6 authors is only marginally
>> excessive; whether or not corporate name-dropping is involved is a
>> question that can only be answered by the authors.
>> 
>> ...
> 
> 
> 
> 

-- 

Magnus Westerlund

---

From: Qin Wu <[email-masked]>
Date: Thu, 28 Jun 2012 11:03:30 +0800

Hi,
I have reviewed XR Block aspect and it seems IANA has already allocated Block Type 12 to this IDMS XR Block. 
http://www.iana.org/assignments/rtcp-xr-block-types/rtcp-xr-block-types.xml
I have not been aware of this before. I am wondering what's the procedure for other SDOs to ask IETF for IANA registry?
Send Liaison statement or something else?

Besides this, below are a few comments related to XR Block:
1. Section 6, 
It is better to number the figure in the section 6 with a title.
2. Section 6, figure
It is unusual to reseve some bits in the middle of "type specific field" after Block Type (BT) field.
Why not move P bit before reseved bits in this field.
3. Section 6, SPST field
For SPST =2, it is better to point out the packet sender is Media Synchronization Application Server (MSAS)
to get in line with SPST =1;
4. Section 6, Payload Type (PT)
Payload Type (PT) and Packet Type (PT) are defined in the same XR Block and has the same short name,
it is quite confusing. Suggest to distinct them in the XR BLock format.

5. Section 6, Payload Type (PT)
Why Synchronization Client (SC) should send Payload Type in the XR Block message to Media Synchronization Application Server (MSAS)
while MSAS does not need to send Payload Type in the IDMS RTCP message to  SC?
It seems you indicate MSAS should handle various payload Type sent from different SCs? How MSAS procss Payload Type? The Payload Type difference 
each SC is using affect the timestamps carried in the IDMS RTCP packet?

I am wondering if it is really necessary to allow XR Block carry Payload Type?

6. Section 6, SSRC of media source field
To get in line with the existing RTCP XR Block, it is better put SSRC of media source field right after report Block header before Payload Type filed. 

7. Section 6, Packet Presented NTP timestamp field:
Why the size of Packet Presented NTP timestamp field in the IDMS XR block is 32 bit while the size of Packet Presented NTP timestamp field in the IDMS RTCP packet
 is 64 bit? It is better to clarify this in the document?

8 Section 6, Media Stream Correlation Identifier field:
It looks the value of Media Stream Correlation Identifier  is same as SyncGroupId,
SynGroupID is signaled using SDP and SC or MSAS just use put SyncGroupID 
into Media Stream Correlation Identifier field
I am wondering why not use the same name for them? That is to say, change Media Stream Correlation field to SyncGroupId.

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 21, 2012 9:52 PM
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

2. Abstract:

3. Section 3:

4. Section 3.

9. Section 6.

10. Section 6.
"To solve

11. Section 7 Title

12. Section 7.

13. Section 7.

14. Section 8.

15. Section 9:

16. Section 11.

17. Section 14.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Glen Zorn <[email-masked]>
Date: Thu, 28 Jun 2012 10:11:59 +0700

> Send Liaison statement or something else?

AFAIK, there is no special procedure; just follow the allocation policy.

...

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jun 2012 08:50:21 +0200

On 2012-06-25 14:15, Brandenburg, R. (Ray) van wrote:
> -----Original Message----- From: Magnus Westerlund
> [mailto:[email-masked]] Sent: donderdag 21 juni 2012
> 15:53 To: [email-masked]; [email-masked] 
> policy allows: http://www.rfc-editor.org/policy.html#policy.authlist
> 
> RvB: See my other mail.
> 
> 2. Abstract: "This document gives information on an RTCP Packet Type
> and RTCP XR Block Type including associated SDP parameters for
> Inter-Destination Media Synchronization (IDMS)."
> 
> RvB: We will change the abstract to reflect the contents more
> accurately. The draft defines the RTCP Packet Type and mandates the
> use of the ETSI-defined XR Block Type, which is included in the draft
> for sake of completeness.
> 
> 3. Section 3:
> 
> 4. Section 3. I am missing discussion on the overview level of
> clocks. Yes it is present later, but I think the topic should be
> introduced already here is section 3.
> 
> b) even if they can agree on using the same clock reference they
> still need to enable the fact that an end-point is acting as MSAS for
> some media sources and SC for others. This should be made more
> clear.
> 
> RvB: I agree that these are both valid scenarios. However, I'm not
> sure whether they pose a problem. In the case where an SC has to
> report on multiple groups, it will just send multiple report blocks
> (possibly concatenated using RTCP rules). Do I miss something here?

No, I don't think they represent any significant issues. It just that I
think it is worth pointing out that this is expected and that
implementations needs to handle such situations. Many implementors reads
the spec and looks at the examples and if it is not spelled out that
these are valid cases they might not implement to support them.

> 
> 6. Section 6 appears to be a normative definition of RTCP XR block
> type 12. That block type is registered by IANA as belonging to ETSI
> 183 063 specification. Unless we have a formal liasion assigning the
> change right to IETF I don't see how we can make an updated normative
> RvB: I fully agree with the problems of trying to change the
> specification. When starting this work, we have therefore decided to
> go for your route B).

Ok, I have no issues with that, however it must be much more clear and
explicit that the ETSI spec is the normative one.

> possibly also as a clarification to the ETSI specification: This
> section is not making it sufficient clear that what an SC is supposed
> to do is to pick one RTP packet it recevied, then report the values
> for this particular packet. I think one should clarify this and also
> making it clearer what the selection criteria for such a packet is.
> Should one focus on using maximum delayed packets, media delayed
> packets or simply random selection? In addition we have the rules
> about picking packets when multiple RTP sequence numbers have the
> same TS value. I would recommned that one add some paragraphs before
> the actual figure definition to discuss this.
> 
> RvB: Good point. In theory it shouldn't really matter. Up to now, we
> have been assuming random selection, just picking a packet when the
> RTCP rules allow you to send a report. I will check with my
> co-authors to see whether they still think this is good enough. I
> will come back to you on this one.

Good

> 9. Section 6. Media Stream Correlation Identifier: 32 bits.  This
> identifier is used to correlate synchronized media streams.  The
> value 0 (all bits are set "0") indicates that this field is empty.
> The value 2^32-1 (all bits are set "1") is reserved for future use.
> If the RTCP Packet Sender is an SC (SPST=1) or an MSAS (SPST=2), then
> the Media Stream Correlation Identifier maps on the Synchronization
> Group Identifier (SyncGroupId) to which the report applies.
> 
> appears to carry the full syncgroupID I think another formulation
> shall be used.
> 
> 10. Section 6. "To solve this, an SC SHOULD report on RTP packets in
> which a certain RTP timestamp shows up for the first time."
> 
> 11. Section 7 Title "RTCP Packet Type for IDMS (IDMS report)"
> 
> Why is the packet used to distribute the intended playout timing
> called a "report". This is very confusing considering that the XR is
> a report also.
> 
> a. What isn't clear is if it is at all valid that another SSRC "SSRC
> of packet sender" than the "SSRC of media source" is allowed and
> shall be considered valid.
> 
> RvB: We have always assumed the SSRC of Media Source scenario. Do you
> think there is a good reason to support 'SSRC of packet sender' as
> well?

No, I don't have a use case in mind. This could be useful if one has a
separate node taking care of determining a number of source should be
played out. At the same time I think it creates thorny security question
etc. Today, you can build the authorization to set the playout time on
the media source. With this you get in addition to authenticating source
you also need to know that the third party setting the playout is
authorized to do it on behalf of the media source. I would suggest to
skip third party functionality at this point.

> RvB: Do you mean a scenario where one source sends multiple RTP
> streams (e.g. audio and video). In that case, it is only necessary to
> do IDMS for one stream. The rest is lip-sync. The Media-level SDP
> part describes which stream to perform IDMS for. I will check with my
> co-authors whether they think it is useful to recommend either audio
> or video streams here for this purpose.

Lets assume audio only RTP session. I can have two audio source. This
means that the end-point needs to set playout for both its sources or
rely on lip sync assuming they are using the same CNAME.

I think this opens up to several aspects:

a) The need to describe that you only need to actually provide playout
time for one SSRC within a synchronization context, i.e. the SSRC having
the same CNAME. I think this needs to be explicit that this can be done
in this way. I think you also needs to say what to do if I get playout
times for two SSRCs with the same CNAME and they don't match. This spans
over both multiple RTP session and multiple SSRCs within a session.

b) The next is that you will receive playout reports from all SSRCs an
end-point have in the session. Also here consistency is an important
aspect, but I would expect that especially the receive time report will
jitter at the same order of the transport jitter.

> included in the RTCP packet. Must the sender of it include
> information for a already sent packet, a future packet or can it even
> be a virtual packet that is never sent?
> 
> I understand that one can scale the figures in this packet to
> determine what the correct value should be given a received RTP
> packet and its timestamp. But, are I allowed to calculate a correct
> time value a year into the future that is then expected to be scaled
> back. Or is the RTP timestamp value included in the packet in itself
> an indication for when this information was current?
> 
> RvB: Good point. Because RTP timestamps wrap around, choosing a time
> far into future may cause problems. So indeed, the timestamp chosen
> needs to be a (relatively) current one. We will change the section to
> reflect this.
> 
> 14. Section 8. [I-D.draft-williams-avtcore-clksrc] defines a set of
> SDP parameters for signaling the clock synchronization source or
> sources available to and used by the individual receivers.  Using
> these paramenters, an SC can indicate which synchronization source is
> being used at the moment, the last time the SC synchronized with this
> source and the synchronization frequency.  An SC can also indicate
> any other synchronization sources available to it.  This allows
> multiple SCs in an IDMS session to use the same or a similar clock
> source for their session.
> 
> So the clksrc draft appear to indended to define the usage of a=ssrc
> to make it clear which clock source a particular SSRC uses. What
> isn't clear from this text is that when providing reporting that all
> nodes sending a report or a configuration must use their view of that
> clock sources in an RTP session must be made clearer. As the used
> clock comes into play both when configuring, reporting and adjusting
> time scales for playout.
> 
> RvB: I'm not completely following you here. The synchronization
> source mentioned here is a wall clock source (e.g. NTP), and not a
> media clock source. The reference to the clcksrc document is just to
> provide the reader with the means to perform clock synchronization
> (and thus improve the accuracy of IDMS). Does this help?

Correct, I hadn't thought through this sufficiently. All SSRCs in one or
more RTP session using the same CNAME MUST use the same wall clock, i.e.
same clksrc. If you have different ones you need to use different
CNAMES. So it is actually CNAMES and clock sources that should be bound
in the signalling.

>From that perspective an end-point could use multiple CNAMES and thus
have different clock sources present in the same session. A prime
example would be a central node that forwards streams, but do not
resynchronize them into a single CNAME. Such an end-point would in an
O/A SDP signalling have need to express the different clock source for
the other participants in the session.

> As the syncgroupID is limited to 10 digits, why not make that clear
> in the ABNF also using 1*10DIGIT as the definition.
> 
> 16. Section 11. Offer/Answer rules It is not clear how one deals with
> the potential existence of multiple sync groups or how the ID is
> negotiated. Especially when you in a multi-party negotiate with an
> application server.
> 
>  And if the XR block type is to be normatively defined by this
> document then two registrations are needed:
> 
- Add the XR SDP parameter:
> RvB: I propose going for informative. The leap-second draft is just a
> way of increasing the accuracy of IDMS. And since it is meant as an
> update to RFC3550, can be considered part of RTCP and not
> specifically targeted at IDMS.

I think that is fine.

Cheers

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Jun 2012 11:10:18 +0200

Regarding IANA registration.

The requirement is specification required, which can obviously be a specification from some other body than IETF.

If you go to the IANA page you will find a set of pages relating to requesting an assignment. Generally I would expect the secretariat of a standards body to complete the request, although again I don't think that is mandatory. You will see the registration in this case came from a member of the ETSI secretariat and the referenced specification is an ETSI specification.

This is all entirely in accordance with the registry requirements.

I do notice that the IETF document and the ETSI document define one and the same XR block. Is there an intention that the ETSI document gets modified to reference the IETF document when finally approved and published (i.e. that the IETF document takes ownership and updates the existing registration? Or is there some other strategy for this block type?

Whatever occurs, this strategy will probably need some explanation in the IANA considerations.

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 28 June 2012 04:04
To: Magnus Westerlund; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 21, 2012 9:52 PM
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

2. Abstract:

3. Section 3:

4. Section 3.

9. Section 6.

10. Section 6.
"To solve

11. Section 7 Title

12. Section 7.

13. Section 7.

14. Section 8.

15. Section 9:

16. Section 11.

17. Section 14.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Stokking, H.M. (Hans)" <[email-masked]>
Date: Thu, 28 Jun 2012 06:29:25 +0000

Hi All,

The registration depends on the requirements posed by the registry. For RTCP XR blocks, this says something like ‘specification required’. This means that any body can specify something, normally standardisation bodies (like ETSI, ITU, etc) but this could even be an open standard by a company I suppose. Furthermore, IANA would ask someone for a review of the document. In this case the mentioned expert on the IANA site is Joerg Ott, see http://www.iana.org/protocols .

This whole thing started with ETSI, although it is clearly something for the AVT/AVTCORE group. That’s the whole reason we started the work here.

Best, Hans

From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
Sent: donderdag 28 juni 2012 5:12
To: [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

...

---

From: Qin Wu <[email-masked]>
Date: Thu, 28 Jun 2012 17:57:59 +0800

I see.
  ----- Original Message ----- 
  From: Glen Zorn 
  To: [email-masked] 
  Sent: Thursday, June 28, 2012 11:11 AM
  Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

  ... 

------------------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Thu, 28 Jun 2012 18:01:10 +0800

Hi, 
----- Original Message ----- 
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Magnus Westerlund" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, June 28, 2012 5:10 PM
Subject: RE: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

[Qin]: I am clear. Thank for your clarification.

[Qin]: That's my concern as well and why raise this issue.

[Qin]: Agree.

Keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: 28 June 2012 04:04
To: Magnus Westerlund; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

Regards!
-Qin
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 21, 2012 9:52 PM
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05

Hi,

2. Abstract:

3. Section 3:

4. Section 3.

9. Section 6.

10. Section 6.
"To solve

11. Section 7 Title

12. Section 7.

13. Section 7.

14. Section 8.

15. Section 9:

16. Section 11.

17. Section 14.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Fri, 29 Jun 2012 13:18:18 +0100

Roni,

I have some comments on this draft:

- I don't believe RTCP is on the RFC Editor's list of approved acronyms for document titles, but RTP is, so I suggest changing the title of the draft to "Inter-destination Media Synchronisation Using the RTP Control Protocol (RTCP)".

- Acronyms also need expanding on first use in the abstract.

- Editorial: the draft might read better if the Section 1.1 heading were removed, and if sub-sections 1.2, 1.3, and 1.4 were made part of a new Section 2 "Rationale".

- Editorial: in Section 1.2, "scalable to large multicast networks" may be better phrased "scalable to large groups" since the functionality is not multicast specific.

- Section 3, near the end of page 6, the draft says "...when both Alice and Bob received (or played out) a particular RTP packet". This might be clearer written "when both Alice and Bob received (and, optionally, when they played out) a particular RTP packet". 

- Section 3 doesn't seem to mention that Alice and Bob need synchronised clocks for this to work. It probably should.

- I find the justification for using a 32 bit NTP presentation timestamp in Section 6, but a 64 bit NTP presentation timestamp in Section 7 to be unconvincing. Could you either strengthen the justification, or move to a common size?

- Section 6: is the PT field needed? The combination of RTP timestamp and SSRC should identify a packet, even with changes in PT and clock rate.

- Section 6, penultimate paragraph: "...in which a certain RTP timestamp shows up for the first time" is problematic, since the RTP timestamp can wrap. 

- Section 8: "receiver involved need synchronised clocks" - yes, but be clear what clock needs to be synchronised. The RTP-format media clocks don't need to be synchronised, for example, while the NTP-format clock does.

- Section 8, 3rd paragraph: is the use of the mechanism in draft-williams-avtcore-clksrc mandatory? It would be useful to make an RFC 2119 style recommendation here.

- Section 8, last paragraph: should "...is therefore recommended to take the guidelines..." be "...RECOMMENDED..."?

Colin

-- 
Colin Perkins
http://csperkins.org/