Zum Hauptinhalt springen

RFC 4566 - SDP: Session Description Protocol

  • Status: Proposed Standard
  • Veröffentlicht: July 2006
  • Stream: IETF
  • Ersetzt: RFC2327, RFC3266
  • Ersetzt durch: RFC8866
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Memo definiert das Session Description Protocol (SDP, Sitzungsbeschreibungsprotokoll). SDP ist für die Beschreibung von Multimedia-Sitzungen zum Zweck der Sitzungsankündigung, Sitzungseinladung und anderer Formen der Multimedia-Sitzungsinitiierung vorgesehen.

Inhaltsverzeichnis (Contents)​

Verwandte Ressourcen​

2. Glossary of Terms (Glossar der Begriffe)​

Die folgenden Begriffe werden in diesem Dokument verwendet und haben im Kontext dieses Dokuments eine spezifische Bedeutung.

Conference (Konferenz): Eine Multimedia-Konferenz ist eine Menge von zwei oder mehr kommunizierenden Benutzern sowie der Software, die sie zur Kommunikation verwenden.

Session (Sitzung): Eine Multimedia-Sitzung ist eine Menge von Multimedia-Sendern und -Empfängern sowie der Datenströme, die von den Sendern zu den Empfängern fließen. Eine Multimedia-Konferenz ist ein Beispiel für eine Multimedia-Sitzung.

Session Description (Sitzungsbeschreibung): Ein wohldefinierteres Format zur Übermittlung ausreichender Informationen, um eine Multimedia-Sitzung zu entdecken und daran teilzunehmen.

Die Schlüsselwörter „MUSS" (MUST), „DARF NICHT" (MUST NOT), „ERFORDERLICH" (REQUIRED), „SOLL" (SHALL), „SOLL NICHT" (SHALL NOT), „SOLLTE" (SHOULD), „SOLLTE NICHT" (SHOULD NOT), „EMPFOHLEN" (RECOMMENDED), „KANN" (MAY) und „OPTIONAL" in diesem Dokument sind gemäß RFC 2119 [3] zu interpretieren.

3. Examples of SDP Usage (Beispiele zur SDP-Verwendung)​

3.1 Session Initiation (Sitzungsinitiierung)​

Das Session Initiation Protocol (SIP) [15] ist ein Anwendungsschicht-Steuerprotokoll zum Erstellen, Ändern und Beenden von Sitzungen wie Internet-Multimedia-Konferenzen, Internet-Telefonanrufen und Multimedia-Verteilung. SIP-Nachrichten zum Erstellen von Sitzungen enthalten Sitzungsbeschreibungen, die es den Teilnehmern ermöglichen, sich auf einen Satz kompatibler Medientypen zu einigen. Diese Sitzungsbeschreibungen werden häufig im SDP-Format kodiert. Bei der Verwendung mit SIP bietet das Angebot/Antwort-Modell (offer/answer model) [17] einen eingeschränkten Rahmen für die Aushandlung mit SDP.

3.2 Streaming Media (Streaming-Medien)​

Das Real Time Streaming Protocol (RTSP) [16] ist ein Protokoll auf Anwendungsebene zur Steuerung der Übertragung von Daten mit Echtzeiteigenschaften. RTSP bietet einen erweiterbaren Rahmen für die kontrollierte, bedarfsgesteuerte Übertragung von Echtzeitdaten wie Audio und Video. RTSP-Clients und -Server handeln einen geeigneten Satz von Medienübertragungsparametern aus, wobei teilweise SDP-Syntax zur Beschreibung dieser Parameter verwendet wird.

3.3 Email and the World Wide Web (E-Mail und das World Wide Web)​

Alternative Methoden zur Übermittlung von Sitzungsbeschreibungen umfassen E-Mail und das World Wide Web (WWW). Für die Verteilung per E-Mail und WWW wird der Medientyp „application/sdp" verwendet. Dies ermöglicht es Anwendungen, automatisch von einem WWW-Client oder einem E-Mail-Programm gestartet zu werden, um an einer Sitzung teilzunehmen.

Es ist zu beachten, dass Multicast-Sitzungsankündigungen, die ausschließlich per E-Mail oder WWW verbreitet werden, nicht die Eigenschaft haben, dass der Empfänger der Sitzungsankündigung die Sitzung notwendigerweise empfangen kann, da Multicast-Sitzungen in ihrem Geltungsbereich eingeschränkt sein können und der Zugriff auf den WWW-Server oder der Empfang von E-Mails außerhalb dieses Geltungsbereichs liegen kann.

