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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Christer,

Thanks for your review.

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> 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,
> 
> 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 <[e-mail]> 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.

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

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

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

Agreed.
 
> 
> 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.

:) yeah sorry about that.

Cheers,
-acbegen
 
> 
> Regards,
> 
> Christer