3. SDP-Definitionen

3.1. Profil-Definition

Die in RFC 3551 [2], RFC 4585 [3] und RFC 3711 [4] definierten AV-Profile werden im Kontext von z. B. dem Session Description Protocol (SDP) [3] als "AVP", "AVPF" bzw. "SAVP" bezeichnet. Das in diesem Dokument spezifizierte kombinierte Profil wird als "SAVPF" bezeichnet.

3.2. Attribut-Definitionen

SDP-Attribute für die Aushandlung von SAVP-Sitzungen sind in RFC 4567 [7] und RFC 4568 [8] definiert. Diese Attribute KÖNNEN auch mit SAVPF verwendet werden. Es gelten die in [7] und [8] definierten Regeln.

SDP-Attribute für die Aushandlung von AVPF-Sitzungen sind in RFC 4585 [3] definiert. Diese Attribute KÖNNEN auch mit SAVPF verwendet werden. Es gelten die in [3] definierten Regeln.

3.3. Profil-Aushandlung

Sitzungsbeschreibungen für RTP-Sitzungen können mit Protokollen übermittelt werden, die für Multimedia-Kommunikation bestimmt sind, wie z. B. dem SDP-Offer/Answer-Modell (RFC 3264, [9]), das mit dem Session Initiation Protocol (SIP) [15], dem Real Time Streaming Protocol (RTSP) [10] oder dem Session Announcement Protocol (SAP) [11] verwendet wird, können aber auch über E-Mail, NetNews, Webseiten usw. verbreitet werden.

Das Offer/Answer-Modell ermöglicht die Aushandlung der resultierenden Sitzungsparameter unter Verwendung der in RFC 4567 [7] und RFC 4568 [8] definierten SDP-Attribute. Im folgenden Unterabschnitt wird der Aushandlungsprozess im Hinblick auf das Offer/Answer-Modell beschrieben.

Anschließend werden die Fälle behandelt, die das Offer/Answer-Modell nicht verwenden: RTSP-spezifische Aushandlungsunterstützung wird durch RFC 4567 [7] bereitgestellt, wie in Abschnitt 3.3.2 erörtert, und Unterstützung für SAP-Ankündigungen (ohne jegliche Aushandlung) wird in Abschnitt 3.3.3 behandelt.

3.3.1. Offer/Answer-basierte Aushandlung von Sitzungsbeschreibungen

Aushandlungen (z. B. von RTP-Profilen, Codecs, Transportadressen usw.) werden auf einer Basis pro Mediensitzung durchgeführt (z. B. pro m=-Zeile in SDP). Wenn die Aushandlung einer Mediensitzung fehlschlägt, KÖNNEN andere dennoch erfolgreich sein.

In verschiedenen Mediensitzungen KÖNNEN unterschiedliche RTP-Profile verwendet werden. Für die Aushandlung einer Medienbeschreibung schließen sich die vier Profile AVP, AVPF, SAVP und SAVPF gegenseitig aus. Beachten Sie jedoch, dass SAVP- und SAVPF-Entitäten in einer einzigen RTP-Sitzung gemischt werden KÖNNEN (siehe Abschnitt 4). Außerdem KANN der Offer/Answer-Mechanismus verwendet werden, um Alternativen für dieselbe Mediensitzung anzubieten und dem Beantworter die Wahl eines der Profile zu ermöglichen.

