[MMUSIC] Comment on draft-jennings-mmusic-adjacent-grouping-03

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 18 March 2011 12:44 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3603A68F2 for <mmusic@core3.amsl.com>; Fri, 18 Mar 2011 05:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level:
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZW1jlaBTe5F for <mmusic@core3.amsl.com>; Fri, 18 Mar 2011 05:44:49 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A9AB53A68D3 for <mmusic@ietf.org>; Fri, 18 Mar 2011 05:44:48 -0700 (PDT)
X-AuditID: c1b4fb39-b7c6dae0000023f2-14-4d835418b32d
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 20.2D.09202.814538D4; Fri, 18 Mar 2011 13:46:17 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 18 Mar 2011 13:46:16 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: mmusic <mmusic@ietf.org>
Date: Fri, 18 Mar 2011 13:46:15 +0100
Thread-Topic: Comment on draft-jennings-mmusic-adjacent-grouping-03
Thread-Index: Acvlangn5Qkpf9TQRJGv64ydqgt7ag==
Message-ID: <224F5CB1ECAB2C45BC64065AFD0339650406B5FD57@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: Cullen Jennings <fluffy@cisco.com>
Subject: [MMUSIC] Comment on draft-jennings-mmusic-adjacent-grouping-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2011 12:44:50 -0000

Hi Cullen/Ali,

There were some comments given on this draft in Beijing, but I am not sure they have been addressed in the new version.

Q1: Declaration vs negotiation
------------------------------

In Beijing it was commented that the usage is not for negotation, but rather for *declaration*. Based on the minutes from Beijing, the authors verified that the intended usage if for declaration.

        "Cullen Jennings <fluffy@cisco.com> replied that there are people who need this capability. The big difference from telepresence 
        would be its declarative nature, in contrast to the negotiation capability intended for telepresence."

So, IF this is about declaration, I think that should be clear in the draft, and everything about telepresence, SDP offer/answer etc should be removed.


Q2: SDP offer/answer
----------------------

(Assuming this is intended to be used also for negotiation)

When used with SDP offer/answer, when an entity sends an SDP offer, it indicates what it is willing to *receive*. So, if I use this mechanism, I would *not* say "please show media received on this stream on your left display", but "please SEND media for MY left display on this stream*. The declarative nature makes it difficult to understand what the intended usage (if any) with SDP offer/answer is.



Q3: Audio/video association
-----------------------------

The draft does not provide a mechanism to e.g. associate audio and video streams. I GUESS that could be done by using the same mid value for two streams (e.g. an audio and a video stream). IF that's the case, I think it needs to be described.



Q4: Telepresence
------------------

(Assuming this is intended to be used also for negotiation)

The draft also talks about telepresence, where I agree this kind of feature very likely will be needed. But, my suggestion would be for CLUE to agree on requirements before taking on this draft, to make sure that it can be used to meet those requirements.

This was also mentioned in Beijing.

        "Magnus Westerlund <magnus.westerlund@ericsson.com> would like to see where the telepresence work goes, but was concerned that
        we not have two solutions to the same problem. Peter Musgrave <peter.musgrave@magorcorp.com> supported him,..."

        "Mary Barnes <mary.ietf.barnes@gmail.com> asked if anyone else supported the work. Why not wait for telepresence?"

So, again, it needs to be clarified what the scope of the propsed mechanism is.


Q5: Editorial
-------------

The SDP example shows audio streams (m=audio), but I assume it's meant to be video (m=video)?


If these issues have been discussed and solved on the list between Beijing and new, I appologize for having missed it.


Regards,

Christer