Hi Rod,
since you asked for feedback :-)
I haven't checked for nits but, overall, the attributes and
the outline looks ok.
You know that I am quite unhappy with the general default rule.
In essence, we are using the grouping framework to indicate non-
grouping. If I have want to specify two independent FLUTE sessions
each on one m= line, I have to include the grouping attribute and
specify that no grouping exists. Which is not exactly intuitive :-)
Since traditional SDP applications haven't used FLUTE, there is
probably not so much of a backwards compatibility problem.
Nevertheless, this breaks with the SDP semantics we have been using
so far, namely that each m= line indicates a new media session
unless explicitly specified otherwise.
I feel architecturally uneasy with introducing behavior that makes
the interpretation of media sessions dependent on the session type.
Here's another proposal:
I have also taken another look at sdp-25: the good ol' multicast
support described there in section 5.7 allows you to specify
multiple layers. And from the your draft, most attributes apply
to the media session as a whole, except for the fec identification.
This identification could just be done by order or appearance.
If you do not need to rely on other than consecutive port numbers
for the different layers, this c= semantics peered with the m=
port range might even do for you. As there is no negotiation and
the sender can choose the ports (do you multicast through NATs?)
that restriction should be ok.
On a side note:
How does this relate to draft-ietf-mmusic-fec-grouping-00.txt?
And do we need both of these?