8.3.2 Changing the Set of Media Formats (Menge der Medienformate ändern)
8.3.2 Changing the Set of Media Formats (Menge der Medienformate ändern)
Die Liste der in der Sitzung verwendeten Medienformate KANN geändert werden. Dazu erstellt der Offerer eine neue Medienbeschreibung, in der die Liste der Medienformate in der m=-Zeile von dem entsprechenden Medienstream im vorherigen SDP abweicht. Diese Liste KANN neue Formate enthalten und KANN Formate entfernen, die im vorherigen SDP vorhanden waren. Im Fall von RTP DARF jedoch die Zuordnung von einer bestimmten dynamischen Payload-Typnummer (dynamic payload type) zu einem bestimmten Codec innerhalb dieses Medienstreams für die Dauer einer Sitzung nicht geändert werden. Wenn zum Beispiel A ein Offer mit G.711 auf dynamischer Payload-Typnummer 46 erzeugt, MUSS Payload-Typ 46 von diesem Punkt an in allen Offers oder Answers für diesen Medienstream innerhalb der Sitzung G.711 bezeichnen. Es ist jedoch zulässig, mehrere Payload-Typnummern demselben Codec zuzuordnen, sodass ein aktualisiertes Offer auch Payload-Typ 72 für G.711 verwenden könnte.
Die Zuordnungen müssen für die Dauer der Sitzung fest bleiben, weil die Synchronisation zwischen SDP-Signalisierungsaustausch und Medienstrom lose ist.
Der entsprechende Medienstream in der Answer wird wie in Abschnitt 6 beschrieben formuliert und kann ebenfalls zu einer Änderung der Medienformate führen. Ebenso MUSS der Answerer, sobald er seine Answer sendet, wie in Abschnitt 6 beschrieben, mit allen Formaten aus dem Offer zu senden beginnen, die auch in der Answer standen, und SOLLTE das bevorzugteste Format im Offer verwenden, das auch in der Answer stand (sofern der Stream Senden erlaubt), und DARF nicht mit Formaten senden, die nicht im Offer stehen, selbst wenn sie in einem vorherigen SDP der Gegenstelle standen. Ebenso MUSS der Offerer, wenn er die Answer erhält, mit allen Formaten aus der Answer zu senden beginnen und SOLLTE das bevorzugteste verwenden (sofern der Stream Senden erlaubt), und DARF nicht mit Formaten senden, die nicht in der Answer stehen, selbst wenn sie in einem vorherigen SDP der Gegenstelle standen.
Wenn eine Implementierung ein Medienformat nicht mehr verwendet (indem sie dieses Format nicht in einem Offer oder einer Answer auflistet, obwohl es in einem vorherigen SDP war), muss sie dennoch kurzzeitig bereit sein, Medien in diesem Format zu empfangen. Wann kann sie aufhören, dafür bereit zu sein? Wenn sie es wissen muss, gibt es drei Techniken. Erstens kann die Implementierung zusätzlich zur Formatänderung die Ports ändern. Wenn Medien auf dem neuen Port ankommen, weiß sie, dass die Gegenstelle mit dem alten Format nicht mehr sendet, und sie kann die Empfangsbereitschaft dafür beenden. Dieser Ansatz ist unabhängig vom Medienformat. Portänderungen können jedoch Ressourcenreservierungen oder Neuverschlüsselung in Sicherheitsprotokollen erfordern. Der zweite Ansatz ist, bei Verwerfen eines Codecs eine völlig neue Menge dynamischer Payload-Typen für alle Codecs zu verwenden. Wenn Medien mit einem der neuen Payload-Typen empfangen werden, weiß die Implementierung, dass die Gegenstelle mit dem alten Format nicht mehr sendet. Dieser Ansatz beeinflusst keine Reservierungen oder Sicherheitskontexte, ist aber RTP-spezifisch und verschwendet einen sehr kleinen Payload-Typ-Raum. Ein dritter Ansatz ist ein Timer. Wenn das SDP der Gegenstelle empfangen wird, wird der Timer gestartet. Wenn er abläuft, kann die Implementierung aufhören, für das alte Format empfangsbereit zu sein. Ein Wert von einer Minute ist typischerweise mehr als ausreichend. In manchen Fällen kann es der Implementierung egal sein und sie dauerhaft für alte Formate bereit bleiben. Dann ist nichts zu tun.
Natürlich kann das Offer, wenn der angebotene Stream abgelehnt wird, sobald die Ablehnung eintrifft, aufhören, für neue Formate empfangsbereit zu sein.