Vorausgesetzt, dass ein Mechanismus zum Anbieten alternativer Sicherheitsprofile verfügbar wird (wie er derzeit entwickelt wird [14]), SOLLTE ein Anbieter, der in der Lage ist, mehr als eines dieser Profile für eine bestimmte Mediensitzung zu unterstützen, immer alle in einer bestimmten Situation akzeptablen Alternativen anbieten. Die Alternativen SOLLTEN in der Reihenfolge ihrer Präferenz aufgeführt werden, und der Anbieter SOLLTE sichere Profile gegenüber nicht sicheren bevorzugen. Das Angebot SOLLTE NICHT sowohl eine sichere Alternative (SAVP und SAVPF) als auch eine unsichere Alternative (z. B. AVP und AVPF) im selben Angebot enthalten, da dies Bidding-Down- und andere Angriffe ermöglichen kann. Wenn daher sowohl sichere als auch nicht sichere RTP-Profile angeboten werden (z. B. für Best-Effort-SRTP [14]), MUSS die Aushandlungssignalisierung angemessen geschützt werden, um solche Angriffe zu vermeiden.

Wenn ein Angebot mehrere alternative Profile enthält, SOLLTE der Beantworter ein sicheres Profil (falls unterstützt) gegenüber nicht sicheren bevorzugen. Unter den sicheren oder unsicheren Profilen SOLLTE der Beantworter die erste akzeptable Alternative auswählen, um die Präferenz des Anbieters zu respektieren.

Wenn eine Medienbeschreibung in einem Angebot SAVPF verwendet und der Beantworter SAVPF nicht unterstützt, MUSS die Mediensitzung abgelehnt werden.

Wenn eine Medienbeschreibung in einem Angebot SAVPF nicht verwendet, der Beantworter aber SAVPF verwenden möchte, MUSS der Beantworter die Mediensitzung ablehnen. Der Beantworter KANN ein Gegenangebot mit einer Medienbeschreibung abgeben, die SAVPF in einem anschließend eingeleiteten Offer/Answer-Austausch angibt.

3.3.2. RTSP-basierte Aushandlung von Sitzungsbeschreibungen

RTSP [10] unterstützt das Offer/Answer-Modell nicht. RTSP unterstützt jedoch den Austausch von Mediensitzungsparametern (einschließlich Profil- und Adressinformationen) mittels des Transport-Headers. Das SDP-basierte Schlüsselmanagement, wie in RFC 4567 [7] definiert, fügt einen RTSP-Header (KeyMgmt) hinzu, um die Übermittlung eines Schlüsselmanagementprotokolls (einschließlich Schlüsselmaterial) zu unterstützen.

Der RTSP-Transport-Header KANN verwendet werden, um das Profil für die Mediensitzung zu bestimmen. Konzeptionell gelten die in Abschnitt 3.3.1 definierten Regeln entsprechend. Der detaillierte Betrieb ist wie folgt: Eine SDP-Beschreibung (z. B. vom RTSP-Server mittels DESCRIBE abgerufen) enthält die Beschreibung der Medienströme der jeweiligen RTSP-Ressource.

Der RTSP-Client MUSS genau eines der Profile pro Medienstrom auswählen, den er empfangen möchte. Er MUSS dies in der SETUP-Anfrage tun. Der RTSP-Client MUSS das gewählte RTP-Profil angeben, indem er das Profil und die vollständige Server-Transportadresse (IP-Adresse und Portnummer) im in der SETUP-Anfrage enthaltenen Transport-Header angibt. Die Antwort des RTSP-Servers auf die SETUP-Nachricht des Clients MUSS diese Profilauswahl bestätigen oder die SETUP-Anfrage ablehnen (letzteres sollte er nicht tun, nachdem er die Profile überhaupt erst angeboten hat).

Hinweis: Um eines der verwendeten Profile zu ändern, muss der Client diesen Medienstrom (und möglicherweise die gesamte RTSP-Sitzung) mit der TEARDOWN-Methode abbauen und mit SETUP neu aufbauen. Dies kann sich ändern, sobald die Medienaktualisierung (ähnlich einem SIP UPDATE oder re-INVITE) spezifiziert wird.

