1. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann SDPng Requirements draft-kutscher-mmusic-sdpng-req-00.txt Dirk Kutscherdku@tzi.uni-bremen.de Jörg Ottjo@tzi.uni-bremen.de Carsten Bormanncabo@tzi.uni-bremen.de http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/

2. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Overview Motivation (Terminology) General requirements Session description requirements Capability negotiation requirements Next steps

3. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Motivation for SDPng No negotiation mechanism in SDP (RFC2327) –Has not been designed for capability negotiation SDP’s extension mechanism –Session and media attributes: a= Provides free extension mechanism Unknown attributes to be ignored Which attributes are required for understanding a session description? –Smooth evolution is difficult when many extensions are developed Limited expressiveness –Syntax, grouping, …

4. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Terminology: Component abstract application in a conference (e.g. interactive audio) characteristics: –intended use (functionality) –set of possibilities to realize functionality Codecs Packetization Transport protocol

5. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Components Host AHost B GSM H.261 QCIF H.261 QCIF GSM PCMU CIF wb CIF PCMU DVI... Component Interactive Audio Component Slide presentation Conference

6. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Terminology: Configuration a way to realize a component's functionality potential configurations –e.g. different supported codecs/parameters actual configurations –an instantiation of one potential configuration, a description how a specific component should be realized

7. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann General Requirements Simplicity –easy to parse and implement Extensibility –extensions mechanisms that allows to accommodate future applications without having to modify base spec. "Firewall friendliness" –session descriptions should be efficiently parsable by network elements

8. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann General Requirements Security –Support for privacy and authentication services of transport and signaling protocols Text encoding –concise text encoding for portability and simple implementations SDP-mapping –translate SDPng to SDP –maybe not always possible

9. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Session Description Requirements Media types –Must fit into RFC 1889/1890 model of standard and dynamic payload types –Re-use payload formats, format names, RTP-profiles, MIME-mapping Media Stream Packetization –Support different variants: Redundancy encoding scheme, FEC, stream repair etc. Codec specification independent from packetization scheme Extensible to other or non-standard schemes

10. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Requirements for Describing Transport Parameters Transport –Support for different transport protocols and network architectures (IP, ATM etc.) Different address formats, parameters Different QoS models and parameters –Flexibility More than 1 transport address per component –Layered encodings –Multi-/unicast address lists More than 1 address per potential configuration set –Specialized media engines –Constraints like source filters etc.

11. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Session Description Requirements Arbitrary other parameters –Extension mechanism required Identify extensions Distinguish mandatory and optional extensions Asymmetric configurations –“Can send format A but want to receive format B” Conciseness and structured extensibility requires –Grouping of definitions –Naming and referencing groups

12. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Elements of Capability Negotiation Model for specifying alternatives (potential configurations) Negotiation model –Syntax and semantics Obtain session description as negotiation result –Augment negotiation result with transport parameters and general session info

13. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Capability Negotiation Requirements I Fit into SIP model (3-way handshake) Semantics independent –Feature-unaware negotiation is key to extensibility and smooth future evolution Grouping capabilities required for –Conciseness of exchanged negotiation –Referencing, combining capability sets –Structured extension mechanism

14. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann Capability Negotiation Requirements II Constraints –Simultaneous capabilities (in a simple way!) “Up to 10 GSM or G.711 streams, but only one codec at a time.” –Processing rules Point-to-point and multiparty Different negotiation policies for different session types “Implementation issues” –Re-use other IETF work, namely RFC 2533

15. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann What next? More requirements? –MEGACO –Specific link layers and protocols Develop architecture –Session description –Capability negotiation Decide on syntax

16. 8/2/200048. IETF, Pittsburgh Kutscher/Ott/Bormann http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/