7. Offerer Processing of the Answer (Verarbeitung der Antwort durch den Offerer)

7. Offerer Processing of the Answer (Verarbeitung der Antwort durch den Offerer)

Wenn der Offerer (Anbietende Partei) die Answer (Antwort) erhält, KANN er Medien auf den akzeptierten Stream(s) senden (sofern diese in der Antwort als sendrecv oder recvonly aufgeführt sind). Er MUSS ein in der Antwort aufgeführtes Medienformat verwenden, und er SOLLTE beim Senden das erste in der Antwort aufgeführte Medienformat verwenden.

Der Grund, warum dies ein SOLL und kein MUSS ist (ebenso ein SOLL und kein MUSS für den Answerer), ist, dass es oft nötig sein wird, Codecs während der Sitzung zu wechseln. Zum Beispiel möchte eine Implementierung in Stillephasen zu einem Comfort-Noise-Codec wechseln. Oder wenn der Benutzer eine Ziffer auf der Tastatur drückt, möchte die Implementierung dies unter Verwendung von RFC 2833 [9] senden. Überlastungssteuerung kann aufgrund von Rückmeldungen den Wechsel zu einem Codec mit niedrigerer Rate erfordern.

Der Offerer SOLLTE Medien gemäß dem Wert von ptime- und Bandbreitenattributen (bandwidth) in der Antwort senden.

Der Offerer KANN sofort aufhören, auf Medienformate zu lauschen, die im ursprünglichen Offer aufgeführt waren, aber nicht in der Antwort enthalten sind.