RE: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed
"Even, Roni" <roni.even@polycom.co.il> Wed, 06 June 2007 06:33 UTC
Return-path: <mmusic-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvp5N-0004Q6-74; Wed, 06 Jun 2007 02:33:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvp5L-0004KH-FT; Wed, 06 Jun 2007 02:33:35 -0400
Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvp5J-0004r1-2W; Wed, 06 Jun 2007 02:33:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed
Date: Wed, 06 Jun 2007 09:34:12 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C049E78C5@IsrExch01.israel.polycom.com>
In-Reply-To: <p0624081ac28b3247e073@[17.202.35.52]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed
Thread-Index: Acenh0L0V4NbyfevQQuzIOSQ/dMA4AAevHPg
From: "Even, Roni" <roni.even@polycom.co.il>
To: Dave Singer <singer@apple.com>, mmusic <mmusic@ietf.org>, IETF AVT WG <avt@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c
Cc: "Clinton Priddle (KI/EAB)" <clinton.priddle@ericsson.com>
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org
Dave, From your response: "No, these streams are not alternatives to each other in the regular sense. Nor is this really used in offer/answer; it's more an issue for multicast. In multicast, you open the tune-in stream and the base stream, grab the first I-frame that arrives (in either) and then drop the tune-in stream. Yes, we're aware that the recipient needs to be able to tell which is the base and which is the tune-in." Reading your application I will try to generalize it. To me you have two streams that have a relationship and there is semantics for the relation between the streams. You say that typically a user will only use the tune-in stream for synchronization; I would think that this can happen when joining the session or when losing synchronization. In the general case these two streams are coming from the same source and the user may use one or the other. This is why I called them alternate streams After specifying the two streams (as alternate since the receiver may chose one or the other), you want to apply a specific semantics to the content of one stream (a repair stream). Again, I think that we need to specify the general mechanism for semantics to enable implementations from different vendors to understand what to do with the streams coming from the same source. In the current work at MMUSIC, the Label attribute (RFC 4574) define tags to a stream but with no semantics. The content attribute RFC 4796 defines semantic to a stream. I think that we now have a requirement for adding semantics to the relationship between streams; examples are the repair streams and the layered codecs. I think that by using grouping and dependency attributes we can define a general framework that will enable these general requirements and use them for the specific applications like repair stream, layered codecs and just alternate offers. Roni > -----Original Message----- > From: Dave Singer [mailto:singer@apple.com] > Sent: Tuesday, June 05, 2007 6:34 PM > To: Even, Roni; mmusic; IETF AVT WG > Cc: Clinton Priddle (KI/EAB) > Subject: RE: [MMUSIC] questions about grouping media streams in RTP and > SDP (RFC3388 etc), advice needed > > At 10:03 +0300 5/06/07, Even, Roni wrote: > >Dave, > >For layered encoding there is a proposal for a new grouping attribute in > >http://tools.ietf.org/wg/mmusic/draft-schierl-mmusic-layered-codec-03.t x > >t > > I don't think this is a layered coding issue, either, alas. > > >I looked at RFC3388 and I think that FID is not the answer to your > >requirement as you mentioned > > > >To me it looks like what you are looking for is a way to specify > >alternate offers. > > No, these streams are not alternatives to each other in the regular > sense. Nor is this really used in offer/answer; it's more an issue > for multicast. In multicast, you open the tune-in stream and the > base stream, grab the first I-frame that arrives (in either) and then > drop the tune-in stream. > > Yes, we're aware that the recipient needs to be able to tell which is > the base and which is the tune-in. > > >If this is the case I have similar requirements and > >would be happy to support such work. > > > >You also need a way to give semantics to the "repair" stream, this can > >be done based on the content attribute from RFC 4796 or using a > >dependency attribute see in Schierl's draft. The mid tag is not enough > >for the receiver to know what you meant by this offer and which stream > >is the repair. > > > >Here is an example for a solution using a new Alternatives grouping > >attribute and giving semantics to the repair stream > > > >By using the grouping attribute in the offer you can know if the > >answerer understood the grouping since if he does not than he will send > >an answer with no a=group > > > >v=0 > >o=bob 280744730 28977631 IN IP4 host.example.com > >s= > >t=0 0 > > > >a=group:ALTS 1 2 > >a=group:ALTS 1 3 > > > >m=audio 6886 RTP/AVP 0 > >c=IN IP6 2001:0600::1 > >a=mid:1 > > > >m=video 9000 RTP/AVP 100 > >c=IN IP4 192.0.2.2 > >a=rtpmap:100 H263-1998 > >a=mid:2 > > > >m=video 9002 RTP/AVP 101 > >c=IN IP4 192.0.2.2 > >a=rtpmap:101 H263-1998 > >a=mid:3 > >a=content:repair=2 or a=depend:repair=2 > > > > > >Roni Even > > > >> -----Original Message----- > >> From: Dave Singer [mailto:singer@apple.com] > >> Sent: Monday, June 04, 2007 7:19 PM > >> To: mmusic; IETF AVT WG > >> Cc: Clinton Priddle (KI/EAB) > >> Subject: [MMUSIC] questions about grouping media streams in RTP and > >SDP > >> (RFC3388 etc), advice needed > >> > >> Hi > >> > >> we have a need to group together two media streams, in the style of > >RFC > >> 3388 <http://www.ietf.org/rfc/rfc3388.txt> but we're unsure whether an > >> existing group type is suitable or not, and if it's not, we'd like to > >> agree on a new one, and document it (presumably in an RFC). > >> > >> What we have is a normal media stream, and a separate 'repair' or > >> 'entry' stream, that can be used when tuning in, or after loss, but is > >> otherwise un-needed. An example might be a video stream with a low > >> I-frame interval (say every 15 seconds), with a repair stream which > >has > >> only I-frames that are equivalent to the time-parallel non-I frame, at > >a > >> frequency of say 1 per second. > >> > >> It's not clear to us whether this is "one media flow" in the sense of > >> FID, or not. The example offers AMR and GSM audio, which are > >> alternatives, and DTMF tones along with audio, which are supplementary > >> to each other. Perhaps we fall afoul of this restriction: > >> > >> "An application that encodes the same media using different codecs > >> simultaneously MUST NOT use FID to group those media lines." > >> > >> or this one, for layered encoding: > >> > >> "FID MUST NOT be used to group "m" lines that do not represent the > >same > >> information." (Though how DTMF tones and their associated audio pass > >> this test is not clear). > >> > >> Nor is it clear that the FEC group of RFC 4756 is right, either. For > >a > >> start, we may wish to use this new ID in combination with FEC, and > >> secondly this tune-in stream has different characteristics. For > >> example, one can typically ignore all FEC and (as long as there are no > >> errors) decode the stream correctly. Ignoring the tune-in stream > > > entirely may mean that you will never find a tune-in point, making > the > >> normal stream useless. > >> > >> So, can we use FID for associating a repair stream with its base (we > >tag > >> the streams so we know which is which, of course)? > >> > >> p.s. RFC 4756 claims in the IANA section that the FEC group is > >> registered under SDP characteristics, but actually I can find no > >> registry anywhere in IANA of group types. > >> > >> > >> -- > >> David Singer > >> Apple/QuickTime > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > -- > David Singer > Apple/QuickTime _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] New draft: multiple times problem descri… Miguel Garcia
- RE: [MMUSIC] New draft: multiple times problem de… Dan Wing
- Re: [MMUSIC] New draft: multiple times problem de… Miguel Garcia
- RE: [MMUSIC] New draft: multiple times problem de… Christer Holmberg (JO/LMF)
- Re: [MMUSIC] New draft: multiple times problem de… Miguel Garcia
- Re: [MMUSIC] New draft: multiple times problem de… Colin Perkins
- [MMUSIC] Moving draft-marjou-behave-app-rtp-keepa… Colin Perkins
- [MMUSIC] RE: Moving draft-marjou-behave-app-rtp-k… Dan Wing
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Lars Eggert
- [MMUSIC] questions about grouping media streams i… Dave Singer
- [MMUSIC] Re: [AVT] RE: Moving draft-marjou-behave… Cullen Jennings
- [MMUSIC] RE: Moving draft-marjou-behave-app-rtp-k… Even, Roni
- [MMUSIC] RE: [BEHAVE] RE: Moving draft-marjou-beh… Dan Wing
- RE: [MMUSIC] questions about grouping media strea… Even, Roni
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Xavier Marjou
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Colin Perkins
- AW: [AVT] RE: [MMUSIC] questions about grouping m… Kalleitner, Franz
- [MMUSIC] Re: [BEHAVE] RE: Moving draft-marjou-beh… Lars Eggert
- RE: [MMUSIC] questions about grouping media strea… Dave Singer
- RE: [MMUSIC] questions about grouping media strea… Even, Roni
- [MMUSIC] Re: [AVT] questions about grouping media… Andrea Lorenzo VITALI
- [MMUSIC] Re: [AVT] questions about grouping media… Dave Singer
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Dave Singer
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Even, Roni
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- Re: [AVT] RE: [MMUSIC] questions about grouping m… Stephan Wenger
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Even, Roni
- RE: [AVT] RE: [MMUSIC] questions about grouping m… Thomas Schierl
- Re: [AVT] RE: [MMUSIC] questions about grouping m… Stephan Wenger
- [MMUSIC] Re: [AVT] Moving draft-marjou-behave-app… Colin Perkins
- Re: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Even, Roni
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer
- Re: AW: [AVT] RE: [MMUSIC] questions about groupi… Randell Jesup
- Re: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Even, Roni
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Even, Roni
- RE: AW: [AVT] RE: [MMUSIC] questions about groupi… Dave Singer