[Rmt] Re: [MMUSIC] FW: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt

[Joerg Ott <jo at netlab.hut.fi>]

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?

Cheers,
Joerg

PS: Is there any chance to fix this stuff in 3GPP?


> FYI, the FLUTE-SDP I-D update is now available.
>
> This was identified by 3GPP as a dependency for release 6. Hence, if you
> do identify problems please state ASAP.
>
> Also, this will be handled in RMT style, i.e. is for experimental. When
> FLUTE (and it's dependencies) go standards track, this FLUTE-SDP will be
> updated for that too. However, we expect the experimental FLUTE-SDP to
> be already ready for standards track except for trivial nits (if any).
>
> Cheers, Rod.
>
> PS Anyone not interested in FLUTE, but generally interested in SDP and
> MMUSIC should still take a look at the CS token for SDP grouping - a
> handy device for setting session semantics independently of "all an SDP
> instance" and "per media" (which is defined as it is needed to declare
> multiple FLUTE session (with multiple FLUTE channels) per SDP).
>
> PPS There are many people who have help. If we forgot your name on the
> acknowledgements please flame me directly and I'll sort it out.
>
>
>
>
> > -----Original Message-----
> > From: Michael Lee [mailto:mlee at newodin.ietf.org] On Behalf Of 
> > ext ID Tracker
> > Sent: 10 November, 2005 22:50
> > To: Mehta Harsh (Nokia-NET/Helsinki); sami.peltotalo at tut.fi; 
> > Walsh Rod (Nokia-NRC/Tampere); magnus.westerlund at ericsson.com; 
> > mankin at psg.com
> > Subject: New Version Notification - draft-mehta-rmt-flute-sdp-04.txt 
> >
> > New version (-04) has been submitted for 
> > draft-mehta-rmt-flute-sdp-04.txt.
> > http://www.ietf.org/internet-drafts/draft-mehta-rmt-flute-sdp-04.txt
> >
> > Sub state has been changed to AD Follow up from New Id Needed
> >
> > IETF Secretariat.
>
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic


_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt