Zum Hauptinhalt springen

9. Canceling a Request

9 Canceling a Request

Im vorherigen Abschnitt haben wir das allgemeine UA-Verhalten zum Erzeugen von Anfragen aller Methoden und zum Verarbeiten von Antworten besprochen. Dieser Abschnitt behandelt eine generische Methode namens CANCEL.

Wie der Name sagt, wird die CANCEL-Anfrage von einem Client verwendet, um eine zuvor gesendete Anfrage zu stornieren. Genauer gesagt, fordert sie einen UAS auf, die Verarbeitung der Anfrage abzubrechen und eine Fehlerantwort auf diese Anfrage zu erzeugen. CANCEL hat keine Auswirkung auf eine Anfrage, für die der UAS bereits eine endgültige Antwort zurückgegeben hat. Daher ist es nützlich, um Anfragen zu stornieren, die möglicherweise lange für eine Antwort brauchen. Aus diesem Grund eignet sich CANCEL am besten für INVITE-Anfragen, die möglicherweise lange für eine Antwort brauchen. In seiner Verwendung hört ein UAS, das ein CANCEL für ein INVITE erhält, das noch keine endgültige Antwort gesendet hat, auf zu „klingeln“ und antwortet dann auf das INVITE mit einer spezifischen Fehlerantwort (487).

Die CANCEL-Anfrage kann sowohl von einem Proxy als auch von einem User Agent Client erstellt und gesendet werden. Abschnitt 15 erörtert, wann ein UAC eine INVITE-Anfrage storniert, und Abschnitt 16.10 erörtert die Verwendung von CANCEL durch den Proxy.

Da der zustandsbehaftete Proxy auf CANCEL antwortet, anstatt einfach Antworten von nachgelagerten Elementen weiterzuleiten, wird CANCEL als „Hop-by-Hop“-Anfrage bezeichnet, da er bei jedem zustandsbehafteten Proxy-Hop beantwortet wird.

9.1 Client-Verhalten

Eine CANCEL-Anfrage SOLLTE (SHOULD NOT) nicht gesendet werden, um eine andere Anfrage als INVITE zu stornieren.

  Nicht-INVITE-Anfragen werden sofort beantwortet, daher würde das Senden eines CANCEL für eine Nicht-INVITE-Anfrage immer eine Wettlaufsituation erzeugen.

Die folgenden Verfahren werden verwendet, um eine CANCEL-Anfrage zu erstellen. Die Header-Felder Request-URI, Call-ID, To, der numerische Teil von CSeq und From der CANCEL-Anfrage MÜSSEN (MUST) identisch (einschließlich Tags) mit denen der zu stornierenden Anfrage sein. Das vom Client erstellte CANCEL MUSS (MUST) nur einen einzigen Via-Header-Feldwert haben, der mit dem ersten Via-Wert der zu stornierenden Anfrage übereinstimmt. Durch die Verwendung derselben Werte für diese Header-Felder kann CANCEL mit der Anfrage abgeglichen werden, die es storniert (Abschnitt 9.2 zeigt, wie ein solcher Abgleich durchgeführt wird). Der Methodenteil des CSeq-Header-Felds MUSS (MUST) jedoch den Wert CANCEL haben. Dies ermöglicht, dass die Anfrage als eigene Transaktion identifiziert und verarbeitet wird (siehe Abschnitt 17).

Wenn die zu stornierende Anfrage ein Route-Header-Feld enthält, MUSS (MUST) die CANCEL-Anfrage den Wert dieses Route-Header-Felds enthalten.

  Dies ist notwendig, damit ein zustandsloser Proxy die CANCEL-Anfrage ordnungsgemäß routen kann.

Eine CANCEL-Anfrage DARF (MUST NOT) keine Require- oder Proxy-Require-Header-Felder enthalten.

Nachdem das CANCEL erstellt wurde, SOLLTE (SHOULD) der Client prüfen, ob er eine Antwort (vorläufig oder endgültig) auf die zu stornierende Anfrage (hier „ursprüngliche Anfrage“ genannt) erhalten hat.

Wenn keine vorläufige Antwort empfangen wurde, DARF (MUST NOT) die CANCEL-Anfrage nicht gesendet werden. Vielmehr MUSS (MUST) der Client auf das Eintreffen einer vorläufigen Antwort warten, bevor er die Anfrage sendet. Wenn die ursprüngliche Anfrage bereits eine endgültige Antwort erzeugt hat, ist CANCEL ein No-op, der nichts Substanzielles bewirkt, und SOLLTE (SHOULD NOT) nicht gesendet werden. Wenn der Client entscheidet, CANCEL zu senden, erstellt er eine Client-Transaktion für CANCEL und übergibt die CANCEL-Anfrage zusammen mit Zieladresse, Port und Transport. Zieladresse, Port und Transport von CANCEL MÜSSEN (MUST) identisch mit denen sein, die zum Senden der ursprünglichen Anfrage verwendet wurden.

  Wenn das Senden eines CANCEL erlaubt gewesen wäre, bevor eine Antwort auf die vorherige Anfrage empfangen wurde, könnte ein Server CANCEL vor der ursprünglichen Anfrage erhalten.

