sdpng update n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
SDPng Update PowerPoint Presentation
Download Presentation
SDPng Update

Loading in 2 Seconds...

play fullscreen
1 / 26

SDPng Update - PowerPoint PPT Presentation


  • 103 Views
  • Uploaded on

SDPng Update. draft-ietf-mmusic-sdpng-04.txt. Dirk Kutscher dku@tzi.org Jörg Ott jo@tzi.org Carsten Bormann cabo@tzi.org. Overview. Changes in -04 Open Issues Next steps. Changes in -04. Generic syntax mechanisms for re-using definitions sdpng:use for referencing named definitions

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'SDPng Update' - dean-chavez


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
sdpng update

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

overview
Overview
  • Changes in -04
  • Open Issues
  • Next steps

IETF 53, Minneapolis

Kutscher/Ott/Bormann

changes in 04
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

capability negotiation
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

capability negotiation in sdpng
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

some assumptions
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

conceptual overview

CAP(A)

Conceptual Overview

A determines potential configurationsand generates CAP(A)

A

B

CAP(A)

IETF 53, Minneapolis

Kutscher/Ott/Bormann

slide8

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

slide9

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

slide10

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

slide11

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

slide12

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

optimization

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

slide14

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

properties of the negotiation procedure
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

collapsing example
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

data types
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

open issue 1 global view
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

open issue 2 external definitions
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

open issue 3 capability negotiation
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

open issue 4 capability negotiation
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

open issue 5 internal references
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

open issue 6 profiles
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

next steps
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

next steps1
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

sdpng implementation
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