3.4 Multicast Session Announcement (Multicast-Sitzungsankündigung)​

Zur Unterstützung der Ankündigung von Multicast-Multimedia-Konferenzen und anderen Multicast-Sitzungen sowie zur Übermittlung relevanter Sitzungseinrichtungsinformationen an potenzielle Teilnehmer kann ein verteiltes Sitzungsverzeichnis verwendet werden. Instanzen eines solchen Sitzungsverzeichnisses senden regelmäßig Pakete mit Sitzungsbeschreibungen an eine bekannte Multicast-Gruppe. Diese Ankündigungen werden von anderen Sitzungsverzeichnissen empfangen, sodass potenzielle entfernte Teilnehmer die Sitzungsbeschreibung verwenden können, um die zur Teilnahme an der Sitzung erforderlichen Werkzeuge zu starten.

Ein Protokoll zur Implementierung eines solchen verteilten Verzeichnisses ist das Session Announcement Protocol (SAP) [14]. SDP bietet das empfohlene Format für Sitzungsbeschreibungen bei solchen Sitzungsankündigungen.

4. Requirements and Recommendations (Anforderungen und Empfehlungen)​

Der Zweck von SDP besteht darin, Informationen über Medienströme in Multimedia-Sitzungen zu übermitteln, damit der Empfänger einer Sitzungsbeschreibung an der Sitzung teilnehmen kann. SDP ist hauptsächlich für den Einsatz in Internetworks gedacht, obwohl es allgemein genug ist, um Konferenzen in anderen Netzwerkumgebungen zu beschreiben. Medienströme können viele-zu-viele sein. Sitzungen müssen nicht dauerhaft aktiv sein.

Bisher unterscheiden sich internetbasierte Multicast-Sitzungen von vielen anderen Konferenzformen dadurch, dass jeder, der den Datenverkehr empfängt, der Sitzung beitreten kann (es sei denn, der Sitzungsverkehr ist verschlüsselt). In einer solchen Umgebung hat SDP zwei Hauptzwecke. Es ist ein Mittel zur Übermittlung der Existenz einer Sitzung und ein Mittel zur Übermittlung ausreichender Informationen, um das Beitreten und Teilnehmen an der Sitzung zu ermöglichen. In Unicast-Umgebungen ist möglicherweise nur der letztere Zweck relevant.

Eine SDP-Sitzungsbeschreibung enthält folgende Informationen:

  • Sitzungsname und -zweck
  • Zeitraum, in dem die Sitzung aktiv ist
  • Die Medien, aus denen die Sitzung besteht
  • Informationen zum Empfang dieser Medien (Adressen, Ports, Formate usw.)

Da die für die Teilnahme an einer Sitzung benötigten Ressourcen begrenzt sein können, können auch einige zusätzliche Informationen erforderlich sein:

  • Informationen über die von der Sitzung verwendete Bandbreite
  • Kontaktinformationen der für die Sitzung verantwortlichen Person

Im Allgemeinen MUSS SDP ausreichende Informationen übermitteln, damit Anwendungen einer Sitzung beitreten können (mit der möglichen Ausnahme von Verschlüsselungsschlüsseln), und alle Nicht-Teilnehmer, die es wissen müssen, über die zu verwendenden Ressourcen informieren. (Letzteres ist hauptsächlich nützlich, wenn SDP mit Multicast-Sitzungsankündigungsprotokollen verwendet wird.)

4.1 Media and Transport Information (Medien- und Transportinformationen)​

Eine SDP-Sitzungsbeschreibung enthält folgende Medieninformationen:

  • Medientyp (Video, Audio usw.)
  • Transportprotokoll (RTP/UDP/IP, H.320 usw.)
  • Medienformat (H.261-Video, MPEG-Video usw.)

Zusätzlich zu Medienformat und Transportprotokoll übermittelt SDP Adress- und Portdetails. Für IP-Multicast-Sitzungen umfassen diese:

  • Die Multicast-Gruppenadresse für die Medien
  • Den Transportport für die Medien

Diese Adresse und dieser Port sind die Zieladresse und der Zielport des Multicast-Stroms, unabhängig davon, ob gesendet, empfangen oder beides erfolgt.

Für Unicast-IP-Sitzungen wird Folgendes übermittelt:

  • Die Remote-Adresse für die Medien
  • Den Remote-Transportport für die Medien

