AW: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed

hi, dave,

you can find some work and ideas on how to handle a "repair" stream in parallel to an orignal RTP stream in RFC4588 too.

cheers, franz

________________________________

Von: Even, Roni [mailto:roni.even@polycom.co.il]
Gesendet: Di 05.06.2007 09:03
An: Dave Singer; mmusic; IETF AVT WG
Cc: Clinton Priddle (KI/EAB)
Betreff: [AVT] RE: [MMUSIC] questions about grouping media streams in RTPand SDP (RFC3388 etc), advice needed

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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic