5.3. Agenti utente con apparizioni condivise

Gli UA che supportano la funzionalità di apparizioni condivise utilizzano il pacchetto di stato del dialogo [RFC4235] con le estensioni di apparizione condivisa e il parametro del campo di intestazione Event 'shared' definito nella sezione 13.

Gli UA utilizzano le estensioni del pacchetto di dialogo nella sezione 5.2 insieme a SUBSCRIBE [RFC6665], NOTIFY [RFC6665] e PUBLISH [RFC3903]. Le richieste SUBSCRIBE, NOTIFY e PUBLISH per il pacchetto di eventi del dialogo includono il parametro del campo di intestazione Event 'shared' come richiesto da questa specifica.

La presenza del parametro del campo di intestazione Event 'shared' indica all'agente di apparizione che l'UA supporta questa specifica.

All'inizializzazione, l'UA DEVE sottoscrivere il pacchetto di eventi del dialogo dell'AOR e aggiornare la sottoscrizione secondo il SIP Events Framework [RFC6665]. Se la richiesta SUBSCRIBE fallisce, allora potrebbe non essere presente alcun agente di apparizione e questa funzionalità non è attiva per questo AOR. L'UA PUÒ riprovare periodicamente la sottoscrizione per vedere se le condizioni sono cambiate a intervalli non inferiori a quattro ore.

Quattro ore sono state scelte per limitare il test di sottoscrizione a sei al giorno per UA. L'aumento di questo intervallo ridurrebbe questo traffico di fallimento ma richiederebbe più tempo per scoprire un agente di apparizione appena attivato.

Gli UA possono anche utilizzare la presenza del parametro del campo di intestazione Event 'shared' nei NOTIFY per scoprire la presenza di un agente di apparizione per l'AOR.

Gli UA che implementano la funzionalità di apparizioni condivise, la risposta alle chiamate, l'unione e il bridging DEVONO supportare l'invio di un INVITE con Replaces [RFC3891] o Join [RFC3911]. L'agente utente client (UAC) deve includere le informazioni to-tag e from-tag nell'intestazione Replaces o Join in modo che il dialogo corretto venga abbinato dall'agente utente server (UAS) secondo le regole degli RFC 3891 e 3911.

Tutti gli UA che implementano la funzionalità di apparizioni condivise e supportano INVITE DEVONO supportare la ricezione di un INVITE con un campo di intestazione Replaces [RFC3891] o Join [RFC3911].

Quando si pubblicano o si notificano informazioni sul pacchetto di dialogo, un UA include il più grande set di identificazione del dialogo disponibile al momento della pubblicazione, con l'eccezione che un UA può omettere informazioni se desidera impedire ad altri UA di unirsi o rispondere a una chiamata. L'identificazione del dialogo include URI di destinazione locali e remoti, call-id, to-tag e from-tag. Sebbene queste informazioni di identificazione del dialogo siano opzionali in [RFC4235], sono essenziali nella funzionalità di apparizioni condivise, consentendo operazioni di controllo delle chiamate. Quando si mettono le chiamate in attesa, utilizzare il tag di funzionalità "+sip.rendering=no" per indicare ciò nelle notifiche del pacchetto di dialogo. L'utilizzo della descrizione completa della sessione SDP costringe invece l'endpoint a eseguire molta analisi aggiuntiva, complicando inutilmente il codice e invitando errori.

Il rendering accurato dello stato inattivo/attivo/avviso/attesa degli altri UA nel gruppo è una parte importante della funzionalità di apparizioni condivise.

Un UA che non ha bisogno di occupare un particolare numero di apparizione (o non se ne preoccupa) invierebbe semplicemente un INVITE come al solito per effettuare una chiamata in uscita.

Se la chiamata è una chiamata di emergenza, un UA NON DEVE mai attendere un'occupazione confermata prima di inviare un INVITE. Invece, la chiamata di emergenza DEVE procedere senza attendere la transazione PUBLISH.

Se un UA richiede un particolare numero di apparizione, l'UA DEVE inviare una richiesta PUBLISH del pacchetto di dialogo e attendere una risposta 2xx prima di inviare l'INVITE. Questo è richiesto nelle seguenti situazioni:

1. Quando l'utente occupa un particolare numero di apparizione per una chiamata in uscita (ad esempio, occupando l'apparizione e andando "fuori dal gancio", se l'interfaccia utente dell'UA utilizza questa metafora).

2. Quando l'utente ha richiesto che un numero di apparizione non venga utilizzato per una chiamata in uscita (cioè, durante una chiamata di consultazione, una chiamata di "media di servizio" come per la musica in attesa [RFC7088], o per una chiamata non considerata parte del gruppo di apparizioni condivise).

3. Quando l'utente ha scelto di unirsi (o collegare) a una chiamata esistente.

4. Quando l'utente ha scelto di sostituire (o prendere) una chiamata esistente.

Si noti che quando un UA occupa un'apparizione prima dell'istituzione di un dialogo (numeri 1 e 2 nell'elenco sopra), non tutte le informazioni sul dialogo saranno disponibili. In particolare, quando un UA pubblica un tentativo di occupare un'apparizione prima di conoscere l'URI di destinazione, potrebbero essere disponibili informazioni minime o nessuna informazione sul dialogo. Ad esempio, in alcuni casi, sarà noto solo l'URI di destinazione locale per la chiamata: nessuna informazione sul dialogo. Se il tag From e Call-ID non erano presenti nel PUBLISH iniziale, un nuovo PUBLISH DEVE essere inviato non appena queste informazioni sono disponibili.

La prima pubblicazione farà sì che l'agente di apparizione riservi il numero di apparizione per questo UA. Se la pubblicazione non ha alcun identificatore di dialogo (ad esempio, Call-ID o local-tag), l'agente di apparizione non può assegnare il numero di apparizione a un particolare dialogo dell'UA fino alla seconda pubblicazione, che conterrà alcuni identificatori di dialogo.

Questo stato di pubblicazione viene aggiornato come descritto in [RFC3903] durante lo stato del dialogo iniziale o l'agente di apparizione può riassegnare il numero di apparizione. Una volta che il dialogo è passato allo stato confermato, non sono necessari aggiornamenti di pubblicazione.

Questa specifica presuppone che l'agente di apparizione abbia altri mezzi oltre alla pubblicazione UA per conoscere lo stato dei dialoghi UA. In questa specifica, PUBLISH viene utilizzato per indicare le operazioni del numero di apparizione desiderate e previste. Una volta che un dialogo passa da iniziale a confermato, questo ruolo è terminato; quindi, non sono necessari aggiornamenti di pubblicazione.

I numeri di apparizione sono un'etichetta abbreviata per i dialoghi attivi e in sospeso relativi a un AOR. Molte delle funzionalità e dei servizi costruiti utilizzando questa estensione si basano sul rendering corretto di queste informazioni all'utente umano. Inoltre, la natura di gruppo della funzionalità significa che il rendering deve essere simile tra diversi fornitori e diversi modelli. Il mancato rispetto di ciò ridurrà notevolmente il valore e l'utilità di queste estensioni di protocollo. In un'interfaccia utente correttamente progettata per questa funzionalità, il numero di apparizione per ogni dialogo attivo e in sospeso viene esplicitamente (cioè, per numero di apparizione) o implicitamente (utilizzando una metafora dell'interfaccia utente che rende chiara la numerazione e l'ordinamento all'utente) reso all'utente. L'identità dell'estremità remota di ogni dialogo (ad esempio, l'identità della parte remota) non è una sostituzione utile per il numero di apparizione. Lo stato di ogni apparizione deve anche essere reso (inattivo, attivo, occupato, unito, ecc.). Gli UA possono dire che un insieme di dialoghi sono uniti (collegati o mescolati) insieme dalla presenza di uno o più elementi <joined-dialog> contenenti altri identificatori di dialogo SIP. I numeri di apparizione dei dialoghi possono essere appresi tramite notifiche del pacchetto di dialogo contenenti l'elemento <appearance> dall'agente di apparizione o dal parametro Alert-Info 'appearance' in un INVITE in arrivo. In caso di conflitto, la notifica del pacchetto di dialogo ha la precedenza.

Un utente può selezionare un numero di apparizione ma poi abbandonare l'effettuazione di una chiamata (riagganciare). In questo caso, l'UA libera il numero di apparizione rimuovendo lo stato dell'evento con un PUBLISH come descritto in [RFC3903]. Il mancato rispetto di ciò richiederà operazioni non necessarie da parte dell'agente di apparizione e occuperà numeri di apparizione che potrebbero altrimenti essere utilizzati da altri UA nel gruppo di apparizioni condivise.

Un UA DOVREBBE registrarsi all'AOR solo se è probabile che l'UA risponda alle chiamate in arrivo. Se l'UA sta principalmente monitorando lo stato delle chiamate del gruppo di apparizioni condivise e rispondendo o unendosi alle chiamate, l'UA DOVREBBE solo sottoscrivere all'AOR e non registrarsi all'AOR. Se un UA di monitoraggio si registra piuttosto che solo sottoscrivere, genera grandi quantità di traffico di rete non necessario.

Tutti gli UA sottoscritti riceveranno NOTIFY del pacchetto di dialogo dello stato di tentativo per gli INVITE in arrivo.

Un UA NON DEVE inserire un parametro 'appearance' in un campo di intestazione Alert-Info in un INVITE o altra richiesta.

L'agente di apparizione è l'unico responsabile di farlo.