Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Nov 2011 14:48:21 +0100

Hi,

Removing all issues that don't need additional discussion or commenting.

On 2011-10-25 07:45, Qin Wu wrote:
> 
> 9. Section 4:
> "It is also
>       fixed across multiple RTP sessions from the same source."
> 
> I interpret "source" in the above as an end-point or RTP node. Which
> causes me to have the following comment.
> 
> This is very commonly true, but not universally true. As CNAME
> identifies a synchronziation context, a given end-point could have media
> sources that belong to multiple synchronization contexts in the same
> session. For example have microphones and cameras from multiple rooms,
> where each room will be its own synchronization context.
> 
> 
> 
> [Qin]: Agree with your thinking, but here what we emphasize is "across multiple RTP session"
> 
> Does this really conflict with what you said?
> 
> Anyway I will reword this in the new vesion.
> 

No, as long as we consider source as media recording device(s) in a
given synchronization context they will be fixed across multiple sessions.

> 
> 12. Section 4. bullet 3:
> This issues does not have a recommendation in the next section. I think
> we should document the WG consensus on this issue. Even if it was that
> this issue wasn't significant enough to do something about. Or am I
> remembering the WG consensus wrong?
> 
> 
> 
> [Qin]: Yes, the issue wasn't significant and I remembered the consensus is 
> 
> to replace tag with the SSRC and use SSRC to identify and correlate and group
> 
>  participants between reports. The sequence numbering information and
> 
>  measurement interval can be defined in a new RTCP XR block if needed, 
> 
> but is not related to identity. Therefore I will add one section to talk about how to deal with this issue.
> 

Thanks, I think it is strange if we don't document the consensus
resolution when it is listed as an issue.

> 
> 21. Section 7.1:
> 
> Strictly the RTP end
>    system can only conclude that its RTP has been lost in the network,
>    though an RTP end system complying with the robustness principle of
>    [RFC1122] should survive with essential functions unimpaired.
> 
> What is the purpose with this sentence? And what is actually seen as
> "essential functions"?
> 
> 
> 
> [Qin]: I think essential functions are referred to as "media distribution"

So you mean that a robustly built end-point will still be able to send
its media despite the fact that media it should receive has been lost in
between the sender and this receiver?

> 
> 22. Section 7.2:
> For bidirectional unicast, an RTP system may usually detect RTCP XR
>    from a translator by noting that the sending SSRC is not present in
>    any RTP media packet.
> 
> So the assumption here is that the translator has its own SSRC to send
> these monitoring reports. But, how does an RTP node determine that an
> SSRC is associated with a translator rather than a receiver only
> end-point? From a session participant I don't think you can determine if
> a give SSRC is a receiver or just a monitor. They will not look
> different. One needs session configuration information, and in that case
> configuration information where the translator announces its node type
> to the management system.
> 
> 
> 
> [Qin]: That's what I want to said in part. And I agree that node type should also be announced.
> 
> I will reflect the draft to reflect this.

Ok, I think the new text is good enough.

> 
> 23. Section 8. I agree that this draft shouldn't have a IANA
> Consideration other to say that it is has no actions. However, I think
> the document should consider if it has some guidance on IANA actions for
> the monitoring architecture. Some part of this is clearly about the
> consumption of XR block code points that isn't a major issue. And if we
> do run out a second RTCP packet type for XR block 2 could be assigned.
> 
> 
> 
> [Qin]: The WG consensus is space depletion is not issue
> 
> if you really want space expansion, you can define one XR block type
> 
>  for vendor-specific extensions, with an enterprise number included 
> 
> to identify the vendor making the extension. So I prefer to say
> 
> "There is no IANA action in this document"

Yes, but if that is the conclusion, shouldn't we document it?

Cheers

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: Qin Wu <[email-masked]>
Date: Fri, 04 Nov 2011 10:13:32 +0800

----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "IETF AVTCore WG" <[email-masked]>; <[email-masked]>
Sent: Thursday, November 03, 2011 9:48 PM
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04

> given synchronization context they will be fixed across multiple sessions.

[Qin]: Okay, do we have other use cases besides the above one you gave?

> resolution when it is listed as an issue.

[Qin]: Yes, I have documented them in the new version 05 I submitted before the deadline.

> between the sender and this receiver?

[Qin]: That's my understanding, is that okay with you?

>> I will revise the draft to reflect this.
> 

[Qin]: Thanks.

> Yes, but if that is the conclusion, shouldn't we document it?

[Qin]: Okay, I can put them in the new version.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Nov 2011 11:01:56 +0100

> [Qin]: Okay, do we have other use cases besides the above one you gave?

Not from the top of my head.

> [Qin]: That's my understanding, is that okay with you?

Yes.

> [Qin]: Okay, I can put them in the new version.

Great

Cheers

Magnus Westerlund