1. Introduction (Einführung)
1. Introduction (Einführung)
Das Session Description Protocol (Sitzungsbeschreibungsprotokoll, SDP) [1] wurde ursprünglich entwickelt, um Multicast-Sitzungen zu beschreiben, die über das Mbone übertragen werden. Das Session Announcement Protocol (Sitzungsankündigungsprotokoll, SAP) [6] wurde als Multicast-Mechanismus zum Transport von SDP-Nachrichten konzipiert. Obwohl die SDP-Spezifikation den Unicast-Betrieb zulässt, ist sie dafür nicht vollständig. Im Gegensatz zu Multicast, bei dem alle Teilnehmer eine globale Sicht der Sitzung verwenden, umfassen Unicast-Sitzungen zwei Teilnehmer, und eine vollständige Sicht der Sitzung erfordert Informationen von beiden Teilnehmern sowie eine Übereinstimmung über Parameter zwischen ihnen.
Beispielsweise erfordert eine Multicast-Sitzung die Übermittlung einer einzigen Multicast-Adresse für einen bestimmten Medienstrom. Für eine Unicast-Sitzung sind jedoch zwei Adressen erforderlich, je eine für jeden Teilnehmer. Ein weiteres Beispiel: Eine Multicast-Sitzung erfordert eine Angabe darüber, welche Codecs in der Sitzung verwendet werden. Für Unicast hingegen muss die Menge der Codecs durch Bildung der Schnittmenge der von jedem Teilnehmer unterstützten Mengen bestimmt werden.
Folglich fehlen dem SDP trotz seiner Ausdruckskraft zur Beschreibung von Unicast-Sitzungen die Semantik und die operativen Einzelheiten, wie dies tatsächlich geschieht. In diesem Dokument beheben wir das, indem wir ein einfaches Offer/Answer-Modell (Angebot-/Antwortmodell) auf Basis von SDP definieren. In diesem Modell erzeugt ein Teilnehmer der Sitzung eine SDP-Nachricht, die das Offer (Angebot) bildet: die Menge der Medienströme und Codecs, die der Offerer (Anbieter) verwenden möchte, sowie die IP-Adressen und Ports, über die der Offerer das Medium empfangen möchte. Das Offer wird dem anderen Teilnehmer, dem Answerer (Antwortenden), übermittelt. Der Answerer erzeugt eine Answer (Antwort), also eine SDP-Nachricht, die auf das vom Offerer bereitgestellte Offer reagiert. Die Answer enthält für jeden Strom im Offer einen passenden Medienstrom, der angibt, ob der Strom angenommen wird oder nicht, sowie die verwendeten Codecs und die IP-Adressen und Ports, über die der Answerer das Medium empfangen möchte.
Es ist auch möglich, dass eine Multicast-Sitzung ähnlich wie eine Unicast-Sitzung funktioniert: Ihre Parameter werden zwischen einem Paar von Benutzern wie im Unicast-Fall ausgehandelt, beide Seiten senden jedoch Pakete an dieselbe Multicast-Adresse statt an Unicast-Adressen. Dieses Dokument behandelt außerdem die Anwendung des Offer/Answer-Modells auf Multicast-Ströme.
Wir definieren ferner Richtlinien dafür, wie das Offer/Answer-Modell zur Aktualisierung einer Sitzung nach einem anfänglichen Offer/Answer-Austausch verwendet wird.
Die Mittel, über die Offers und Answers transportiert werden, liegen außerhalb des Geltungsbereichs dieses Dokuments. Das hier definierte Offer/Answer-Modell ist der verpflichtende Baseline-Mechanismus, der vom Session Initiation Protocol (Sitzungsaufbauprotokoll, SIP) [7] verwendet wird.