9. Canceling a Request
9 Canceling a Request
Nella sezione precedente abbiamo discusso il comportamento generale dell'UA per generare richieste di tutti i metodi ed elaborare le risposte. Questa sezione tratta di un metodo generico chiamato CANCEL.
Come suggerisce il nome, la richiesta CANCEL è utilizzata da un client per annullare una richiesta precedentemente inviata. Più precisamente, richiede a un UAS di interrompere l'elaborazione della richiesta e di generare una risposta di errore a tale richiesta. CANCEL non ha effetto su una richiesta per la quale il UAS ha già restituito una risposta finale. Per questo motivo, è utile per annullare richieste che potrebbero richiedere molto tempo per rispondere. Per questo motivo, CANCEL si applica meglio alle richieste INVITE che potrebbero richiedere tempo per generare una risposta. Nel suo utilizzo, un UAS che riceve un CANCEL per un INVITE che non ha ancora inviato una risposta finale « smette di squillare » e poi risponde all'INVITE con una specifica risposta di errore (487).
La richiesta CANCEL può essere costruita e inviata sia da un proxy sia da un user agent client. La sezione 15 discute quando un UAC annulla una richiesta INVITE, e la sezione 16.10 discute l'utilizzo di CANCEL da parte del proxy.
Poiché il proxy con stato risponde a CANCEL anziché semplicemente inoltrare le risposte ricevute dagli elementi a valle, CANCEL è chiamata una richiesta « hop-by-hop » poiché viene risposta a ogni hop di proxy con stato.
9.1 Comportamento del client
Una richiesta CANCEL NON DOVREBBE (SHOULD NOT) essere inviata per annullare una richiesta diversa da INVITE.
Le richieste non-INVITE ricevono una risposta immediata, quindi l'invio di un CANCEL per una richiesta non-INVITE produrrebbe sempre una condizione di competizione.
Le seguenti procedure sono utilizzate per costruire una richiesta CANCEL. I campi di intestazione Request-URI, Call-ID, To, la parte numerica di CSeq e From della richiesta CANCEL DEVONO (MUST) essere identici (inclusi i tag) a quelli della richiesta da annullare. Il CANCEL costruito dal client DEVE (MUST) avere un solo valore di campo di intestazione Via corrispondente al primo valore Via della richiesta da annullare. Utilizzando gli stessi valori per questi campi di intestazione, CANCEL può essere messo in corrispondenza con la richiesta che annulla (la sezione 9.2 mostra come viene effettuata tale corrispondenza). Tuttavia, la parte metodo del campo di intestazione CSeq DEVE (MUST) avere il valore CANCEL. Ciò consente alla richiesta di essere identificata e elaborata come propria transazione (vedi sezione 17).
Se la richiesta da annullare contiene un campo di intestazione Route, la richiesta CANCEL DEVE (MUST) includere il valore di quel campo di intestazione Route.
Ciò è necessario per consentire a un proxy senza stato di instradare correttamente la richiesta CANCEL.
Una richiesta CANCEL NON DEVE (MUST NOT) contenere campi di intestazione Require o Proxy-Require.
Una volta costruito il CANCEL, il client DOVREBBE (SHOULD) verificare se ha ricevuto una risposta (provvisoria o finale) alla richiesta da annullare (qui chiamata « richiesta originale »).
Se non è stata ricevuta alcuna risposta provvisoria, la richiesta CANCEL NON DEVE (MUST NOT) essere inviata. Piuttosto, il client DEVE (MUST) attendere l'arrivo di una risposta provvisoria prima di inviare la richiesta. Se la richiesta originale ha già generato una risposta finale, il CANCEL è un no-op che non fa nulla di sostanziale, e NON DOVREBBE (SHOULD NOT) essere inviato. Quando il client decide di inviare il CANCEL, crea una transazione client per il CANCEL e passa la richiesta CANCEL con indirizzo di destinazione, porta e trasporto. L'indirizzo di destinazione, la porta e il trasporto del CANCEL DEVONO (MUST) essere identici a quelli utilizzati per inviare la richiesta originale.
Se l'invio di un CANCEL fosse stato consentito prima di ricevere una risposta alla richiesta precedente, un server potrebbe ricevere un CANCEL prima della richiesta originale.
Si noti che sia la transazione corrispondente alla richiesta originale sia la transazione CANCEL terminano entrambe indipendentemente. Tuttavia, il UAC che annulla una richiesta non può fare affidamento sulla ricezione di una risposta 487 (Request Terminated) alla richiesta originale. Un UAS conforme a RFC 2543 non genererebbe tale risposta. Se la risposta finale alla richiesta originale non viene ricevuta entro 64*T1 secondi (T1 è definito nella sezione 17.1.1.1), il client DOVREBBE (SHOULD) considerare la transazione originale annullata e DOVREBBE (SHOULD) scartare la transazione client che elabora la richiesta originale.
9.2 Comportamento del server
Il metodo CANCEL richiede al TU lato server di annullare una transazione in sospeso. Il TU determina la transazione da annullare ricevendo la richiesta CANCEL e poi applicando la procedura di corrispondenza della transazione della sezione 17.2.3 presumendo che il metodo di richiesta sia diverso da CANCEL o ACK. La transazione messa in corrispondenza è quella da annullare.
L'elaborazione di una richiesta CANCEL lato server dipende dal tipo di server. Un proxy senza stato la inoltra, un proxy con stato vi risponde, eventualmente generando alcune delle proprie richieste CANCEL, e un UAS vi risponde. Vedere la sezione 16.10 per la gestione di CANCEL da parte del proxy.
Il UAS elabora innanzitutto la richiesta CANCEL secondo l'elaborazione generale UAS descritta nella sezione 8.2. Tuttavia, poiché la richiesta CANCEL è hop-by-hop e non può essere ritrasmessa, non può essere contestata dal server per ottenere le credenziali appropriate nel campo di intestazione Authorization. Si noti inoltre che nessun campo di intestazione Require è incluso nella richiesta CANCEL.
Se il UAS non trova una transazione corrispondente a CANCEL secondo le procedure sopra, DOVREBBE (SHOULD) rispondere a CANCEL con 481 (Call Leg/Transaction Does Not Exist). Se la transazione della richiesta originale esiste ancora, il comportamento del UAS alla ricezione della richiesta CANCEL dipende dal fatto che sia già stata inviata una risposta finale alla richiesta originale. Se è stata inviata, la richiesta CANCEL non ha alcun effetto sull'elaborazione della richiesta originale, sullo stato di sessione o sulla risposta generata alla richiesta originale. Se il UAS non ha ancora emesso una risposta finale alla richiesta originale, il suo comportamento dipende dal metodo della richiesta originale. Se la richiesta originale era un INVITE, il UAS DOVREBBE (SHOULD) rispondere immediatamente all'INVITE con 487 (Request Terminated). La richiesta CANCEL non influisce sull'elaborazione di transazioni con altri metodi definiti in questa specifica.
Indipendentemente dal metodo della richiesta originale, purché il CANCEL corrisponda a una transazione esistente, il UAS risponde alla richiesta CANCEL stessa con una risposta 200 (OK). Questa risposta è costruita secondo le procedure della sezione 8.2.6, e si noti che il To tag della risposta a CANCEL e il To tag della risposta alla richiesta originale DOVREBBERO (SHOULD) essere identici. La risposta a CANCEL viene passata alla transazione server per l'invio.