Subject: RE: SDPng

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 30 May 2000 16:03:30 -0500

Note that I limited my statement to session description as opposed to
capability negotiation.  It happens in Megaco that we have already
incorporated semantics for alternative session descriptions, without the
need for any specific labelling.  However, this alone is not enough because
when you get down to small details ("I'll accept any of these packetization
intervals" -- which share the common property that they are 40 ms or
greater) you get a potential number of session descriptions which is
exponential with the number of individual variables to be negotiated.  As a
result, we modified SDP in the MGC-to-MG direction to include constraints
and  other expressions of choice for individual parameters.

> -----Original Message-----
> From:	Rob Lanphier [SMTP:[email-masked]]
> Sent:	Tuesday, May 30, 2000 1:46 AM
> To:	Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:	[email-masked]; [email-masked]
> Subject:	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:[email-masked]]
> > > Sent:	Thursday, May 25, 2000 9:14 PM
> > > To:	Markus Buchhorn; [email-masked]; [email-masked]
> > > Cc:	[email-masked]
> > > Subject:	Re: SDPng
> > > 
> > > Hi Markus,
> > > 
> > > ([email-masked] 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 [email-masked] 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: [email-masked], snail: ACSys, RSISE Bldg,|Fax: +61 2
> > > 62798602
> > > >Australian National University, Canberra 0200, Australia |Mobile:
> 0417 
> > > >281429
> > > 
> > 
>