6.1 Unicast Streams (Unicast-Ströme)
6.1 Unicast Streams (Unicast-Ströme)
Wird ein Stream mit Unicast-Adresse angeboten, MUSS die Antwort für diesen Stream eine Unicast-Adresse enthalten. Der Medientyp in der Antwort MUSS dem des Angebots entsprechen.
Ist ein Stream als sendonly angeboten, MUSS der entsprechende Stream in der Antwort recvonly oder inactive sein. Ist er recvonly im Angebot, MUSS die Antwort sendonly oder inactive sein. Wird ein Medienstrom als sendrecv angeboten (oder fehlt ein Richtungsattribut auf Medien- oder Sitzungsebene, sodass der Strom standardmäßig sendrecv ist), DARF der entsprechende Stream in der Antwort sendonly, recvonly, sendrecv oder inactive sein. Ist er inactive angeboten, MUSS er in der Antwort inactive sein.
Bei in der Antwort als recvonly markierten Streams MUSS die "m="-Zeile mindestens ein Medienformat aus dem Angebot enthalten, das der Antwortende empfangen will. Zusätzliche Formate, die nicht im entsprechenden Angebots-Stream stehen, DÜRFEN angegeben werden. Bei sendonly mindestens ein zu sendendes Format aus dem Angebot; bei sendrecv mindestens ein Codec zum Senden und Empfangen aus dem Angebot. Zusätzliche Formate außerhalb des Angebots DÜRFEN genannt werden (Senden scheitert vorerst, da nicht im Angebot). Bei inactive in der Antwort wird die Formatliste aus dem Angebot abgeleitet: war das Angebot sendonly, wie bei recvonly-Antwort; recvonly wie sendonly; sendrecv wie sendrecv; inactive wie bei sendrecv für beide.
Verbindungsadresse und Port in der Antwort geben an, wo der Antwortende Medien empfangen will (bei RTP wird RTCP auf dem um eins höheren Port empfangen, sofern nicht anders angegeben). Adresse und Port MÜSSEN auch bei sendonly vorhanden sein; bei RTP dient der nächsthöhere Port weiterhin für RTCP.
Bei RTP SOLLTE, wenn ein Codec im Angebot mit bestimmtem Payload-Typ referenziert wurde, derselbe Typ in der Antwort für diesen Codec verwendet werden. Selbst bei gleichem Typ MUSS die Antwort rtpmap-Attribute für dynamische Typen enthalten und SOLL auch statische abbilden. Formate in "m=" MÜSSEN nach Präferenz sortiert sein; der Anbieter SOLL das höchstpräferierte Format aus der Antwort nutzen.
Obwohl der Antwortende die Reihenfolge nach eigener Präferenz wählen KANN, wird EMPFOHLEN, ohne besonderen Grund dieselbe relative Reihenfolge wie im Angebot beizubehalten (z. B. Codecs 8, 22, 48 im Angebot, Unterstützung nur 8 und 48 → Reihenfolge 8, 48 statt 48, 8), damit beide Richtungen denselben Codec nutzen.
Die Auslegung von fmtp im Angebot hängt von den Parametern ab. Oft beschreiben sie konkrete Konfigurationen und sind wie der Medienformatwert zu behandeln: dieselben fmtp mit denselben Werten MÜSSEN in der Antwort stehen, wenn das beschriebene Format dort vorkommt. Andere fmtp sind eher freie Parameter; unterschiedliche Werte je Agent sind zulässig, die Antwort KANN fmtp mit gleichen oder anderen Werten enthalten. SDP-Erweiterungen SOLLEN die Offer/Answer-Auslegung neuer Parameter festlegen.
Der Antwortende KANN ein von null verschiedenes ptime für jeden Medienstrom angeben (gewünschtes Paketierungsintervall zum Empfang). Gleiche Intervalle in beide Richtungen sind nicht erforderlich.
Er KANN ein Bandbreitenattribut angeben (Bandbreite, die der Anbieter beim Senden nutzen soll). Null ist erlaubt, Auslegung wie in Abschnitt 5.
Gibt es für einen angebotenen Stream kein gemeinsames Format, MUSS der Antwortende den Stream durch Port null ablehnen.
Ohne gemeinsame Formate für alle Streams wird die gesamte angebotene Sitzung abgelehnt.
Nach dem Senden der Antwort MUSS der Antwortende zum Empfang für alle recvonly-Streams aus der Antwort bereit sein. Er MUSS für sendrecv senden und empfangen können und DARF sofort senden. Er MUSS für recvonly oder sendrecv jedes in der Antwort gelistete Format empfangen können und DARF sofort senden. Beim Senden SOLL er ptime aus dem Angebot verwenden, falls vorhanden, und eine Bandbreite nicht über dem Angebotswert, falls angegeben. Er MUSS ein Format senden, das sowohl im Angebot als auch in der Antwort steht, und SOLL das höchstpräferierte aus dem Angebot wählen, das auch in der Antwort steht. Bei RTP MUSS er die Payload-Typ-Nummern aus dem Angebot verwenden, auch wenn sie von der Antwort abweichen.