RE: SDPng

["Tom-PT Taylor" <[e-mail]>]

I did want to say that Megaco has a great deal of interest in an improved
capability negotiation protocol.  We deliberately isolated media flow
negotiation within the Megaco protocol (to the Local and Remote descriptors)
to make it easier to move to a new protocol should a replacement for SDP
appear.  We can use SDP now, but we are threatened with a combinatorial
explosion if there are a lot of details to negotiate.

I suppose this means I should be contributing  to discussion of the topic in
MMUSIC :-)

> -----Original Message-----
> From:	Dirk Kutscher [SMTP:[e-mail]]
> Sent:	Thursday, May 25, 2000 6:51 AM
> To:	Markus Buchhorn
> Cc:	[e-mail]; [e-mail]
> Subject:	Re: SDPng
> 
> >>>>> "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.tx
> t
> 
> 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
> 
>