Die Semantik dieser Adresse und dieses Ports hängt von den definierten Medien und dem Transportprotokoll ab. Standardmäßig SOLLTE dies die Remote-Adresse und der Remote-Port sein, an den Daten gesendet werden. Einige Medientypen können dieses Verhalten neu definieren, was jedoch NICHT EMPFOHLEN wird, da es die Implementierung erschwert (einschließlich Zwischengeräten, die Adressen analysieren müssen, um NAT- oder Firewall-Pinholes zu öffnen).

4.2 Timing Information (Zeitinformationen)​

Sitzungen können zeitlich begrenzt oder unbegrenzt sein. Unabhängig davon, ob sie begrenzt sind, können sie nur zu bestimmten Zeiten aktiv sein. SDP kann übermitteln:

  • Eine beliebige Liste von Start- und Stoppzeiten, die die Sitzung begrenzen
  • Für jede Begrenzung Wiederholungszeiten, z. B. „jeden Mittwoch um 10 Uhr für eine Stunde"

Diese Zeitinformationen sind global konsistent, unabhängig von lokalen Zeitzonen oder Sommerzeit (siehe Abschnitt 5.9).

4.3 Private Sessions (Private Sitzungen)​

Es können sowohl öffentliche als auch private Sitzungen erstellt werden. SDP selbst unterscheidet nicht zwischen diesen; private Sitzungen werden typischerweise durch Verschlüsselung der Sitzungsbeschreibung während der Verteilung übermittelt. Die Details der Verschlüsselung hängen vom Mechanismus ab, der zur Übertragung von SDP verwendet wird; derzeit sind Mechanismen für SDP definiert, das über SAP [14] und SIP [15] transportiert wird, und weitere können in Zukunft definiert werden.

Wenn die Sitzungsankündigung privat ist, kann diese private Ankündigung verwendet werden, um die Verschlüsselungsschlüssel zu übermitteln, die zum Dekodieren jedes Mediums in der Konferenz erforderlich sind, einschließlich ausreichender Informationen darüber, welches Verschlüsselungsschema für jedes Medium verwendet wird.

4.4 Obtaining Further Information about a Session (Weitere Informationen über eine Sitzung)​

Eine Sitzungsbeschreibung SOLLTE ausreichende Informationen übermitteln, um zu entscheiden, ob man an der Sitzung teilnehmen möchte. SDP kann zusätzliche Verweise auf weitere Informationen über die Sitzung in Form von Uniform Resource Identifiers (URIs) enthalten.

4.5 Categorisation (Kategorisierung)​

