1 / 13

SDPng Requirements

SDPng Requirements. Dirk Kutscher dku@tzi.uni-bremen.de Jörg Ott jo@tzi.uni-bremen.de Carsten Bormann cabo@tzi.uni-bremen.de. draft-kutscher-mmusic-sdpng-req-00.txt. http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/. Overview. Motivation (Terminology) General requirements

pello
Download Presentation

SDPng Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SDPng Requirements Dirk Kutscher dku@tzi.uni-bremen.de Jörg Ott jo@tzi.uni-bremen.de Carsten Bormann cabo@tzi.uni-bremen.de draft-kutscher-mmusic-sdpng-req-00.txt http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ 48. IETF, Pittsburgh Kutscher/Ott/Bormann

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

  3. 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, … 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  4. 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  5. 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  6. 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  7. 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. 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  8. 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  9. Elements ofCapability 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  10. 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  11. 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 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  12. What next? • More requirements? • MEGACO • Specific link layers and protocols • Develop architecture • Session description • Capability negotiation • Decide on syntax 48. IETF, Pittsburgh Kutscher/Ott/Bormann

  13. http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/ 48. IETF, Pittsburgh Kutscher/Ott/Bormann

More Related