dean-chavez
Uploaded by
26 SLIDES
392 VUES
260LIKES

SDPng Update

DESCRIPTION

This document provides an overview of the updates to SDP-NG at IETF 53 in Minneapolis, addressing changes outlined in draft-ietf-mmusic-sdpng-04. Key topics include generic syntax mechanisms for reusing definitions, capability negotiation improvements, and proposed solutions for handling numerous configuration parameters in applications like video. The document discusses open issues, assumptions for implementation, and the integration of transport parameters, offering insights into negotiation procedures to optimize communication in multiparty scenarios.

1 / 26

Télécharger la présentation

SDPng Update

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 Update draft-ietf-mmusic-sdpng-04.txt Dirk Kutscher dku@tzi.org Jörg Ott jo@tzi.org Carsten Bormann cabo@tzi.org IETF 53, Minneapolis Kutscher/Ott/Bormann

  2. Overview • Changes in -04 • Open Issues • Next steps IETF 53, Minneapolis Kutscher/Ott/Bormann

  3. Changes in -04 • Generic syntax mechanisms for re-using definitions • sdpng:use for referencing named definitions • sdpng:group to name a group of definitions for later referencing • sdpng:prop to add properties to definitions • Capability negotiation IETF 53, Minneapolis Kutscher/Ott/Bormann

  4. Capability Negotiation • Offer/Answer: • Select one (or more) configuration alternatives from the set of offered configurations • Typically, the answerer matches offer against list of supported configurations • Problem: • Some applications (e.g., video) can require many configuration parameters • Representing each variant as an individual alternative not practical IETF 53, Minneapolis Kutscher/Ott/Bormann

  5. Capability Negotiation in SDPng • Language mechanisms to describe supported value ranges for configuration parameters • “For codec X, I can support frame rates 6,12,24 and codec options foo and bar” • Algorithms to compare and collapse two descriptions • Result: A commonly supported configuration (if it exists) IETF 53, Minneapolis Kutscher/Ott/Bormann

  6. Some Assumptions • This should be simple • Limited set of data types and collapsing rules • Usable for SIP, RTSP, SAP, MEGACO • Message size, implementation complexity • SIP: SDPng exchange in one offer/answer cycle • Extensible • No fixed identifiers • Collapsing is possible without knowing semantics of configuration descriptions • Can collapse without having to know schema definition etc. IETF 53, Minneapolis Kutscher/Ott/Bormann

  7. CAP(A) Conceptual Overview A determines potential configurationsand generates CAP(A) A B CAP(A) IETF 53, Minneapolis Kutscher/Ott/Bormann

  8. CAP(A) CAP(B) B generates CAP(B), according to the set of components from A’s description that B wants to support. A B CAP(A) CAP(B) IETF 53, Minneapolis Kutscher/Ott/Bormann

  9. CAP(A) CAP(B) Both A and B can compute CAP(AB), the list of commonly supported potential configurations. A B CAP(A) CAP(B) CAP(AB) CAP(AB) IETF 53, Minneapolis Kutscher/Ott/Bormann

  10. CAP(A) CAP(B) A selects the actual configuration CFG(AB). A B CAP(A) CAP(B) CAP(AB) CAP(AB) CFG(AB) IETF 53, Minneapolis Kutscher/Ott/Bormann

  11. CFG_T(A) CAP(A) CAP(B) A augments CFG(AB) with A’s non-negotiable transport parameters and generates CFG_T(A). A B CAP(A) CAP(B) CAP(AB) CAP(AB) CFG(AB) CFG_T(A) IETF 53, Minneapolis Kutscher/Ott/Bormann

  12. CFG_T(A) CAP(A) CFG_T(AB) CAP(B) B receives CFG_T(A) and adds its own transport parameters, resulting in CFG_T(AB). A B CAP(A) CAP(B) CAP(AB) CAP(AB) CFG(AB) CFG_T(A) CFG_T(AB) CFG_T(AB) IETF 53, Minneapolis Kutscher/Ott/Bormann

  13. CAP(A) + CFG_T(A) Optimization A sends capabilities and transport parameters. A B CAP(A) CFG_T(A) CAP(B) CFG_T(A) IETF 53, Minneapolis Kutscher/Ott/Bormann

  14. CAP(A) + CFG_T(A) CFG_T(AB) B computes CAP(AB) and generates CFG_T(AB). A B CAP(A) CFG_T(A) CAP(B) CFG_T(A) CFG_T(AB) CFG_T(AB) IETF 53, Minneapolis Kutscher/Ott/Bormann

  15. Properties of the Negotiation Procedure • Integration of transport parameters in “offer” • Concept of non-negotiable parameters • “Context-free” processing • Process capability descriptions without knowing schema definition and semantics • Encode type info into parameters, infer collapsing rule IETF 53, Minneapolis Kutscher/Ott/Bormann

  16. Collapsing Example <x a="[BAR, 3, 5, 8]" b="(2,8)" c="foo"> <y b="[UVW, XYZ]"/> </x> A <x a="[3, 6, 8]" b="(5,10)" c="bar"> <y b="[RST, XYZ]"/> </x> B <x a="[3, 8]" b="(5,8)"> <y b="[XYZ]"/> </x> Result IETF 53, Minneapolis Kutscher/Ott/Bormann

  17. Data Types • Set of symbols • [FOO,4,5]  [BAR,3,4]  [4] • Collapsing rule: intersection • Numerical ranges • (3,10)  (5,12)  (5,10) • Collapsing rule: determine common range • Optional string parameters • “FOO”  “BAR”  “” • Collapsing rule: test for equality IETF 53, Minneapolis Kutscher/Ott/Bormann

  18. Open Issue #1: Global View • With SIP/SDP, we send participant-specific descriptions • Can lead to ambiguity (e.g., asymmetric configurations) • Global view: • Disambiguate all descriptions • Relate to participant • Participant-identifier? • Useful for multi-party scenarios • Adds some complexity IETF 53, Minneapolis Kutscher/Ott/Bormann

  19. Open Issue #2:External Definitions • External libraries • How useful are they in real life? • Resolving references to librariesat call-setup time… • Always include all definitions? IETF 53, Minneapolis Kutscher/Ott/Bormann

  20. Open Issue #3:Capability Negotiation • What functionality is really needed? • Current draft provides a simple, limited solution • Limited set of data types • Optimized, application specific processing rules • Other, more generic work exists • CC/PP, CONNEG etc. • How much re-use is useful? • Technical discussion required! IETF 53, Minneapolis Kutscher/Ott/Bormann

  21. Open Issue #4:Capability Negotiation • Semantics of descriptions and negotiation results • Multiple alternatives for a component • Select one? Support any? • Ranges for parameters in final descriptions • Are senders free to select values? • Do changes require signaling? • Non-negotiable parameters • Currently under-specified… IETF 53, Minneapolis Kutscher/Ott/Bormann

  22. Open Issue #5:Internal References • SPDng provides mechanisms to name definitions and re-use them • Compact definitions, grouping etc. • For capability negotiation, all references MUST be resolved • Collapsing process yields a new description instance • How to generate a compact description instance again? IETF 53, Minneapolis Kutscher/Ott/Bormann

  23. Open Issue #6: Profiles • Designing profiles • Current draft provides merely examples • Audio, RTP, UDP, IPv4 • Complete set of basic profiles for RTP/AVP required • Payload type assignment • Security: MIKEY in SDPng • QoS • Different types of QoS parameters IETF 53, Minneapolis Kutscher/Ott/Bormann

  24. Next Steps • Restructuring specification • Split document: • Framework document • General model, scenarios •  Informational? • SPDng spec. • Syntax, processing algorithms •  Standards track • Profiles • Some basic profiles covering RTP/AVP •  Standards track • Editorial changes required • Make examples consistent, fix bugs IETF 53, Minneapolis Kutscher/Ott/Bormann

  25. Next Steps • Complete list of open issues • Discuss (and resolve) on the mailing list • Work on profiles • Fix remaining issues IETF 53, Minneapolis Kutscher/Ott/Bormann

  26. SDPng implementation • C++ library • Works with expat (XML parser) • Any other event-based parser should be fine • Covers sdpng-03 • Newer stuff currently being implemented IETF 53, Minneapolis Kutscher/Ott/Bormann

More Related