Beachten Sie, dass sowohl die Transaktion, die der ursprünglichen Anfrage entspricht, als auch die CANCEL-Transaktion unabhängig voneinander abgeschlossen werden. Der UAC, der eine Anfrage storniert, kann sich jedoch nicht auf den Empfang einer 487 (Request Terminated)-Antwort auf die ursprüngliche Anfrage verlassen. Ein RFC-2543-konformer UAS würde eine solche Antwort nicht erzeugen. Wenn die endgültige Antwort auf die ursprüngliche Anfrage nicht innerhalb von 64*T1 Sekunden empfangen wird (T1 ist in Abschnitt 17.1.1.1 definiert), SOLLTE (SHOULD) der Client die ursprüngliche Transaktion als storniert betrachten und SOLLTE (SHOULD) die Client-Transaktion verwerfen, die die ursprüngliche Anfrage verarbeitet.

9.2 Server-Verhalten

Die CANCEL-Methode fordert den TU auf der Serverseite auf, eine ausstehende Transaktion zu stornieren. Der TU bestimmt die zu stornierende Transaktion, indem er die CANCEL-Anfrage empfängt und dann das Transaktionsabgleichsverfahren aus Abschnitt 17.2.3 anwendet, wobei angenommen wird, dass die Anfragemethode anderen als CANCEL oder ACK ist. Die abgeglichene Transaktion ist die zu stornierende.

Die Verarbeitung einer CANCEL-Anfrage auf Serverseite hängt vom Servertyp ab. Ein zustandsloser Proxy leitet sie weiter, ein zustandsbehafteter Proxy antwortet darauf, möglicherweise indem er einige seiner eigenen CANCEL-Anfragen erzeugt, und ein UAS antwortet darauf. Siehe Abschnitt 16.10 für die Behandlung von CANCEL durch den Proxy.

Der UAS verarbeitet die CANCEL-Anfrage zunächst gemäß der allgemeinen UAS-Verarbeitung in Abschnitt 8.2. Da die CANCEL-Anfrage jedoch hop-by-hop ist und nicht erneut übertragen werden kann, kann sie vom Server nicht herausgefordert werden, um die entsprechenden Anmeldeinformationen im Authorization-Header-Feld zu erhalten. Beachten Sie auch, dass in der CANCEL-Anfrage kein Require-Header-Feld enthalten ist.

Wenn der UAS gemäß den obigen Verfahren keine mit CANCEL übereinstimmende Transaktion findet, SOLLTE (SHOULD) er mit 481 (Call Leg/Transaction Does Not Exist) auf CANCEL antworten. Wenn die Transaktion der ursprünglichen Anfrage noch existiert, hängt das Verhalten des UAS beim Empfang der CANCEL-Anfrage davon ab, ob bereits eine endgültige Antwort auf die ursprüngliche Anfrage gesendet wurde. Wenn ja, hat die CANCEL-Anfrage keinerlei Auswirkung auf die Verarbeitung der ursprünglichen Anfrage, den Sitzungszustand oder die auf die ursprüngliche Anfrage erzeugte Antwort. Wenn der UAS noch keine endgültige Antwort auf die ursprüngliche Anfrage ausgegeben hat, hängt sein Verhalten von der Methode der ursprünglichen Anfrage ab. War die ursprüngliche Anfrage ein INVITE, SOLLTE (SHOULD) der UAS sofort mit 487 (Request Terminated) auf das INVITE antworten. Die CANCEL-Anfrage hat keine Auswirkung auf die Verarbeitung von Transaktionen mit anderen in dieser Spezifikation definierten Methoden.

Unabhängig von der Methode der ursprünglichen Anfrage antwortet der UAS, solange das CANCEL mit einer existierenden Transaktion abgeglichen wird, auf die CANCEL-Anfrage selbst mit einer 200 (OK)-Antwort. Diese Antwort wird gemäß den Verfahren in Abschnitt 8.2.6 erstellt, und beachten Sie, dass der To-Tag der Antwort auf CANCEL und der To-Tag der Antwort auf die ursprüngliche Anfrage identisch sein SOLLTEN (SHOULD). Die Antwort auf CANCEL wird zur Übertragung an die Server-Transaktion übergeben.