5.1 Unicast Streams (Unicast-Ströme)
5.1 Unicast Streams (Unicast-Ströme)
Wenn der Anbieter auf einem Stream nur Medien an seinen Peer senden will, MUSS er den Stream mit dem Attribut "a=sendonly" als sendonly kennzeichnen. Ein Stream gilt als mit einer bestimmten Richtung markiert, wenn ein Richtungsattribut als Medienstrom- oder Sitzungsattribut vorhanden war. Will der Anbieter nur Medien von seinem Peer empfangen, MUSS er den Stream als recvonly markieren. Will er kommunizieren, aber vorerst weder senden noch empfangen, MUSS er den Stream mit "a=inactive" markieren. Das inaktive Richtungsattribut ist in RFC 3108 [3] festgelegt. Beim Real Time Transport Protocol (RTP) [4] werden für sendonly-, recvonly- und inactive-Streams weiterhin RTCP gesendet und empfangen, d. h. die Richtung des Medienstroms hat keine Auswirkung auf die RTCP-Nutzung. Will der Anbieter sowohl senden als auch empfangen, KANN er "a=sendrecv" angeben oder weglassen, da sendrecv der Standard ist.
Bei recvonly- und sendrecv-Streams geben Portnummer und Adresse im Angebot an, wo der Anbieter den Medienstrom empfangen möchte. Bei sendonly-RTP-Streams geben Adresse und Port indirekt an, wo der Anbieter RTCP-Berichte empfangen möchte. Sofern nicht ausdrücklich anders angegeben, werden Berichte an die um eins höhere Portnummer gesendet. Die im Angebot genannte IP-Adresse und der Port sagen nichts über Quell-IP und Quellport der RTP- und RTCP-Pakete des Anbieters aus. Eine Portnummer null im Angebot bedeutet, dass der Stream angeboten, aber NICHT verwendet werden DARF. Für ein initiales Angebot hat das keine nützliche Semantik, ist aber der Vollständigkeit halber erlaubt, da die Antwort Port null für einen abgelehnten Stream enthalten kann (Abschnitt 6). Bestehende Streams können durch Port null beendet werden (Abschnitt 8). Generell bedeutet Port null, dass der Medienstrom nicht gewünscht ist.
Die Liste der Medienformate je Medienstrom vermittelt zwei Informationen: die Menge der Formate (Codecs und ggf. zugehörige Parameter bei RTP), die der Anbieter senden und/oder empfangen kann (je nach Richtungsattributen), und bei RTP die RTP-Payload-Typ-Nummern zur Identifikation. Mehrere Formate bedeuten, dass der Anbieter jedes dieser Formate während der Sitzung nutzen kann. Mit anderen Worten: der Antwortende DARF mitten in der Sitzung das Format wechseln, ohne ein neues Angebot zu senden. Bei sendonly SOLL das Angebot die Formate nennen, die der Anbieter senden will; bei recvonly die zum Empfang; bei sendrecv die Codecs für Senden und Empfang.
Bei recvonly-RTP-Streams geben die Payload-Typ-Nummern den Wert des Payload-Typ-Feldes in RTP-Paketen an, die der Anbieter für diesen Codec zu empfangen erwartet. Bei sendonly die Werte in Paketen, die er senden will. Bei sendrecv die Werte, die er zu empfangen erwartet und vorzugsweise senden möchte. Für sendonly und sendrecv kann die Antwort jedoch andere Payload-Typ-Nummern für dieselben Codecs angeben; dann MUSS der Anbieter mit den Nummern aus der Antwort senden.
Unterschiedliche Payload-Typ-Nummern je Richtung können wegen der Interoperabilität mit H.323 nötig sein.
Gemäß RFC 2327 DÜRFEN fmtp-Parameter zusätzliche Parameter des Medienformats angeben.
Bei RTP-Strömen SOLLEN alle Medienbeschreibungen "a=rtpmap"-Zuordnungen von RTP-Payload-Typen zu Kodierungen enthalten. Ohne "a=rtpmap" ist die Standard-Zuordnung des aktuellen Profils (z. B. RFC 1890 [5]) zu verwenden.
Das erleichtert die Migration von statischen Payload-Typen.
In allen Fällen MÜSSEN die Formate in der "m="-Zeile nach Präferenz geordnet sein, das erste ist am präferiertesten. Präferiert heißt hier, dass der Empfänger des Angebots das höchste akzeptable Präferenzformat verwenden SOLL.
Ist das ptime-Attribut vorhanden, gibt es das gewünschte Paketierungsintervall an, das der Anbieter empfangen möchte. ptime MUSS größer als null sein.
Ist das Bandbreitenattribut vorhanden, gibt es die gewünschte Empfangsbandbreite an. Null ist erlaubt, aber nicht erwünscht; es bedeutet, dass kein Medienstrom gesendet werden soll; bei RTP würde auch RTCP abgeschaltet.
Mehrere Medienströme unterschiedlicher Typen bedeuten gleichzeitige Nutzung, typisch Audio und Video in einer Videokonferenz.
Mehrere Ströme desselben Typs bedeuten gleichzeitiges Senden und/oder Empfangen mehrerer Ströme dieses Typs. Beim Senden mehrerer gleichartiger Ströme ist die Zuordnung jeder Quelle (z. B. Kamera und VCR bei Video) zu jedem Stream lokale Policy. Hat der Nutzer nur eine Quelle pro Medientyp, ist nur eine Policy sinnvoll: die Quelle wird an jeden gleichartigen Stream gesendet. Jeder Stream DARF andere Kodierungen nutzen. Beim Empfang mehrerer gleichartiger Ströme ist die Zuordnung zu den Senken (z. B. Lautsprecher oder Aufnahme bei Audio) lokale Policy. Es gelten jedoch Einschränkungen: Erstens MUSS jeder empfangene gleichartige Stream mindestens einer Senke zur Darstellung für den Nutzer zugeordnet werden, d. h. parallele Darstellung aller, nicht nur eine auswählen. Zweitens MÜSSEN mehrere an dieselbe Senke geführte Ströme medien-spezifisch kombiniert werden (z. B. Mischen bei zwei Audiostreams; bei mehreren Instant-Messaging-Strömen mit Bildschirm als Senke alle in der UI zeigen). Drittens MÜSSEN mehrere Quellen, die auf denselben Stream gemappt sind, vor dem Senden medien-spezifisch kombiniert werden. Jenseits dieser Regeln ist Policy flexibel; ein Agent will in der Regel keine Policy, die Medien von Senken zu Quellen kopiert, außer er ist ein Konferenzserver (d. h. empfangenes Medien von einem Stream nicht auf einen anderen kopieren).
Ein typisches Beispiel sind Prepaid-Telefonkarten: Nutzer kann während eines Anrufs "#" gedrückt halten, auflegen und mit derselben Karte neu wählen. Dazu Medien des Nutzers an zwei Ziele: Remote-Gateway und DTMF-Anwendung für "#". Zwei Medienströme: einer sendrecv zum Gateway, einer sendonly (aus Nutzersicht) zur DTMF-Anwendung.
Nach dem Senden des Angebots MUSS der Anbieter zum Empfang für alle recvonly-Streams aus dem Angebot bereit sein. Er MUSS für sendrecv senden und empfangen und für sendonly senden können (Senden erst nach Antwort mit Adresse/Port). Bei RTP kann er Medien vor der Antwort empfangen, aber keine RTCP-Empfängerberichte senden, bis die Antwort eintrifft.