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

Magnus Westerlund <> Thu, 03 November 2011 13:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 269E011E811F for <>; Thu, 3 Nov 2011 06:48:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.579
X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id evdwhfqrVmPU for <>; Thu, 3 Nov 2011 06:48:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0106711E8087 for <>; Thu, 3 Nov 2011 06:48:28 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c26ae0000035b9-a9-4eb29ba6f865
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6D.C1.13753.6AB92BE4; Thu, 3 Nov 2011 14:48:23 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 3 Nov 2011 14:48:22 +0100
Message-ID: <>
Date: Thu, 3 Nov 2011 14:48:21 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Qin Wu <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: IETF AVTCore WG <>, "" <>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Nov 2011 13:48:30 -0000


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?


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: