Subject: Re: [MMUSIC] draft-johansson-mmusic-grouping-simultaneous-01

From: <[email-masked]>
Date: Wed, 23 Feb 2011 15:32:09 +0100

Hi Ingemar et al.

Could you please verify whether the "Composite Session" (CS) token syntax and semantics provide the necessary and sufficient functionality for the SID use cases?

(CS: http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-sdp-00.txt, originally draft-mehta-rmt-flute-sdp-04, November 2005)

It might not make sense to have two IANA MID tokens doing the same job and, IMHO, CS and SID are both grouping the same content session together for a set of media for the receiver/sink/client to interpret which one or more media to use. In the RTP & SID case, the expectation is a single media is used, in the FLUTE and CS case the expectation is that the client understands enough of the channelisation or congestion control to know which one or several to use (in both cases the same content is delivered within media of the "composite session" / media group). In the (not documented) multi-layer delivered over multi-media RTP case I would assume something like the FLUTE and CS expectation of the client understanding which one or more media to use.

Sorry about any conflicts or inconvenience caused, no wailing or gnashing of teeth is intended!

There's no obsicle to documenting the RTP/SID use case in draft-ietf-rmt-flute-sdp if it make sense to use the CS token for this use case. Likewise, documenting the RTP/SID case using the CS token in a seperate ID would achieve the same thing.

The relevant (and modifiable) quote from draft-ietf-rmt-flute-sdp is:
3.2.2.  Composite Session Semantics for Protocols other than FLUTE
   The Composite Session mechanism solves the problem of describing
   multiple FLUTE sessions in a single SDP instance.  However, this does
   not place any restrictions on the use of the Composite Session
   mechanism with transport protocols other than FLUTE/UDP, nor on
   whether a complete SDP would include media of other transport
   protocols too.  Specification of semantics beyond the use of FLUTE
   sessions is outside the scope of this document.

(Incidentally, we are interested in any final conflicts and inconveniences for the security and congestion control description in draft-ietf-rmt-flute-sdp-00 before we revise to 01 and do a standards track WGLC. i.e. - suggested reuse and extension of existing work is very welcome! So far we've only found RFCs 4567 and 4568 to be promising).

Cheers, Rod.

On 17/11/2010 15:29, ext Ingemar Johansson S wrote:

Hi

I would like to make the WGs aware of this draft
http://tools.ietf.org/id/draft-johansson-mmusic-grouping-simultaneous-01.txt

This draft has relevance for the upcoming multistreams work discussed in DISPATCH (Teleprecense)

=========
Abstract
   This document proposes an extension to the grouping framework
   [RFC5888].  The extension identifies media descriptions that contain
   different representations of identical content.  An example of this
   is an endpoint that sends both a high-resolution and a low-resolution
   video sequence to a conferencing server.
=========

Regards
/Ingeamr
=================================
INGEMAR JOHANSSON  M.Sc.
Senior Research Engineer

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com<http://www.ericsson.com>
Visit http://labs.ericsson.com !
=================================
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic