Passa al contenuto principale

12. Dialogs

12 Dialogs

Un dialogo è una relazione SIP peer-to-peer tra due user agent che persiste per un certo tempo. I dialoghi sono utilizzati come mezzo per stabilire una chiamata (sezione 13) e per modificare e terminare chiamate (sezioni 14 e 15). I dialoghi formano la base di funzionalità più avanzate (ad esempio, PRESENCE e REFER [1] per riferire le risorse multimediali di un partecipante a un altro) definite successivamente.

Un dialogo è identificato dal Call-ID e dai tag locali e remoti (noti rispettivamente come tag To e From) (questi formano un identificatore di dialogo univoco). La serie di messaggi inviati all'interno di un dialogo comprende il mantenimento dello stato del dialogo, incluso l'obiettivo remoto (remote target) del dialogo (l'URI per inviare messaggi nel dialogo) e l'insieme di route (route set) (un insieme di proxy) corrispondente alle richieste inviate nel dialogo. Il dialogo è creato dai comportamenti del UAS e del UAC stabiliti, come descritto in tutto questo capitolo.

Questa sezione introduce il concetto di stato del dialogo. Tale stato è necessario per instradare le richieste inviate in ciascun dialogo. Questo stato è tracciato dal « lato » di ciascun UA. Cioè, in un particolare dialogo, il UAC e il UAS mantengono ciascuno uno stato diverso. Un UA registra lo stato utilizzando i concetti di lato « locale » e « remoto » del dialogo. L'URI locale, l'URI obiettivo remoto, il numero di sequenza remoto e il tag remoto del UAS corrispondono all'URI remoto, all'URI obiettivo locale, al numero di sequenza locale e al tag locale del UAC. Ciascun lato dello stato del dialogo è composto da una coppia di identificatori di dialogo (Call-ID, tag locale e tag remoto), un numero di sequenza locale (solo UAC), un numero di sequenza remoto, un URI remoto (utilizzato dal UAS per determinare dove inviare i messaggi), un URI obiettivo remoto e un insieme di route.

  I termini « remoto » e « locale » del capitolo 12 si riferiscono a uno specifico stato del dialogo e non al comportamento generale UAS e UAC del capitolo 8.

I lati mantengono lo stato del dialogo creando il dialogo e tramite l'elaborazione della risposta INVITE iniziale (con successo o meno) e delle richieste successive inviate nel dialogo.

12.1 Creazione di un dialogo

Il dialogo è creato dai comportamenti del UAS e del UAC che lo creano. Il comportamento del UAS è descritto nella sezione 12.1.1 e quello del UAC nella sezione 12.1.2. Il dialogo è creato dalla risposta UAS a un nuovo INVITE, a condizione che la risposta abbia un tag nel campo To e che la risposta sia un codice di risposta 2xx o 101-199. Le risposte di reindirizzamento 3xx non creano un dialogo.

  Nota: in RFC 2543, il dialogo era chiamato call (chiamata), ma ora è chiamato dialogo. Ciò lascia il termine call con il suo significato informale (ad esempio, call setup). Il dialogo è stabilito dallo scambio INVITE iniziale per stabilire una sessione. Tuttavia, il dialogo non corrisponde necessariamente 1:1 a una sessione. Più dialoghi (e quindi più chiamate) possono essere associati alla stessa sessione. Quando un user agent invia un re-INVITE per la stessa sessione, come descritto nella sezione 12.2, non viene creato un nuovo dialogo. Tuttavia, se un utente invia un nuovo INVITE che porta a un altro dialogo e tale INVITE punta a un altro utente nella stessa sessione, viene creato un altro dialogo (e quindi un'altra chiamata). Ciò si verifica, ad esempio, quando l'utente utilizza il call transfer durante una chiamata per terminare la prima chiamata e avviarne una nuova.

12.1.1 Comportamento del UAS

Un UAS che genera una risposta che crea un dialogo (cioè una risposta 101-199 o 2xx) DEVE (MUST) includere un tag nel campo di intestazione To della risposta (sezione 8.2.6.2). Questo tag, combinato con il valore Call-ID contenuto nella risposta e il valore del tag From fornito dal chiamante, forma il lato UAS dell'identificatore di dialogo. Il lato UAC dell'identificatore di dialogo (l'inverso dei tag To e From) è stabilito dalla richiesta che crea il dialogo. Pertanto, se la richiesta non crea un dialogo (ad esempio, una richiesta non-INVITE), il UAC che invia la richiesta non ha bisogno (NEED NOT) di registrare il valore del tag To contenuto nella risposta. Il lato UAC dell'identificatore di dialogo è formato dal tag From nella richiesta e dal tag To nella risposta (poiché è il creatore della richiesta, non della risposta). Una richiesta successiva come una richiesta BYE stabilisce il lato UAS dell'identificatore di dialogo utilizzando il tag From nella richiesta (poiché è il UAC di tale richiesta).

Un UAS che stabilisce una chiamata PUÒ (MAY) includere valori del campo di intestazione Record-Route nella risposta che crea il dialogo. Questi vengono aggiunti allo stato del dialogo per assicurare che le richieste successive passino attraverso di essi.

Il numero di sequenza remoto (dal punto di vista del UAS) del dialogo creato è impostato sul valore del numero di sequenza nel campo di intestazione CSeq della risposta. L'URI remoto è impostato sull'URI nel campo di intestazione To della risposta. L'URI obiettivo remoto è impostato sull'URI nel campo di intestazione Contact della risposta.

12.1.2 Comportamento del UAC

Un UAC che riceve una risposta che crea un dialogo (cioè una risposta 2xx o una risposta provvisoria 101-199) DEVE (MUST) copiare la parte di tag remoto dell'identificatore di dialogo dal campo To della risposta. Se la risposta è 2xx, il tag remoto DEVE (MUST) essere copiato dalla risposta che crea la richiesta, poiché alcune richieste possono creare lo stato del dialogo da risposte 1xx successive ricevute (sezione 13). L'URI remoto è impostato sull'URI nel campo di intestazione To della risposta. L'URI obiettivo remoto è impostato sull'URI nel campo di intestazione Contact della risposta.

  Se sono presenti valori del campo di intestazione Record-Route nella risposta (forniti dal UAS), il UAC DEVE (MUST) conservarli come valore iniziale dell'insieme di route e DEVE (MUST) invertirli (poiché appaiono nella richiesta nell'ordine inverso rispetto a quello in cui i campi Record-Route sono stati aggiunti). Il UAC utilizza l'insieme di route per inviare richieste nel dialogo (sezione 12.2.1.1). Quando una richiesta successiva viene inviata nel dialogo, il numero di sequenza locale per UAC è impostato sul numero di sequenza nel campo di intestazione CSeq della richiesta. Questo numero di sequenza DEVE (MUST) essere incrementato di uno per ogni richiesta inviata nel dialogo.

  Nota: una risposta di reindirizzamento 3xx non crea un dialogo. Una risposta di reindirizzamento 3xx è elaborata dal UAC secondo il requisito predefinito.

12.2 Richieste all'interno di un dialogo

Questa sezione descrive come le richieste sono inviate all'interno di un dialogo. Ciò include le richieste inviate all'interno di un dialogo esistente, come un re-INVITE (un INVITE per aggiornare l'obiettivo remoto del dialogo) o un BYE. Queste richieste sono costruite utilizzando le procedure generali di costruzione delle richieste UAC definite nella sezione 8.1.1. Pertanto, questa sezione descrive solo le differenze specifiche rispetto a tali procedure. L'invio di queste richieste non utilizza il numero di sequenza (CSeq) di richiesta nel dialogo (avvertimento: ci sono alcune eccezioni). Un proxy PUÒ (MAY) utilizzare le informazioni dell'insieme di route, sotto forma di modello di entità, per aiutare l'instradamento delle richieste inviate all'interno di un dialogo.

Notazione: questa sezione presuppone che, poiché il dialogo è già stato configurato come UAS o UAC prima che il lato ricevente elabori la richiesta, la richiesta INVITE iniziale che lo ha creato non è trattata come una richiesta nel dialogo, indipendentemente dallo stato dell'INVITE iniziale.

12.2.1 Comportamento del UAC

Una richiesta UAC inviata all'interno di un dialogo DEVE (MUST) essere instradata utilizzando lo stato del dialogo.

12.2.1.1 Generazione della richiesta

Durante la costruzione della richiesta, i campi di intestazione To, From e Call-ID DEVONO (MUST) essere impostati sull'URI remoto, URI locale e Call-ID dello stato del dialogo, e il campo di intestazione CSeq DEVE (MUST) essere impostato su un nuovo valore superiore di uno all'ultimo valore CSeq di richiesta inviato nel dialogo. Il Request-URI della richiesta DEVE (MUST) essere impostato sull'URI obiettivo remoto del dialogo. Se l'insieme di route non è vuoto, i valori del campo di intestazione Route della richiesta DEVONO (MUST) essere i valori dell'insieme di route. Se l'insieme di route è vuoto, il valore del campo di intestazione Route DOVREBBE (SHOULD) essere omesso.

  Nota: ciò garantisce che, se l'insieme di route non è vuoto, la richiesta passi attraverso un proxy (questo è lo scopo di fornire l'insieme di route). L'URI obiettivo remoto è utilizzato per aggirare i proxy poiché fornisce una rotta diretta tra UAC e UAS.

Ad esempio, se un UAC invia un re-INVITE in un dialogo creato tramite un singolo Record-Route (proxy):

  Re-INVITE sip:[email protected] SIP/2.0
  Via: SIP/2.0/UDP host.ua1.example.com;branch=z9hG4bKvscx
  Max-Forwards: 70
  To: Bob `<sip:[email protected]>;tag=a6c85cf`
  From: Alice `<sip:[email protected]>`;tag=1928301774
  Call-ID: [email protected]
  CSeq: 314160 INVITE
  Contact: `<sip:[email protected]>`
  Route: `<sip:proxy.example.com>`

Nota: l'unico valore Via è l'URI del mittente. Il valore CSeq del re-INVITE DEVE (MUST) essere maggiore di quello dell'INVITE originale. Si noti che un valore di numero di sequenza CSeq NON DEVE (MUST NOT) essere riutilizzato. Il valore del campo di intestazione Route è ottenuto dall'insieme di route.

Le seguenti procedure si applicano all'invio di una richiesta in un dialogo. Se una richiesta di aggiornamento destinazione (definita nella sezione 12.2.2) è generata dal UAC nel dialogo, il valore del campo di intestazione Contact di tale richiesta DEVE (MUST) aggiornare l'URI obiettivo remoto del dialogo.

  In generale, un re-INVITE è utilizzato per aggiornare l'obiettivo remoto del dialogo, ma una richiesta UPDATE o altre richieste di aggiornamento destinazione possono essere utilizzate anch'esse. Le procedure descritte in questa sezione (incluse il routing) sono regole generali che consentono a una richiesta di aggiornamento destinazione di aggiornarsi utilizzando un booleano. Per una richiesta INVITE, un re-INVITE DEVE (MUST) essere utilizzato anche per inizializzare una modifica della descrizione di sessione (sezione 14).

12.2.1.2 Elaborazione della risposta

Una risposta a una richiesta inviata all'interno di un dialogo è elaborata utilizzando le procedure descritte nella sezione 8.1.3.

Alla ricezione di una risposta 2xx a una richiesta di aggiornamento destinazione (definita nella sezione 12.2.2), il UAC DEVE (MUST) aggiornare l'URI obiettivo remoto del dialogo utilizzando l'URI nel campo di intestazione Contact della risposta.

12.2.2 Richieste di aggiornamento destinazione

Una richiesta di aggiornamento destinazione è definita come una richiesta inviata all'interno di un dialogo che può modificare l'obiettivo remoto del dialogo. Le richieste INVITE e UPDATE di questa specifica sono richieste di aggiornamento destinazione. Altre richieste inviate all'interno di un dialogo (ad esempio BYE) NON DOVREBBERO (SHOULD NOT) modificare l'URI obiettivo remoto.

12.3 Terminazione di un dialogo

Un dialogo termina con la ricezione di un BYE con successo (con risposta 2xx), o con una risposta non-2xx (ad esempio 408 o 480 per un INVITE rifiutato) (vedere sezione 15). In entrambi i casi, il lato ricevente DEVE (MUST) cancellare lo stato del dialogo. Il mittente di un BYE con successo DEVE (MUST) cancellarlo solo dopo aver ricevuto il BYE (anche se un UAC con un INVITE fallito può cancellare immediatamente lo stato del dialogo (MAY)).

  Nota: un dialogo corrispondente a un INVITE fallito termina con la ricezione della risposta finale (con successo o fallimento). Un dialogo corrispondente a un INVITE con successo termina solo tramite una successiva richiesta BYE. Pertanto, un re-INVITE non termina il dialogo contenente la richiesta INVITE originale.

  Un INVITE fallito è trattato come una semplice transazione. Un dialogo corrispondente a un INVITE con successo termina solo tramite la ricezione di una richiesta BYE. Anche dopo la fine tramite la ricezione di un BYE, il UAC può continuare a mantenere il vecchio stato del dialogo fino al completamento di tutte le transazioni nel dialogo (MAY).