Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08

"Ali C. Begen (abegen)" <> Thu, 13 June 2013 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E84BB21F9A3D; Thu, 13 Jun 2013 04:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.448
X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SydgPd1d5i1x; Thu, 13 Jun 2013 04:58:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F34621F9A76; Thu, 13 Jun 2013 04:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11571; q=dns/txt; s=iport; t=1371124736; x=1372334336; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0w5UL5EYas5pvdqTUKG3SiITyrqC8Tnwi1kGL+5HVPw=; b=cT2JMzmGjnyiMx45rw1SqR5TeCAE0Yp/Xmslflq9ufTmdIJh5wPM1B98 yEUGEaKbtplNX6DEteP2uaCVTfh1TnJGeffUxoi3QNtYUQeMJdjqfPsIL l0rEkPI+ipbT5knhONKW4A6b7Mq278eInbVMI5Nct0dQDn8ozV6JuxYUk w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah0FAKCzuVGtJXHB/2dsb2JhbABbgkUjITBJgnS7dg1zFnSCJQEEI0gOEgEIDhQgAgQwJQIEAQ0NiAYBqU+RY48SMQeCTDNhA6kDgw+CJw
X-IronPort-AV: E=Sophos; i="4.87,858,1363132800"; d="scan'208,217"; a="222418984"
Received: from ([]) by with ESMTP; 13 Jun 2013 11:58:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r5DBwpba022447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Jun 2013 11:58:51 GMT
Received: from ([fe80::747b:83e1:9755:d453]) by ([]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 06:58:51 -0500
From: "Ali C. Begen (abegen)" <>
To: Qin Wu <>, "" <>
Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08
Thread-Index: AQHOaC1e8zLHZgmgvUyxnoUMR5FcUQ==
Date: Thu, 13 Jun 2013 11:58:29 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940D1421DExmbalnx01ciscoc_"
MIME-Version: 1.0
Cc: xrblock-chairs <>, mmusic <>, 'xrblock' <>
Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jun 2013 11:59:02 -0000

- I don't agree with the following statement:

   Information is recorded about QoE metric which provides a
   measure that is indicative of the user's view of a service.

The application cannot possibly know a user's view of service unless the user explicitly enters that info in some fashion to the application.

[Qin]:  The application can rely on QoE evaluation model to calculate MoS value and use such MoS value to reflect how end user feel or experience the media quality. That’s what this statement want
to convey.

That is not what the sentence says, though, at least to me. The "user's view of a service" is the troubling part to me. What you do is that you apply an algorithm with some observed values and you try to estimate some sort of a mean opinion score. That may or may not be indicative of the end-user's QoE.

- Section 4.1: "extmap" is already a registered attribute name. I did not understand why and in what way you want to use it.

[Qin]: We need a new attribute defining the mapping from the different parameter names (i.e., the different calculation-algorithm parameter names) to the numeric values used in the packets Unlike RFC5285 extmap usage, we map name rather than URI to the numeric values used in the packet.
So I assume “extmap” can be reused, however if not, I believe we should define new attribute similar to “extmap” in this document.

I'd refer to some SDP experts here as I could not understand what you wanna do and how you wanna do it.