RE: SDPng

On Fri, 26 May 2000, Tom-PT Taylor wrote:
> For session description, which I think is what you're talking about here, I
> wasn't aware that expressiveness of SDP was much of a problem.

Depends on your definition of "problem", I guess.  For many applications,
SDP is working just fine.  But, as an example, content negotiation has
been brought up as a desirable feature.  There's already a mechanism in
SMIL for dealing with this:  the <switch> statement.  This allows one to
specify an ordered list of alternative streams or entire presentation
sets from which a client can pick.

From the perspective of an RTSP/SMIL/SDP implementation, the benefits of
combining the SMIL and SDP phases would be pretty great (fewer
roundtrips).

If one believes that SDP should be expressed as XML (a very difficult
transition in some contexts), one would hope that people rethink the
feature set while they are at it.

Rob


> 
> > -----Original Message-----
> > From:	Rob Lanphier [SMTP:robla@real.com]
> > Sent:	Thursday, May 25, 2000 9:14 PM
> > To:	Markus Buchhorn; confctrl@isi.edu; atmsdp@eng.fore.com
> > Cc:	www-smil@w3.org
> > Subject:	Re: SDPng
> > 
> > Hi Markus,
> > 
> > (www-smil@w3.org added to the cc line.  See mail below for context)
> > 
> > The W3C SYMM Working Group is currently in the process of defining the
> > next 
> > version of SMIL (Synchronized Multimedia Integration Language).  It's an 
> > XML-based language describing how to combine multimedia primitives (audio,
> > 
> > video, images, text, etc) into a coherent presentation.
> > 
> > One of the proposed set of extensions to SMIL would be to add RTP delivery
> > 
> > information into the SMIL specification.  The latest draft for this is 
> > located here:
> > http://www.w3.org/TR/smil-boston/extended-media-object.html
> > 
> > A SMIL representation of SDP information would clearly be heavier than an 
> > SDP equivalent, but would also be a lot more expressive.  What's more, 
> > there's many cases where SMIL and SDP are both used in the same 
> > presentation today (RealPlayer and Quicktime support both).
> > 
> > I'll have to add the caveat that this particular portion of the spec
> > hasn't 
> > received a lot of attention due to the fact that the bulk of the working 
> > group has more interest and/or expertise in matters higher in the 
> > application stack than getting the bits from point A to point B.  Input 
> > from this group on fleshing this proposal out would be greatly appreciated
> > 
> > (best sent to www-smil@w3.org to keep me honest)  :)
> > 
> > Since the RTP portion of the SMIL Boston spec has such clear overlap with 
> > an existing IETF spec, it may make sense to separate this out and work on 
> > it as a namespace-separated extension to SMIL Boston, for which the
> > details 
> > are sorted out in the IETF.  That would allow the group with the most 
> > interest and expertise in the matter to participate.
> > 
> > Thoughts?
> > 
> > Rob
> > 
> > At 09:43 AM 5/25/00 +1000, Markus Buchhorn wrote:
> > 
> > >Hi All
> > >
> > >A quick question that leapt to mind from a couple of recent threads. I
> > have
> > >seen mention of various extensions to SDP ("we're hitting some
> > limitations
> > >of SDP"), some for application features (codecs, etc.), some for
> > transport
> > >features (ATM leaps to mind, mobile users ?).
> > >
> > >Which group/who is looking at the next generation of SDP? (I think Mark
> > >Handley mentioned "some people call it SDPv2 and it's not really a v2").
> > I
> > >haven't seen any mailing lists under avt or mmusic (where it should be?)
> > >really discuss it.
> > >
> > >I'd be interested to see what is being done. One idea I wanted to canvas
> > >was the use of XML in session/content/transport description, with
> > >appropriate DTD's being created as necessary. Nicely extensible and
> > >pigeon-hole-able and container-able :-). However, it can be a bit heavy
> > and
> > >SAP puts some strong recommendations on bandwidth usage and packet sizes.
> > >OTOH XML is compressible (e.g. wbxml) in special cases.
> > >
> > >Anyway - just wanted to lob a couple of cents in (around $US0.0114 at
> > last
> > >glance...), and see what people are thinking.
> > >
> > >Cheers,
> > >         Markus
> > >
> > >Markus Buchhorn,  Advanced Computational Systems CRC     | Ph: +61 2
> > 62798810
> > >email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2
> > 62798602
> > >Australian National University, Canberra 0200, Australia |Mobile: 0417 
> > >281429
> > 
>

Received on Tuesday, 30 May 2000 01:46:00 UTC