[AVT] RE: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed
Dave Singer <singer@apple.com> Tue, 05 June 2007 15:35 UTC
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvb4E-0005RA-20; Tue, 05 Jun 2007 11:35:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvb4C-0005Lw-Un; Tue, 05 Jun 2007 11:35:28 -0400
Received: from mail-out3.apple.com ([17.254.13.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvb4C-0005Zz-Ce; Tue, 05 Jun 2007 11:35:28 -0400
Received: from relay5.apple.com (relay5.apple.com [17.128.113.35]) by mail-out3.apple.com (Postfix) with ESMTP id AED427F511F; Tue, 5 Jun 2007 08:34:33 -0700 (PDT)
Received: from relay5.apple.com (unknown [127.0.0.1]) by relay5.apple.com (Symantec Mail Security) with ESMTP id E632329C002; Tue, 5 Jun 2007 08:35:27 -0700 (PDT)
X-AuditID: 11807123-9d01cbb000000a23-7a-466582bf36d2
Received: from [17.202.35.52] (unknown [17.151.66.148]) by relay5.apple.com (Apple SCV relay) with ESMTP id 58E4830400E; Tue, 5 Jun 2007 08:35:27 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0624081ac28b3247e073@[17.202.35.52]>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com>
References: <144ED8561CE90C41A3E5908EDECE315C049E76DA@IsrExch01.israel.polycom.com>
Date: Tue, 05 Jun 2007 08:34:08 -0700
To: "Even, Roni" <roni.even@polycom.co.il>, mmusic <mmusic@ietf.org>, IETF AVT WG <avt@ietf.org>
From: Dave Singer <singer@apple.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: "Clinton Priddle (KI/EAB)" <clinton.priddle@ericsson.com>
Subject: [AVT] RE: [MMUSIC] questions about grouping media streams in RTP and SDP (RFC3388 etc), advice needed
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org
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.tx >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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] Moving draft-marjou-behave-app-rtp-keepaliv… Colin Perkins
- [AVT] RE: Moving draft-marjou-behave-app-rtp-keep… Dan Wing
- [AVT] Re: [BEHAVE] RE: Moving draft-marjou-behave… Lars Eggert
- [AVT] questions about grouping media streams in R… Dave Singer
- [AVT] RE: [MMUSIC] questions about grouping media… Even, Roni
- AW: [AVT] RE: [MMUSIC] questions about grouping m… Kalleitner, Franz
- [AVT] RE: [BEHAVE] RE: Moving draft-marjou-behave… Dan Wing
- Re: [AVT] RE: Moving draft-marjou-behave-app-rtp-… Cullen Jennings
- [AVT] RE: Moving draft-marjou-behave-app-rtp-keep… Even, Roni
- [AVT] Re: [BEHAVE] RE: Moving draft-marjou-behave… Colin Perkins
- [AVT] Re: [BEHAVE] RE: Moving draft-marjou-behave… Lars Eggert
- [AVT] RE: [MMUSIC] questions about grouping media… Dave Singer
- [AVT] RE: [MMUSIC] questions about grouping media… Even, Roni
- Re: [AVT] questions about grouping media streams … Andrea Lorenzo VITALI
- Re: [AVT] questions about grouping media streams … 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
- Re: [AVT] Moving draft-marjou-behave-app-rtp-keep… 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