Bei Verwendung des SDP-Schlüsselmanagements [7] MUSS der KeyMgmt-Header in die entsprechenden RTSP-Nachrichten aufgenommen werden, wenn ein sicheres Profil gewählt wird. Wenn in der SDP-Beschreibung verschiedene sichere Profile angeboten werden (z. B. SAVP und SAVPF) und für diese unterschiedliches Schlüsselmaterial bereitgestellt wird, MUSS nach der Auswahl eines Profils in der SETUP-Nachricht nur der KeyMgmt-Header für das gewählte Profil bereitgestellt werden. Es gelten die Regeln für das Abgleichen von KeyMgmt-Headern mit Medienströmen gemäß RFC 4567 [7].

3.3.3. Ankündigung von Sitzungsbeschreibungen

Protokolle, die die interaktive Aushandlung von Sitzungsbeschreibungen nicht zulassen (z. B. SAP [11], Beschreibungen, die auf einer Webseite veröffentlicht oder per E-Mail gesendet werden), übertragen die Verantwortung für den angemessenen Zugriff auf die Mediensitzungen dem Initiator einer Sitzung.

Der Initiator SOLLTE alternative Sitzungsbeschreibungen für mehrere RTP-Profile bereitstellen, soweit dies für die Anwendung und den Zweck der Sitzung akzeptabel ist. Wenn Sicherheit erwünscht ist, kann SAVP als Alternative zu SAVPF angeboten werden – aber AVP- oder AVPF-Sitzungen SOLLTEN NICHT angekündigt werden, es sei denn, es werden andere Sicherheitsmittel eingesetzt, die nicht auf SRTP beruhen.

Die in RFC 4567 [7] und RFC 4568 [8] definierten SDP-Attribute können auch für die Verteilung von Sicherheitsparametern angekündigter Sitzungsbeschreibungen verwendet werden.

Die in RFC 4568 [8] definierte Beschreibung des Sicherheitsschemas erfordert einen sicheren Kommunikationskanal, um Dritte am Abhören der Schlüsselparameter und an Manipulationen zu hindern. Daher SOLLTEN SAP-Sicherheit (wie in RFC 2974 [11] definiert), S/MIME [12], HTTPS [13] oder andere geeignete Mechanismen für die Verteilung oder den Zugriff auf diese Sitzungsbeschreibungen verwendet werden.

3.3.4. Beschreibung alternativer Sitzungsprofile

SAVP- und SAVPF-Entitäten KÖNNEN in derselben RTP-Sitzung gemischt werden (siehe auch Abschnitt 4), ebenso wie AVP- und AVPF-Entitäten. Andere Kombinationen – d. h. zwischen sicheren und unsicheren Profilen – in derselben RTP-Sitzung sind inkompatibel und DÜRFEN NICHT zusammen verwendet werden.

Wenn eine Aushandlung zwischen den beteiligten Peers möglich ist (wie beim Offer/Answer-Modell gemäß Abschnitt 3.3.1 oder RTSP gemäß Abschnitt 3.3.2), KÖNNEN alternative (sichere und nicht sichere) Profile von einer Entität (z. B. dem Anbieter) spezifiziert werden, und eine Wahl eines Profils MUSS von der anderen getroffen werden. Wenn keine solche Aushandlung möglich ist (z. B. mit SAP gemäß Abschnitt 3.3.3), DÜRFEN inkompatible Profile NICHT als Alternativen spezifiziert werden.

Die Aushandlung alternativer Profile ist Gegenstand weiterer Untersuchungen.

RTP-Profile KÖNNEN über verschiedene RTP-Sitzungen hinweg beliebig gemischt werden.

3.4. Beispiele

Dieser Abschnitt enthält Beispiele für die Verwendung von SDP zur Aushandlung der Verwendung sicherer und unsicherer Profile. Je nachdem, welcher Schlüsselmechanismus verwendet wird und wie er parametrisiert ist, erfordern die SDP-Nachrichten in der Regel einen Integritätsschutz und für einige Mechanismen auch einen Vertraulichkeitsschutz. Beispielsweise könnte man sagen, dass Integritätsschutz für den a=fingerprint von Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16] erforderlich ist und Vertraulichkeitsschutz für RFC 4568 [8] (Security Descriptions) a=crypto.