Wenn SAP oder ein anderer Ankündigungsmechanismus viele Sitzungsbeschreibungen verteilt, kann es notwendig sein, interessante Sitzungsankündigungen von uninteressanten zu filtern. SDP unterstützt Sitzungskategorisierungsmechanismen, die automatisiert werden können (das Attribut „a=cat:"; siehe Abschnitt 6).

4.6 Internationalisation (Internationalisierung)​

Die SDP-Spezifikation empfiehlt die Verwendung des ISO-10646-Zeichensatzes in UTF-8-Kodierung [5], um die Darstellung vieler verschiedener Sprachen zu ermöglichen. Um jedoch eine kompakte Darstellung zu unterstützen, erlaubt SDP auch die Verwendung anderer Zeichensätze wie ISO 8859-1, wenn dies erforderlich ist. Die Internationalisierung gilt nur für Freitextfelder (Sitzungsname und Hintergrundinformationen) und nicht für SDP als Ganzes.

5. SDP Specification (SDP-Spezifikation)​

Eine SDP-Sitzungsbeschreibung wird durch den Medientyp „application/sdp" dargestellt (siehe Abschnitt 8).

SDP-Sitzungsbeschreibungen sind vollständig in Textform unter Verwendung des ISO-10646-Zeichensatzes in UTF-8-Kodierung. SDP-Feldnamen und Attributnamen verwenden nur die US-ASCII-Teilmenge von UTF-8, aber Textfelder und Attributwerte KÖNNEN den vollständigen ISO-10646-Zeichensatz verwenden. Felder und Attributwerte, die den vollständigen UTF-8-Zeichensatz verwenden, werden niemals direkt verglichen, daher ist keine UTF-8-Normalisierung erforderlich. Die Wahl der Textform (anstelle einer binären Kodierung wie ASN.1 oder XDR) dient der Verbesserung der Portabilität, der Unterstützung verschiedener Transportmethoden und der Ermöglichung der Verwendung flexibler textbasierter Werkzeuge zur Erstellung und Verarbeitung von Sitzungsbeschreibungen.

SDP-Beschreibungsformat​

Eine SDP-Sitzungsbeschreibung besteht aus mehreren Textzeilen im Format:

<type>=<value>

Dabei MUSS <type> genau ein Zeichen sein, das zwischen Groß- und Kleinschreibung unterscheidet, und <value> ist strukturierter Text, dessen Format vom <type> abhängt.

SDP-Beschreibungsstruktur​

Eine SDP-Sitzungsbeschreibung besteht aus einem Sitzungsabschnitt und null oder mehr Medienabschnitten. Einige Zeilen in der Beschreibung sind ERFORDERLICH (REQUIRED), andere sind OPTIONAL, aber alle Zeilen MÜSSEN in der hier angegebenen Reihenfolge erscheinen. Optionale Elemente sind mit „*" gekennzeichnet.

Sitzungsbeschreibung (Session description):

  • v= (Protokollversion)
  • o= (Urheber und Sitzungskennung)
  • s= (Sitzungsname)
  • i=* (Sitzungsinformationen)
  • u=* (URI der Beschreibung)
  • e=* (E-Mail-Adresse)
  • p=* (Telefonnummer)
  • c=* (Verbindungsinformationen – nicht erforderlich, wenn in allen Medien enthalten)
  • b=* (null oder mehr Bandbreiteninformationszeilen)
  • Eine oder mehrere Zeitbeschreibungen (Zeilen „t=" und „r=")
  • z=* (Zeitzoneneinstellungen)
  • k=* (Verschlüsselungsschlüssel)
  • a=* (null oder mehr Sitzungsattributzeilen)
  • Null oder mehr Medienbeschreibungen

Zeitbeschreibung (Time description):

  • t= (Zeitraum, in dem die Sitzung aktiv ist)
  • r=* (null oder mehr Wiederholungszeiten)

Medienbeschreibung (Media description, falls vorhanden):

  • m= (Medienname und Transportadresse)
  • i=* (Medientitel)
  • c=* (Verbindungsinformationen – optional, wenn auf Sitzungsebene enthalten)
  • b=* (null oder mehr Bandbreiteninformationszeilen)
  • k=* (Verschlüsselungsschlüssel)
  • a=* (null oder mehr Medienattributzeilen)

SDP-Beispiel​

v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
[email protected] (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

Unterabschnitte​

5.1 Protocol Version ("v=") (Protokollversion)​

v=0

Das Feld „v=" gibt die Version des Sitzungsbeschreibungsprotokolls an. Dieses Memo definiert Version 0. Es gibt keine Nebenversion.

5.2 Origin ("o=") (Urheber)​

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Das Feld „o=" gibt den Urheber der Sitzung (seinen Benutzernamen und die Adresse des Benutzer-Hosts) sowie die Sitzungskennung und Versionsnummer an.

5.3 Session Name ("s=") (Sitzungsname)​

s=<session name>

Das Feld „s=" ist der Textsitzungsname. Jede Sitzungsbeschreibung MUSS genau ein Feld „s=" haben.

5.4 Session Information ("i=") (Sitzungsinformationen)​

i=<session description>

Das Feld „i=" liefert Textinformationen über die Sitzung. Jede Sitzungsbeschreibung kann höchstens ein Feld „i=" auf Sitzungsebene und jedes Medium kann höchstens ein Feld „i=" haben.

5.5 URI ("u=")​

u=<uri>

Das Feld „u=" enthält einen URI, der auf weitere Informationen über die Sitzung verweist.

5.6 Email Address and Phone Number ("e=" and "p=") (E-Mail-Adresse und Telefonnummer)​

e=<email-address>
p=<phone-number>

Das Feld „e=" enthält die E-Mail-Adresse der für die Konferenz verantwortlichen Person. Das Feld „p=" enthält die Telefonnummer der für die Konferenz verantwortlichen Person.

5.7 Connection Data ("c=") (Verbindungsdaten)​

c=<nettype> <addrtype> <connection-address>

Das Feld „c=" enthält die für die Verbindungsdaten erforderlichen Informationen.

5.8 Bandwidth ("b=") (Bandbreite)​

b=<bwtype>:<bandwidth>

Das Feld „b=" gibt die vorgeschlagene Sitzungsbandbreite an.

5.9 Timing ("t=") (Zeitangabe)​

t=<start-time> <stop-time>

Die Zeile „t=" gibt die Start- und Stoppzeiten der Sitzung an.

5.10 Repeat Times ("r=") (Wiederholungszeiten)​

r=<repeat interval> <active duration> <offsets from start-time>

Die Zeile „r=" gibt die Zeiten für wiederkehrende Sitzungen an.

5.11 Time Zones ("z=") (Zeitzonen)​

z=<adjustment time> <offset> <adjustment time> <offset> ...

Die Zeile „z=" gibt Zeitzoneneinstellungen an, die zur Kompensation von Sommerzeit oder anderen Zeitzonenverschiebungen verwendet werden.

5.12 Encryption Keys ("k=") (Verschlüsselungsschlüssel)​

k=<method>
k=<method>:<encryption key>

Das Feld „k=" dient zur Übermittlung von Verschlüsselungsschlüsseln.

5.13 Attributes ("a=") (Attribute)​

a=<attribute>
a=<attribute>:<value>

Attribute sind das wichtigste Mittel zur Erweiterung von SDP. Attribute können auf Sitzungs- oder Medienebene definiert werden.

5.14 Media Descriptions ("m=") (Medienbeschreibungen)​

m=<media> <port> <proto> <fmt> ...

Eine Medienbeschreibung beginnt mit einer Zeile „m=" und enthält ausreichende Informationen zur Beschreibung eines Medienstroms.

Hinweis: Abschnitt 5 enthält umfangreiche technische Details und ABNF-Syntaxdefinitionen. Die vollständige Spezifikation ist in der offiziellen RFC-4566-Dokumentation zu finden.

6. SDP Attributes (SDP-Attribute)​

Attribute (Attributes) sind das wichtigste Mittel zur Erweiterung von SDP. Sie können auf Sitzungs- oder Medienebene definiert werden. Attribute auf Sitzungsebene gelten für die gesamte Sitzung (sofern sie nicht durch Attribute auf Medienebene überschrieben werden), Attribute auf Medienebene gelten nur für den jeweiligen Medienstrom.

Das Format einer Attributzeile lautet:

a=<attribute>
a=<attribute>:<value>

Liste der Standardattribute​

Im Folgenden sind die von dieser Spezifikation definierten Standard-SDP-Attribute aufgeführt:

cat (Category) (Kategorie)​

a=cat:<category>

Dient zur Kategorisierung der Sitzung, um das Filtern und Suchen zu erleichtern.

keywds (Keywords) (Schlüsselwörter)​

a=keywds:<keywords>

Liefert eine Liste von Schlüsselwörtern zur Sitzung.

tool (Tool) (Werkzeug)​

a=tool:<name and version of tool>

Identifiziert das Softwarewerkzeug, das die Sitzungsbeschreibung erstellt hat.

ptime (Packet Time) (Paketzeit)​

a=ptime:<packet time>

Gibt die Dauer der Medien in jedem Paket in Millisekunden an.

maxptime (Maximum Packet Time) (Maximale Paketzeit)​

a=maxptime:<maximum packet time>

Gibt die maximale Dauer der Medien in einem Paket in Millisekunden an.

rtpmap (RTP Mapping) (RTP-Zuordnung)​

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

Ordnet einen RTP-Nutzlasttyp einem Medien-Kodierungsnamen zu.

recvonly (Receive Only) (Nur Empfangen)​

a=recvonly

Gibt an, dass das Werkzeug nur Medien empfangen, aber nicht senden kann.

sendrecv (Send and Receive) (Senden und Empfangen)​

a=sendrecv

Gibt an, dass das Werkzeug sowohl Medien senden als auch empfangen kann (dies ist der Standardwert).

sendonly (Send Only) (Nur Senden)​

a=sendonly

Gibt an, dass das Werkzeug nur Medien senden, aber nicht empfangen kann.

inactive (Inactive) (Inaktiv)​

a=inactive

Gibt an, dass der Medienstrom derzeit inaktiv ist.

orient (Orientation) (Ausrichtung)​

a=orient:<whiteboard orientation>

Wird für Whiteboard-Medientypen verwendet und gibt die Ausrichtung des Whiteboards an.

type (Conference Type) (Konferenztyp)​

a=type:<conference type>

Gibt den Konferenztyp an (z. B. „broadcast", „meeting", „moderated", „test", „H332").

charset (Character Set) (Zeichensatz)​

a=charset:<character set>

Gibt den Zeichensatz an, der für Textfelder in der Sitzungsbeschreibung verwendet wird.

sdplang (SDP Language) (SDP-Sprache)​

a=sdplang:<language tag>

Gibt die Sprache an, in der die Sitzungsbeschreibung verfasst ist.

lang (Language) (Sprache)​

a=lang:<language tag>

Gibt die Sprache des Medienstroms an.

framerate (Frame Rate) (Bildrate)​

a=framerate:<frame rate>

Gibt die Bildrate des Videos in Bildern pro Sekunde an.

quality (Quality) (Qualität)​

a=quality:<quality>

Gibt einen empfohlenen Wert für die Kodierungsqualität an.

fmtp (Format Parameters) (Formatparameter)​

a=fmtp:<format> <format specific parameters>

Dient zur Angabe formatspezifischer Parameter.

Hinweis: Dieses Kapitel listet die Kernattribute von SDP auf. Einzelne Medientypen und Anwendungen können zusätzliche Attribute definieren. Die vollständige Attributliste und detaillierte Beschreibungen sind in der offiziellen RFC-4566-Dokumentation, Abschnitt 6, zu finden.

7. Security Considerations (Sicherheitsüberlegungen)​

SDP-Sitzungsbeschreibungen stellen selbst kein Transportprotokoll dar und MÜSSEN zusammen mit einem Transportprotokoll verwendet werden, um die Sitzungsbeschreibung an die Teilnehmer zu übermitteln. Dieser Abschnitt behandelt Sicherheitsüberlegungen bei der Verwendung von SDP.

Vertraulichkeit (Confidentiality)​

Sitzungsbeschreibungen können sensible Informationen enthalten, darunter:

  • Identitätsinformationen der Teilnehmer
  • Kontaktinformationen (E-Mail, Telefonnummern)
  • Verschlüsselungsschlüssel
  • Netzwerktopologieinformationen (IP-Adressen, Ports)
  • Sitzungszeiten und -themen

Es wird empfohlen, geeignete Verschlüsselungsmechanismen (wie TLS, S/MIME) zu verwenden, um die Vertraulichkeit der Sitzungsbeschreibung während der Übertragung zu schützen.

Integrität und Authentizität (Integrity and Authenticity)​

Sitzungsbeschreibungen MÜSSEN vor unbefugter Änderung geschützt werden. Ein Angreifer könnte durch Änderung der Sitzungsbeschreibung:

  • Medienströme auf bösartige Server umleiten
  • Bösartige Attribute einschleusen
  • Verschlüsselungsschlüssel ändern
  • Sitzungszeiten verändern

Es wird empfohlen, digitale Signaturen oder Message Authentication Codes (MAC) zu verwenden, um die Integrität und Authentizität der Sitzungsbeschreibung zu überprüfen.

Denial of Service (Denial-of-Service)​

Angreifer könnten Sitzungsbeschreibungen für Denial-of-Service-Angriffe missbrauchen:

  • Versenden einer großen Anzahl gefälschter Sitzungsankündigungen
  • Erstellen sehr großer Sitzungsbeschreibungen, die Parser-Ressourcen erschöpfen
  • Verweisen auf nicht existierende Adressen, um Netzwerkressourcen zu verbrauchen

Implementierungen SOLLTEN die Größe und Komplexität von Sitzungsbeschreibungen begrenzen und Parsing-Fehler angemessen behandeln.

Encryption Key Distribution (Verteilung von Verschlüsselungsschlüsseln)​

Obwohl SDP einen Mechanismus zur Übermittlung von Verschlüsselungsschlüsseln bereitstellt (das Feld „k="), kann die Übertragung von Schlüsseln über Sitzungsbeschreibungen in vielen Fällen unsicher sein. Es wird empfohlen, dedizierte Schlüsselverwaltungsprotokolle (wie MIKEY, ZRTP) oder Out-of-Band-Schlüsselaustauschverfahren zu verwenden.

Privacy Considerations (Datenschutzüberlegungen)​

Das Feld „o=" enthält den Benutzernamen und die IP-Adresse des Sitzungserstellers, was private Informationen preisgeben kann. In Szenarien, in denen Datenschutz erforderlich ist, können ein beliebiger Benutzername und eine private Adresse verwendet werden, sofern die globale Eindeutigkeit des Feldes nicht beeinträchtigt wird.

Network Address Translation (NAT) und Firewalls​

Die in SDP enthaltenen IP-Adressen und Portinformationen können beim Durchlaufen von NAT oder Firewalls ungültig werden. Anwendungen SOLLTEN Mechanismen wie Interactive Connectivity Establishment (ICE) verwenden, um mit diesen Situationen umzugehen.

8. IANA Considerations (IANA-Überlegungen)​

Dieser Abschnitt beschreibt die IANA-Registrierungsanforderungen für die verschiedenen von SDP verwendeten Parameter.

8.1 The "application/sdp" Media Type (Der Medientyp „application/sdp")​

SDP-Sitzungsbeschreibungen verwenden den Medientyp „application/sdp".

Medientypname: application
Medienuntertypname: sdp
Erforderliche Parameter: keine
Optionale Parameter: keine
Kodierungsüberlegungen: SDP-Dateien sind Textdateien, die den ISO-10646-Zeichensatz in UTF-8-Kodierung verwenden.
Sicherheitsüberlegungen: Siehe Abschnitt 7 von RFC 4566
Interoperabilitätsüberlegungen: Siehe RFC 4566
Veröffentlichte Spezifikation: RFC 4566
Anwendungen, die diesen Medientyp verwenden: Werkzeuge zur Einrichtung und Ankündigung von Multimedia-Sitzungen
Zusätzliche Informationen:

  • Dateiendung: .sdp
  • Macintosh-Dateitypcode: 'sdp '

8.2 Registration of Parameters (Registrierung von Parametern)​

SDP verwendet verschiedene Parametertypen, die von der IANA registriert werden können.

8.2.1 Media Types ("media") (Medientypen)​

Von SDP verwendete Medientypnamen SOLLTEN bei der IANA registriert werden. Zu den initial registrierten Medientypen gehören:

  • audio (Audio)
  • video (Video)
  • text (Text)
  • application (Anwendung)
  • message (Nachricht)

Neue Medientypen können über den IETF-Standardprozess oder durch Expertenbegutachtung registriert werden.

8.2.2 Transport Protocols ("proto") (Transportprotokolle)​

Zu den initial registrierten Transportprotokollen gehören:

  • RTP/AVP (RTP Audio/Video Profile)
  • RTP/SAVP (RTP Secure Audio/Video Profile)
  • UDP (User Datagram Protocol)

Neue Transportprotokolle können über den IETF-Standardprozess oder durch Expertenbegutachtung registriert werden.

8.2.3 Media Formats ("fmt") (Medienformate)​

Die Registrierung von Medienformaten (z. B. RTP-Nutzlasttypen) folgt den in RFC 3555 definierten Verfahren.

8.2.4 Attribute Names ("att-field") (Attributnamen)​

SDP-Attributnamen werden bei der IANA registriert. Die Registrierung neuer Attribute SOLLTE Folgendes umfassen:

  • Attributname
  • Typ (Sitzungsebene, Medienebene oder beides)
  • Wert (falls vorhanden)
  • Verwendungszweck und Semantik
  • Referenzspezifikation

Die Attributregistrierung erfolgt durch Expertenbegutachtung oder ein von der IESG genehmigtes Registrierungsverfahren.

8.2.5 Bandwidth Specifiers ("bwtype") (Bandbreitenbezeichner)​

Zu den initial registrierten Bandbreitenbezeichnern gehören:

  • CT (Conference Total, Gesamtbandbreite der Konferenz)
  • AS (Application Specific, anwendungsspezifische Bandbreite)

Neue Bandbreitenbezeichner können über den IETF-Standardprozess oder durch Expertenbegutachtung registriert werden.

8.2.6 Network Types ("nettype") (Netzwerktypen)​

Zu den initial registrierten Netzwerktypen gehören:

  • IN (Internet)

Neue Netzwerktypen können über den IETF-Standardprozess registriert werden.

8.2.7 Address Types ("addrtype") (Adresstypen)​

Zu den initial registrierten Adresstypen gehören:

  • IP4 (IPv4-Adresse)
  • IP6 (IPv6-Adresse)

Neue Adresstypen können über den IETF-Standardprozess registriert werden.

8.2.8 Registration Procedure (Registrierungsverfahren)​

Sofern nicht anders angegeben, verwenden alle in diesem Abschnitt beschriebenen Parameterregistrierungen eines der folgenden Verfahren:

  • Standards Action (Standardmaßnahme): Erfordert einen IETF-RFC
  • Expert Review (Expertenbegutachtung): Erfordert die Überprüfung durch einen benannten Experten
  • IESG Approval (IESG-Genehmigung): Erfordert die ausdrückliche Genehmigung der IESG

8.3 Encryption Key Access Methods (Zugriffsmethoden für Verschlüsselungsschlüssel)​

Die vom Feld „k=" verwendeten Zugriffsmethoden für Verschlüsselungsschlüssel SOLLTEN bei der IANA registriert werden. Zu den initial registrierten Methoden gehören:

  • clear (Klartext-Schlüssel)
  • base64 (Base64-kodierter Schlüssel)
  • uri (Schlüssel wird über URI abgerufen)
  • prompt (Benutzer wird zur Eingabe des Schlüssels aufgefordert)

Neue Schlüsselzugriffsmethoden können durch Expertenbegutachtung registriert werden.

10. Summary of Changes from RFC 2327 (Zusammenfassung der Änderungen gegenüber RFC 2327)​

RFC 4566 ersetzt RFC 2327 und RFC 3266. Dieser Abschnitt gibt einen Überblick über die wichtigsten Änderungen gegenüber RFC 2327.

Wesentliche Änderungen​

Normative Referenzen​

  • Aktualisierung der Verweise auf andere RFCs unter Verwendung aktueller normativer Dokumente
  • Hinzufügung eines Verweises auf RFC 3986 (URI-Syntax)

Internationalisierte Domänennamen (IDN)​

  • Explizite Anforderung, dass internationalisierte Domänennamen in ASCII-kompatibler Kodierung (ACE) angegeben werden MÜSSEN
  • Verbot der direkten Verwendung von UTF-8 oder anderen Kodierungen für IDN in SDP

Medientypregistrierung​

  • Aktualisierung der Registrierungsinformationen für den Medientyp „application/sdp"
  • Klarstellung der Kodierungs- und Sicherheitsüberlegungen

ABNF-Grammatik​

  • Aktualisierung der ABNF-Grammatik zur Widerspiegelung aktueller Praxis
  • Korrektur kleinerer Fehler in einigen Grammatikregeln
  • Verwendung der ABNF-Notation aus RFC 4234 (jetzt RFC 5234)

Sicherheitsüberlegungen​

  • Erweiterung des Abschnitts zu Sicherheitsüberlegungen
  • Hinzufügung einer Diskussion über NAT-Traversal und Firewalls
  • Betonung der Sicherheitsprobleme bei der Verteilung von Verschlüsselungsschlüsseln

IANA-Überlegungen​

  • Aktualisierung der Parameterregistrierungsverfahren
  • Klarstellung der Registrierungsanforderungen für verschiedene SDP-Parameter
  • Hinzufügung neuer Registrierungskategorien

Attributdefinitionen​

  • Klärung der Semantik bestimmter Attribute
  • Aktualisierung der Verwendungsbeispiele für Attribute

Verbindungsadresse​

  • Klärung der Verwendung der Verbindungsadresse in der Zeile „c="
  • Klarstellung der Darstellung von IPv4- und IPv6-Adressen

Zeitbeschreibung​

  • Klärung der Semantik der Zeitfelder
  • Aktualisierung der Hinweise zur Verwendung von NTP-Zeitstempeln

Redaktionelle Änderungen​

  • Verbesserung der Dokumentstruktur und Lesbarkeit
  • Aktualisierung der Beispiele zur Widerspiegelung aktueller Praxis
  • Korrektur von Rechtschreib- und Grammatikfehlern
  • Vereinheitlichung der Terminologie

Abwärtskompatibilität​

RFC 4566 wahrt die Abwärtskompatibilität mit RFC 2327. Implementierungen, die RFC 2327 entsprechen, sollten in der Lage sein, Sitzungsbeschreibungen zu verarbeiten, die RFC 4566 entsprechen, und umgekehrt.

Hinweis: Die detaillierte Änderungsliste und technische Erläuterungen sind in der offiziellen RFC-4566-Dokumentation, Abschnitt 10, zu finden.

11. Acknowledgements (Danksagungen)​

Die Entwicklung von SDP profitierte von den Beiträgen zahlreicher Mitglieder der Multicast Backbone (MBONE)-Gemeinschaft. Besonderer Dank gilt Eve Schooler, Steve Casner, Bill Fenner, Ron Frederick, Allison Mankin, Scott Shenker, Henning Schulzrinne und vielen anderen für ihre Kommentare und Vorschläge zu früheren Versionen von SDP.

Wir danken allen Mitgliedern der MMUSIC-Arbeitsgruppe für ihre Überprüfungen und Kommentare zu den verschiedenen Versionen dieses Dokuments.

Besonderer Dank gilt den folgenden Personen für ihre Beiträge und Kommentare zu RFC 4566:

  • Dave Singer
  • Joerg Ott
  • Jonathan Rosenberg
  • Magnus Westerlund
  • sowie allen Mitgliedern der IETF-Gemeinschaft, die Rückmeldungen gegeben haben

Die vollständige Danksagungsliste ist in der offiziellen RFC-4566-Dokumentation, Abschnitt 11, zu finden.