Subject: SDPng

From: Markus Buchhorn <[email-masked]>
Date: Thu, 25 May 2000 09:43:37 +1000

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

---

From: Dirk Kutscher <[email-masked]>
Date: 25 May 2000 12:50:47 +0200

>>>>> "Markus" == Markus Buchhorn <[email-masked]> writes:

    Markus> Which group/who is looking at the next generation of SDP?
    Markus> (I think Mark Handley mentioned "some people call it SDPv2
    Markus> and it's not really a v2"). I haven't seen any mailing
    Markus> lists under avt or mmusic (where it should be?)  really
    Markus> discuss it.

Markus,

we have started a discussion about this about a year ago and submitted
an ID called "Capability description for group cooperation". The draft
has expired but you can grab an old copy at

ftp://ftp.tzi.uni-bremen.de/doc/internet-drafts/draft-ott-mmusic-cap-00.txt

The draft does not directly propose a concrete new SDP version but
also deals with

	- a model for multimedia conferencing from a
          configuration point of view: We used the notion of
          "components" that are basically applications within a
          multimedia conference and can be mapped to the final media
          streams. The way components can be implemented depends on
          the capabilities of end-systems and preferences of users,
          what we called "potential configurations".

	- the relation between "session description" and capability
          negotiation: In a capability negotiation process
          potential configurations are taken as input for a function
          that finally yields a usable "actual configuration", that is
          an element of a session description.

	- algorithms for capability negotiation and mapping to/from
          SDP: We have presented an algorithm that allows capability
          negotiation without having to know the semantics of
          individual descriptions, which is important for
          extensibility.

The motivation for this was the observation that, while SDP has not
been designed to support capability negotiation, the dynamic
negotiation of session parameters is considered an important
functionality for conferencing/IP-telephony and that there are usage
scenarios where protocols like SIP actually do rely on capability
negotiation involving SDP.

It is obvious that negotiating capabilities and describing session
parametes are closely related and that it is probably useful to have a
common representation for both purposes, so this is one reason why
developing a "new" SDP has been considered. Other reasons may be the
various proposals of extending SDP that have been presented and that
suggest that, while SDP provides some extension mechanisms, it lacks
the required extensiblity to support all this conveniently.

Because of the capability negotiation aspect a few more questions
arise as it would have been the case for finding a new representation
for session descriptions.

For example, it has been noted that capability negotiation has a
considerable overlap to content negotiation, i.e. RFC2703 and
RFC2533. It makes sense to build upon this work but it is also
important to adhere to the "keep it simple" requirement, one of the
reasons being the one you mention below:

    Markus> I'd be interested to see what is being done. One idea I
    Markus> wanted to canvas was the use of XML in
    Markus> session/content/transport description, with appropriate
    Markus> DTD's being created as necessary. Nicely extensible and
    Markus> pigeon-hole-able and container-able :-). However, it can
    Markus> be a bit heavy and SAP puts some strong recommendations on
    Markus> bandwidth usage and packet sizes.  OTOH XML is
    Markus> compressible (e.g. wbxml) in special cases.

I think, before thinking of DTDs, schemata and concrete
representations we have to address the fundamental questions of how
the model for capability negotiation and session decription should
look like etc. It should then be comparatively easy to find one (or
more) appropriate representation syntaxes, maybe even an XML-based
one.

Discussion about all this is of course welcome.

-- 
	Dirk

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 25 May 2000 18:13:53 -0700

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