Beispiel 1: Die folgende Sitzungsbeschreibung zeigt eine sichere Sitzung, die aus Audio und Dual-Tone Multi-Frequency (DTMF) für die Punkt-zu-Punkt-Kommunikation besteht, bei der der DTMF-Stream generische NACKs verwendet. Das angegebene Schlüsselmanagementprotokoll ist MIKEY. Diese Sitzungsbeschreibung (das Angebot) könnte in einer SIP INVITE- oder 200 OK-Nachricht enthalten sein, um anzuzeigen, dass der Absender in der Lage und bereit ist, Feedback für den von ihm übertragenen DTMF-Stream zu empfangen. Die entsprechende Antwort kann in einer 200 OK oder einem ACK übermittelt werden. Die Parameter für das Sicherheitsprotokoll werden wie in den in RFC 4567 [7] definierten SDP-Erweiterungen beschrieben ausgehandelt.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

Beispiel 2: Dieses Beispiel zeigt dieselben Feedback-Parameter wie Beispiel 1, verwendet jedoch die Syntax für sichere Beschreibungen [8]. Beachten Sie, dass der Schlüsselteil des a=crypto-Attributs nicht gegen Abhören geschützt ist und die Sitzungsbeschreibung daher über einen sicheren Kommunikationskanal ausgetauscht werden muss.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
  inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
  :32

Beispiel 3: Dieses Beispiel ist eine Replikation des obigen Beispiels 1, zeigt jedoch die Interaktion zwischen dem Anbieter und dem Beantworter in einem Offer/Answer-Austausch, wobei erneut MIKEY zur Aushandlung des Schlüsselmaterials verwendet wird:

Angebot:

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Antwort:

v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Beispiel 4: Dieses Beispiel zeigt den Austausch für Video-Streaming, das über RTSP gesteuert wird. Ein Client erwirbt eine Medienbeschreibung von einem Server mittels DESCRIBE und erhält eine statische SDP-Beschreibung ohne Schlüsselparameter, aber die Medienbeschreibung zeigt, dass sowohl sichere als auch unsichere Mediensitzungen unter Verwendung von (S)AVPF verfügbar sind. Ein Mechanismus, der eine explizite Identifizierung dieser Alternativen (d. h. sichere und unsichere Sitzungen) in der Sitzungsbeschreibung ermöglicht, wird derzeit definiert [14]. Der Client sendet dann eine SETUP-Anfrage und gibt seine Wahl an, indem er das jeweilige Profil im Transport-Parameter angibt. Darüber hinaus fügt der Client einen KeyMgmt-Header ein, um seine Sicherheitsparameter zu übermitteln, was durch einen entsprechenden KeyMgmt-Header vom Server in der Antwort bestätigt wird. Es wird nur eine einzige Mediensitzung ausgewählt, so dass der aggregierte RTSP-URI zur Identifizierung ausreicht.

RTSP DESCRIBE Anfrage-Antwort-Paar (optional):

DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp

200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316

v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
m=video 49170 RTP/SAVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack
m=video 49172 RTP/AVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack

RTSP SETUP Anfrage-Antwort-Paar

SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."

200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
           src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE

Beispiel 5: Die folgende Sitzungsbeschreibung zeigt eine Multicast-Audio/Video-Sitzung (unter Verwendung von PCMU für Audio und entweder H.261 oder H.263+) mit der Videoquelle, die generische NACKs für beide Codecs und Reference Picture Selection für H.263 akzeptiert. Die Parameter für das Sicherheitsprotokoll werden wie in den in RFC 4567 [7] definierten SDP-Erweiterungen beschrieben ausgehandelt, die auf Sitzungsebene verwendet werden. Eine solche Beschreibung könnte über das Session Announcement Protocol (SAP) übermittelt worden sein.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi