Re: SDPng

[Dirk Kutscher <[e-mail]>]

>>>>> "Markus" == Markus Buchhorn <[e-mail]> 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