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

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Mar 2011 13:46:15 +0100

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 <[email-masked]> 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 <[email-masked]> would like to see where the telepresence work goes, but was concerned that
        we not have two solutions to the same problem. Peter Musgrave <[email-masked]> supported him,..."

        "Mary Barnes <[email-masked]> 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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 24 Mar 2011 04:17:04 -0700

Hi Christer,

Thanks for your review.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, March 18, 2011 1:46 PM
> To: mmusic
> Cc: Cullen Jennings (fluffy); Ali C. Begen (abegen)
> Subject: Comment on draft-jennings-mmusic-adjacent-grouping-03
> 
> 
> Hi Cullen/Ali,
> 
> 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.
> 

We can reduce the draft to declaration only, however, the 5888 already provides o/a model support. Is that a concern?
 
> 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.

You are right. Depending on how we move on the first issue, this should be either removed or fixed.
 
> 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.

(Yes, this is an open issue that we realized after the revision).

Is that a legal use of mid values? It probably needs more thought on this, but I suspect this method won't cover all the scenarios that this draft could be used for.
 
> 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.
> 
> 

Agreed.
 
> Q5: Editorial

:) yeah sorry about that.

Cheers,
-acbegen