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 at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic