21. Antwortcodes (Response Codes)
21 Antwortcodes
Die Antwortcodes entsprechen den HTTP/1.1-Antwortcodes und erweitern sie. Nicht alle HTTP/1.1-Antwortcodes sind angemessen, und es werden hier nur die passenden gezeigt. Andere HTTP/1.1-Antwortcodes sollten nicht verwendet werden. Darüber hinaus definiert SIP eine neue Klasse 6xx.
21.1 Vorläufig 1xx
Vorläufige Antworten (auch informelle Antworten genannt) zeigen an, dass der verbundene Server eine zusätzliche Aktion ausführt und noch keine endgültige Antwort hat. Der Server sendet eine 1xx-Antwort, wenn das Erhalten einer endgültigen Antwort voraussichtlich mehr als 200 ms dauert. Beachten Sie, dass vorläufige Antworten (1xx) auf unzuverlässige Weise gesendet werden. Sie veranlassen den Client niemals zum Senden eines ACK. Eine vorläufige (1xx)-Antwort darf einen Nachrichtenrumpf mit einer Sitzungsbeschreibung enthalten.
21.1.1 100 Trying
Diese Antwort zeigt an, dass die Anforderung vom Server des nächsten Hops empfangen wurde und eine unspezifizierte Aktion für diesen Anruf ausgeführt wird (beispielsweise wird eine Datenbank abgefragt). Diese Antwort, wie alle anderen vorläufigen Antworten, stoppt die Retransmission der INVITE durch den UAC. Die 100 (Trying)-Antwort wird, anders als andere vorläufige Antworten, niemals von einem zustandsbehafteten Proxy stromaufwärts weitergeleitet.
21.1.2 180 Ringing
Ein UA, das eine INVITE empfangen hat, versucht, den Benutzer zu warnen. Diese Antwort kann verwendet werden, um ein lokales Rückrufsignal zu starten.
21.1.3 181 Call Is Being Forwarded
Der Server kann diesen Statuscode verwenden, um anzuzeigen, dass der Anruf an eine Reihe anderer Ziele weitergeleitet wird.
21.1.4 182 Queued
Der Gerufene ist vorübergehend nicht verfügbar, aber der Server hat beschlossen, den Anruf in die Warteschlange zu stellen, anstatt ihn abzulehnen. Wenn der Gerufene verfügbar wird, wird eine angemessene endgültige Statusantwort zurückgegeben. Die Reason-Phrase kann weitere Details über den Status des Anrufs geben. Beispielsweise „5 Anrufe in der Warteschlange. Geschätzte Wartezeit 15 Minuten". Der Server darf mehrere 182 (Queued)-Antworten ausgeben, um den Anrufer über den Status des warteschlangengebundenen Anrufs zu informieren.
21.1.5 183 Session Progress
Die 183 (Session Progress)-Antwort wird verwendet, um Informationen über den Fortschritt eines Anrufs zu übermitteln, die sonst nicht klassifiziert werden. Sie darf Details über den Fortschritt des Anrufs mithilfe der Reason-Phrase, der Headerfelder oder des Nachrichtenrumpfs übermitteln.
21.2 Erfolg 2xx
Die Anforderung war erfolgreich.
21.2.1 200 OK
Die Anforderung war erfolgreich. Die mit der Antwort zurückgegebenen Informationen hängen von der in der Anforderung verwendeten Methode ab.
21.3 Umleitung 3xx
3xx-Antworten geben Informationen über den neuen Standort des Benutzers oder über einen alternativen Dienst, der den Anruf erfüllen könnte, an.
21.3.1 300 Multiple Choices
Die Adresse in der Anforderung wurde in mehrere Wahlmöglichkeiten aufgelöst, die jeweils ihren eigenen spezifischen Standort haben, und der Benutzer (oder der UA) kann den bevorzugten Kommunikationsendpunkt auswählen und die Anforderung an diesen Standort umleiten.
Die Antwort darf einen Nachrichtenrumpf enthalten, der eine Liste der Ressourcenmerkmale und Standorte enthält, aus denen der Benutzer oder der UA den am besten geeigneten auswählen kann, jedoch nur wenn durch das Accept-Anforderungs-Headerfeld zugelassen. Der MIME-Typ dieses Nachrichtenrumpfs ist jedoch nicht definiert.
Die Wahlmöglichkeiten sollten auch als Contact-Felder (Abschnitt 20.10) aufgelistet werden. Im Gegensatz zu HTTP darf eine SIP-Antwort mehrere Contact-Felder oder eine Adressliste in einem Contact-Feld enthalten. Der UA darf den Wert des Contact-Headerfelds für die automatische Umleitung verwenden oder den Benutzer um Bestätigung der Auswahl bitten. Diese Spezifikation definiert jedoch keinen Standard für eine solche automatische Auswahl.
Dieser Antwortstatuscode ist angemessen, wenn der Gerufene an mehreren verschiedenen Standorten erreichbar ist und der Server die Anforderung nicht proxifizieren kann oder will.
21.3.2 301 Moved Permanently
Der Benutzer existiert an der Adresse im Request-URI nicht mehr, und der Absender der Anforderung sollte es mit der neuen Adresse, die im Contact-Headerfeld (Abschnitt 20.10) angegeben ist, erneut versuchen. Der Absender der Anforderung sollte sein lokales Verzeichnis, sein Adressbuch und seinen Cache für die Benutzerposition mit diesem neuen Wert aktualisieren und zukünftige Anforderungen an die aufgeführte Adresse umleiten.
21.3.3 302 Moved Temporarily
Der Absender der Anforderung sollte die Anforderung mit der neuen Adresse, die im Contact-Headerfeld (Abschnitt 20.10) angegeben ist, erneut versuchen. Der Request-URI der neuen Anforderung verwendet den Wert des Contact-Headerfelds in der Antwort.
Die Gültigkeitsdauer des Contact-URI kann über das Expires-Headerfeld (Abschnitt 20.19) oder den expires-Parameter im Contact-Headerfeld angegeben werden. Proxys und UAs dürfen diesen URI für die Dauer der Gültigkeit zwischenspeichern. Ohne explizite Ablaufzeit ist die Adresse nur einmal für die Rekursion gültig und darf nicht für zukünftige Transaktionen zwischengespeichert werden.
Wenn der aus dem Contact-Headerfeld zwischengespeicherte URI fehlschlägt, darf der Request-URI der umgeleiteten Anforderung nur einmal erneut versucht werden.
Ein temporärer URI kann früher als seine Gültigkeitsdauer veralten, und ein neuer temporärer URI könnte verfügbar sein.
21.3.4 305 Use Proxy
Die angeforderte Ressource muss über den im Contact-Feld angegebenen Proxy zugegriffen werden. Das Contact-Feld gibt den URI des Proxys an. Vom Empfänger wird erwartet, dass er diese einzelne Anforderung über den Proxy wiederholt. Die 305 (Use Proxy)-Antwort darf nur von einem UAS generiert werden.
21.3.5 380 Alternative Service
Der Anruf ist fehlgeschlagen, aber ein alternativer Dienst ist möglich.
Der alternative Dienst wird im Nachrichtenrumpf der Antwort beschrieben. Das Format eines solchen Rumpfs ist hier nicht definiert und könnte Gegenstand künftiger Standardisierung sein.
21.4 Anforderungsfehler 4xx
4xx-Antworten sind endgültige Fehlerantworten von einem bestimmten Server. Der Client sollte dieselbe Anforderung nicht ohne Änderung erneut versuchen (beispielsweise durch Hinzufügen der entsprechenden Authentifizierung). Jedoch könnte dieselbe Anforderung an einen anderen Server erfolgreich sein.
21.4.1 400 Bad Request
Die Anforderung konnte wegen eines fehlerhaft formatierten Syntax nicht verstanden werden. Die Reason-Phrase sollte das Syntaxproblem genauer identifizieren. Beispielsweise „Call-ID header field missing".
21.4.2 401 Unauthorized
Die Anforderung erfordert die Authentifizierung des Benutzers. Diese Antwort wird von UAS und Registrar ausgegeben, und 407 (Proxy Authentication Required) wird vom Proxyserver verwendet.
21.4.3 402 Payment Required
Für zukünftige Verwendung reserviert.
21.4.4 403 Forbidden
Der Server hat die Anforderung verstanden, lehnt es jedoch ab, sie auszuführen. Authentifizierung ist nutzlos, und die Anforderung sollte nicht wiederholt werden.
21.4.5 404 Not Found
Der Server hat die definitive Information, dass kein Benutzer im durch das Request-URI angegebenen Domänen existiert. Dieser Status wird auch zurückgegeben, wenn die Domäne im Request-URI mit keiner der vom Empfänger der Anforderung verarbeiteten Domänen übereinstimmt.
21.4.6 405 Method Not Allowed
Die in der Request-Line angegebene Methode wird verstanden, aber für die durch das Request-URI identifizierte Adresse nicht zugelassen.
Die Antwort muss ein Allow-Headerfeld enthalten, das die Liste der gültigen Methoden für die angegebene Adresse enthält.
21.4.7 406 Not Acceptable
Die durch die Anforderung identifizierte Ressource ist nur in der Lage, eine Antworentität zu erzeugen, die Merkmale aufweist, die gemäß dem in der Anforderung gesendeten Accept-Headerfeld nicht akzeptabel sind.
21.4.8 407 Proxy Authentication Required
Dieser Code ähnelt 401 (Unauthorized), zeigt jedoch an, dass der Client sich zuerst beim Proxy authentifizieren muss. Die SIP-Zugriffsauthentifizierung ist in den Abschnitten 26 und 22.3 beschrieben.
Dieser Statuscode kann in Anwendungen verwendet werden, die eine Authentifizierung für den Zugriff auf den Kommunikationskanal (beispielsweise ein Telefon-Gateway) erfordern.
21.4.9 408 Request Timeout
Der Server konnte keine Antwort innerhalb der angemessenen Zeit erzeugen. Beispielsweise konnte er die Position des Benutzers nicht rechtzeitig bestimmen. Der Client darf die Anforderung zu einem beliebigen späteren Zeitpunkt unverändert erneut versuchen.
21.4.10 410 Gone
Die angeforderte Ressource ist auf dem Server nicht mehr verfügbar und die Weiterleitungsadresse ist ebenfalls nicht bekannt. Dieser Zustand wird als dauerhaft angesehen. Wenn der Server nicht weiß oder nicht entscheiden kann, ob der Zustand dauerhaft ist, sollte er stattdessen den Statuscode 404 (Not Found) verwenden.
21.4.11 413 Request Entity Too Large
Der Server lehnt die Verarbeitung der Anforderung ab, weil der Entitätsrumpf der Anforderung größer als die Größe ist, die der Server verarbeiten möchte oder kann. Der Server darf die Verbindung schließen, um zu verhindern, dass der Client die Anforderung fortsetzt.
Ist die Bedingung vorübergehend, sollte der Server ein Retry-After-Headerfeld einfügen, das angibt, dass sie vorübergehend ist und wann der Client erneut versuchen kann.
21.4.12 414 Request-URI Too Long
Der Server lehnt die Verarbeitung der Anforderung ab, weil das Request-URI länger als die Länge ist, die der Server interpretieren möchte.
21.4.13 415 Unsupported Media Type
Der Server lehnt die Verarbeitung der Anforderung ab, weil der Nachrichtenrumpf der Anforderung in einem Format vorliegt, das der Server für die angeforderte Methode nicht unterstützt. Der Server muss eine Liste der akzeptablen Formate zurückgeben, indem er je nach spezifischem Inhaltsproblem die Headerfelder Accept, Accept-Encoding oder Accept-Language verwendet. Die UAC-Verarbeitung dieser Antwort ist in Abschnitt 8.1.3.5 beschrieben.
21.4.14 416 Unsupported URI Scheme
Der Server kann die Anforderung nicht verarbeiten, weil das Schema des URI im Request-URI dem Server unbekannt ist. Die Client-Verarbeitung dieser Antwort ist in Abschnitt 8.1.3.5 beschrieben.
21.4.15 420 Bad Extension
Der Server hat die im Headerfeld Proxy-Require (Abschnitt 20.29) oder Require (Abschnitt 20.32) angegebene Protokollerweiterung nicht verstanden. Der Server muss in der Antwort die Liste der nicht unterstützten Erweiterungen im Unsupported-Headerfeld enthalten. Die UAC-Verarbeitung dieser Antwort ist in Abschnitt 8.1.3.5 beschrieben.
21.4.16 421 Extension Required
Ein UAS benötigt eine bestimmte Erweiterung, um die Anforderung zu verarbeiten, diese Erweiterung ist jedoch nicht in dem Supported-Headerfeld der Anforderung aufgeführt. Die Antwort mit diesem Statuscode muss ein Require-Headerfeld enthalten, das die erforderliche Erweiterung auflistet.
Ein UAS sollte diese Antwort nur verwenden, wenn es dem Client tatsächlich keinen nützlichen Dienst bieten kann. Stattdessen sollte der Server, wenn die gewünschte Erweiterung nicht im Supported-Headerfeld aufgeführt ist, die Anforderung mithilfe der Basis-SIP-Funktionen und der vom Client unterstützten Erweiterungen verarbeiten.
21.4.17 423 Interval Too Brief
Der Server lehnt die Anforderung ab, weil das Gültigkeitsintervall der durch die Anforderung aktualisierten Ressource zu kurz ist. Diese Antwort kann von einem Registrar verwendet werden, um eine Registrierung abzulehnen, deren Ablauf im Contact-Headerfeld zu kurz war. Die Verwendung dieser Antwort und des zugehörigen Min-Expires-Headerfelds ist in den Abschnitten 10.2.8, 10.3 und 20.23 beschrieben.
21.4.18 480 Temporarily Unavailable
Das Endsystem des Gerufenen ist ordnungsgemäß verbunden, aber der Gerufene ist derzeit nicht verfügbar (beispielsweise nicht angemeldet, angemeldet, aber in einem Zustand, der die Kommunikation mit dem Gerufenen verhindert, oder mit aktivierter „Anrufabweisung"). Die Antwort darf einen besseren Anrufzeitpunkt über das Retry-After-Headerfeld angeben. Der Benutzer könnte an anderer Stelle verfügbar sein (diesem Server nicht bekannt). Die Reason-Phrase sollte die genaue Ursache der Nichtverfügbarkeit des Gerufenen angeben. Dieser Wert sollte vom UA konfigurierbar sein. Der Status 486 (Busy Here) darf verwendet werden, um den spezifischen Grund des Anrufversagens genauer anzugeben.
Dieser Status wird auch von einem Redirect- oder Proxyserver zurückgegeben, der den durch das Request-URI identifizierten Benutzer erkennt, aber derzeit keinen gültigen Weiterleitungsort für diesen Benutzer hat.
21.4.19 481 Call/Transaction Does Not Exist
Dieser Status zeigt an, dass ein UAS eine Anforderung erhalten hat, die mit keinem bestehenden Dialog oder keiner bestehenden Transaktion übereinstimmt.
21.4.20 482 Loop Detected
Der Server hat eine Schleife erkannt (Element 4 des Abschnitts 16.3).
21.4.21 483 Too Many Hops
Der Server hat eine Anforderung erhalten, die ein Max-Forwards-Headerfeld (Abschnitt 20.22) mit dem Wert Null enthielt.
21.4.22 484 Address Incomplete
Der Server hat eine Anforderung erhalten, deren Request-URI unvollständig ist. Zusätzliche Informationen sollten in der Reason-Phrase bereitgestellt werden.
Dieser Statuscode erlaubt die Überlappungswahl. Bei der Überlappungswahl kennt der Client die Länge der Wählzeichenfolge nicht. Er sendet eine Zeichenfolge mit zunehmender Länge und fordert den Benutzer zu weiterer Eingabe auf, und fährt fort, bis er keine 484 (Address Incomplete)-Statusantwort mehr erhält.
21.4.23 485 Ambiguous
Das Request-URI war mehrdeutig. Die Antwort darf die Liste der eindeutig möglichen Adressen im Contact-Headerfeld enthalten. Die Alternativen offenzulegen kann die Privatsphäre des Benutzers oder der Organisation verletzen. Es muss möglich sein, den Server so zu konfigurieren, dass er auf ein mehrdeutiges Request-URI mit 404 (Not Found) antwortet oder die Liste der möglichen Wahlmöglichkeiten unterdrückt.
Beispiel für eine Antwort auf eine Anforderung, deren Request-URI sip:[email protected] ist:
SIP/2.0 485 Ambiguous
Contact: Carol Lee `<sip:[email protected]>`
Contact: Ping Lee `<sip:[email protected]>`
Contact: Lee M. Foote `<sips:[email protected]>`
Einige E-Mail- und Voicemail-Systeme bieten diese Funktion. Ein von 3xx verschiedener Statuscode wird verwendet, da er eine andere Semantik als 3xx hat. Im Fall von 300 wird angenommen, dass die bereitgestellten Wahlmöglichkeiten dieselbe Person oder denselben Dienst erreichen. Die automatische Auswahl oder die sequentielle Suche ergibt für 3xx-Antworten einen Sinn, aber eine 485 (Ambiguous)-Antwort erfordert die Eingabe des Benutzers.
21.4.24 486 Busy Here
Das Endsystem des Gerufenen ist ordnungsgemäß verbunden, aber der Gerufene will oder kann derzeit keinen anderen Anruf annehmen. Die Antwort darf einen besseren Anrufzeitpunkt über das Retry-After-Headerfeld angeben. Der Benutzer könnte an anderer Stelle verfügbar sein, wie ein Voicemail-Dienst. Wenn der Client weiß, dass andere Endsysteme diesen Anruf nicht annehmen können, sollte er 600 (Busy Everywhere) verwenden.
21.4.25 487 Request Terminated
Die Anforderung wurde durch eine BYE- oder CANCEL-Anforderung beendet. Diese Antwort wird niemals auf die CANCEL-Anforderung selbst zurückgegeben.
21.4.26 488 Not Acceptable Here
Die Antwort hat dieselbe Bedeutung wie 606 (Not Acceptable), gilt jedoch nur für die durch das Request-URI adressierte bestimmte Ressource, und die Anforderung könnte anderswo erfolgreich sein.
Ein Nachrichtenrumpf, der eine Beschreibung der Medienfunktionen enthält, die gemäß dem Accept-Headerfeld in der INVITE (oder application/sdp, falls nicht vorhanden) formatiert ist, darf in der Antwort vorhanden sein. Dies ist identisch mit dem Nachrichtenrumpf in einer 200 (OK)-Antwort auf eine OPTIONS-Anforderung.
21.4.27 491 Request Pending
Die Anforderung wurde von einem UAS empfangen, das eine ausstehende Anforderung im selben Dialog hat. Wie eine solche „Glare"-Situation gelöst wird, ist in Abschnitt 14.2 beschrieben.
21.4.28 493 Undecipherable
Die Anforderung wurde von einem UAS empfangen, das einen verschlüsselten MIME-Rumpf enthält, für den der Empfänger den entsprechenden Entschlüsselungsschlüssel nicht besitzt oder nicht bereitstellt. Diese Antwort darf einen einzelnen Rumpf enthalten, der den geeigneten öffentlichen Schlüssel enthält, der zum Verschlüsseln des an diesen UA gesendeten MIME-Rumpfs verwendet werden soll. Einzelheiten zur Verwendung dieses Antwortcodes finden sich in Abschnitt 23.2.
21.5 Serverfehler 5xx
5xx-Antworten sind Fehlerantworten, die gegeben werden, wenn der Server selbst einen Fehler verursacht hat.
21.5.1 500 Server Internal Error
Der Server hat eine unerwartete Bedingung festgestellt, die ihn daran hinderte, die Anforderung auszuführen. Der Client darf einen spezifischen Fehlerzustand anzeigen und die Anforderung nach einigen Sekunden erneut versuchen.
Ist die Bedingung vorübergehend, darf der Server über das Retry-After-Headerfeld angeben, wann der Client die Anforderung erneut versuchen kann.
21.5.2 501 Not Implemented
Der Server unterstützt die Funktionen nicht, die zur Erfüllung der Anforderung notwendig sind. Dies ist die angemessene Antwort, wenn ein UAS die Anforderungsmethode nicht erkennt und sie für keinen Benutzer unterstützen kann. (Ein Proxy leitet alle Anforderungen unabhängig von der Methode weiter.)
Beachten Sie, dass, wenn der Server die Anforderungsmethode erkennt, sie jedoch nicht zugelassen oder unterstützt ist, ein 405 (Method Not Allowed) gesendet wird.
21.5.3 502 Bad Gateway
Der Server hat, während er als Gateway oder Proxy fungierte, eine ungültige Antwort vom Downstream-Server erhalten, auf den er zur Erfüllung der Anforderung zugegriffen hat.
21.5.4 503 Service Unavailable
Der Server kann die Anforderung vorübergehend aufgrund einer vorübergehenden Überlastung oder Wartung des Servers nicht verarbeiten. Der Server darf über das Retry-After-Headerfeld angeben, wann der Client die Anforderung erneut versuchen sollte. Ohne Retry-After muss der Client so handeln, als hätte er eine 500 (Server Internal Error)-Antwort erhalten.
Ein Client (Proxy oder UAC), der eine 503 (Service Unavailable) erhalten hat, sollte versuchen, die Anforderung an einen alternativen Server weiterzuleiten. Er sollte während des im Retry-After-Headerfeld (falls vorhanden) angegebenen Zeitraums keine anderen Anforderungen an diesen Server weiterleiten.
Der Server darf die Verbindung ablehnen oder die Anforderung verwerfen, anstatt mit 503 (Service Unavailable) zu antworten.
21.5.5 504 Server Time-out
Der Server hat keine rechtzeitige Antwort vom externen Server erhalten, auf den er zur Verarbeitung der Anforderung zugegriffen hat. Wenn innerhalb des durch das Expires-Headerfeld des Upstream-Servers angegebenen Zeitraums keine Antwort einging, sollte stattdessen 408 (Request Timeout) verwendet werden.
21.5.6 505 Version Not Supported
Der Server unterstützt oder lehnt es ab, die in der Anforderung verwendete SIP-Protokollversion zu unterstützen. Der Server gibt an, dass er die Anforderung nicht mit derselben Hauptversion wie der Client abschließen kann oder will, mit Ausnahme dieser Fehlermeldung.
21.5.7 513 Message Too Large
Der Server konnte die Anforderung nicht verarbeiten, weil die Nachrichtenlänge seine Fähigkeiten überschritt.
21.6 Globaler Fehler 6xx
6xx-Antworten zeigen an, dass der Server definitive Informationen über einen bestimmten Benutzer hat und nicht nur über die durch das Request-URI angegebene Instanz.
21.6.1 600 Busy Everywhere
Das Endsystem des Gerufenen ist ordnungsgemäß verbunden, aber der Gerufene ist beschäftigt und will derzeit keinen anderen Anruf annehmen. Die Antwort darf einen besseren Anrufzeitpunkt über das Retry-After-Headerfeld angeben. Wenn der Gerufene den Grund der Anrufablehnung nicht offenlegen will, verwendet er stattdessen den Statuscode 603 (Decline). Diese Statusantwort wird nur zurückgegeben, wenn der Client weiß, dass andere Endpunkte (wie ein Voicemail-System) nicht auf die Anforderung antworten. Andernfalls sollte ein 486 (Busy Here) zurückgegeben werden.
21.6.2 603 Decline
Die Maschine des Gerufenen ist ordnungsgemäß verbunden, aber der Benutzer hat ausdrücklich abgelehnt, teilzunehmen, oder kann es nicht. Die Antwort darf einen besseren Anrufzeitpunkt über das Retry-After-Headerfeld angeben. Diese Statusantwort wird nur zurückgegeben, wenn der Client weiß, dass andere Endpunkte nicht auf die Anforderung antworten.
21.6.3 604 Does Not Exist Anywhere
Der Server hat die autoritative Information, dass der durch das Request-URI angegebene Benutzer nirgends existiert.
21.6.4 606 Not Acceptable
Der Benutzeragent des Benutzers ist ordnungsgemäß verbunden, aber einige Aspekte der Sitzungsbeschreibung, wie das angeforderte Medium, die Bandbreite oder der Adressierungsstil, wurden nicht akzeptiert.
Eine 606 (Not Acceptable)-Antwort bedeutet, dass der Benutzer kommunizieren möchte, aber die beschriebene Sitzung nicht angemessen unterstützen kann. Eine 606 (Not Acceptable)-Antwort darf eine Liste von Gründen im Warning-Headerfeld enthalten, die erklären, warum die beschriebene Sitzung nicht unterstützt werden kann. Die Warning-Gründecodes sind in Abschnitt 20.43 aufgeführt.
Ein Nachrichtenrumpf, der eine Beschreibung der Medienfunktionen enthält, die gemäß dem Accept-Headerfeld in der INVITE (oder application/sdp, falls nicht vorhanden) formatiert ist, darf in der Antwort vorhanden sein. Dies ist identisch mit dem Nachrichtenrumpf in einer 200 (OK)-Antwort auf eine OPTIONS-Anforderung.
Es ist wünschenswert, dass die Aushandlung nicht häufig notwendig wird. Und wenn ein neuer Benutzer zu einer bestehenden Konferenz eingeladen wird, könnte die Aushandlung unmöglich sein. Es liegt in der Verantwortung des Initiators der Einladung zu entscheiden, ob auf Basis einer 606 (Not Acceptable)-Antwort gehandelt wird.
Diese Statusantwort wird nur zurückgegeben, wenn der Client weiß, dass andere Endpunkte nicht auf die Anforderung antworten.