4. Requisiti e implementazione

La sezione successiva dettaglia i requisiti e discute l'implementazione della funzionalità di apparizioni condivise.

4.1. Requisiti

I requisiti di base della funzionalità di apparizioni condivise possono essere riassunti come segue:

REQ-1: Le chiamate in arrivo all'AOR devono essere offerte a un gruppo di UA e possono essere risposte da qualsiasi di essi.

REQ-2: Ogni UA nel gruppo deve essere in grado di conoscere lo stato delle chiamate degli altri nel gruppo allo scopo di presentare queste informazioni all'utente.

REQ-3: Un UA deve essere in grado di unirsi (anche chiamato ponte o conferenza insieme) o prendere una chiamata attiva di un altro UA nel gruppo in modo sicuro.

REQ-4: Il meccanismo dovrebbe richiedere una quantità minima di configurazione. Gli UA che si registrano all'AOR di gruppo dovrebbero essere in grado di partecipare al gruppo di apparizioni condivise senza configurazione manuale dei membri del gruppo.

REQ-5: Il meccanismo deve scalare per grandi numeri di apparizioni e grandi numeri di UA senza introdurre traffico di messaggistica eccessivo.

REQ-6: Ogni chiamata o sessione (in arrivo o in uscita) dovrebbe essere assegnata un numero "apparizione" comune da un pool gestito amministrato per il gruppo AOR. Una volta che la sessione è terminata, il numero di apparizione viene rilasciato nel pool e può essere riutilizzato da un'altra sessione in arrivo o in uscita.

REQ-7: Ogni UA nel gruppo deve essere in grado di conoscere lo stato di tutte le apparizioni del gruppo.

REQ-8: Devono esistere meccanismi per risolvere i conflitti di apparizione tra gli UA nel gruppo. Il conflitto in questo contesto significa che un numero di apparizione è associato a più dialoghi che non sono mescolati o altrimenti associati.

REQ-9: Il meccanismo deve consentire a tutti gli UA che ricevono una richiesta di sessione in arrivo di utilizzare lo stesso numero di apparizione al momento dell'allerta.

REQ-10: Il meccanismo deve avere un modo per ricostruire lo stato dell'apparizione dopo un'interruzione che non risulti in traffico e elaborazione eccessivi.

REQ-11: Il meccanismo deve avere compatibilità all'indietro in modo che un UA che non è a conoscenza della funzionalità possa ancora registrarsi all'AOR di gruppo ed effettuare e ricevere chiamate.

REQ-12: Il meccanismo non deve consentire agli UA esterni al gruppo di selezionare, occupare o manipolare i numeri di apparizione.

REQ-13: Per motivi di privacy, deve esserci un meccanismo in modo che le informazioni sull'apparizione non vengano divulgate al di fuori del gruppo di UA (ad esempio, "Allora chi hai sulla linea 1?").

REQ-14: Il meccanismo deve supportare un modo per gli UA di richiedere l'esclusività su un'apparizione di linea. L'esclusività significa che l'UA che la richiede desidera una conversazione privata con la parte esterna e agli altri UA non deve essere consentito di unirsi o prendere la chiamata. L'esclusività può essere richiesta all'inizio di una sessione in arrivo o in uscita o durante la sessione. Una richiesta di esclusività può essere accettata o rifiutata dall'entità che fornisce il servizio di apparizione condivisa. Pertanto, il meccanismo deve fornire un modo per comunicare il risultato all'UA richiedente.

REQ-15: Il meccanismo dovrebbe supportare un modo per un UA di occupare un particolare numero di apparizione per le richieste in uscita prima di inviare la richiesta effettiva. Questo è spesso chiamato occupazione (seizure).

REQ-16: Il meccanismo dovrebbe supportare un modo per un UA di occupare un particolare numero di apparizione e anche inviare la richiesta allo stesso tempo. Ciò è necessario quando una funzione di chiamata automatica (un telefono configurato per comporre immediatamente un numero di telefono quando si solleva il ricevitore) viene combinata con apparizioni condivise. In questo caso, l'occupazione della linea è integrata con la composizione.

4.2. Implementazione

Questa sezione discute in modo non normativo dell'implementazione della funzionalità di apparizioni condivise. La descrizione normativa si trova nella sezione 5. Molti dei requisiti per questo servizio possono essere soddisfatti utilizzando meccanismi SIP standard come:

• Un proxy di biforcazione SIP e un registrar/servizio di localizzazione soddisfano REQ-1.

• Il pacchetto di dialogo SIP soddisfa REQ-2.

• La combinazione dei campi di intestazione SIP Replaces e Join soddisfa REQ-3.

• L'uso di un agente di stato per il pacchetto di dialogo soddisfa REQ-4 e REQ-5.

REQ-6 suggerisce la necessità di un'entità che gestisca la risorsa di apparizione. Proprio come i sistemi di conferenza hanno comunemente un unico punto di controllo, noto come focus, un gruppo di apparizioni condivise ha un unico punto di controllo della risorsa condivisa di apparizione. Questo è definito come un agente di apparizione per un gruppo. Mentre un agente di apparizione può far parte di un server centralizzato, potrebbe anche coesistere in un UA membro che ha assunto questa funzionalità per un gruppo. L'agente di apparizione conosce o è in grado di determinare lo stato del dialogo di tutti i membri del gruppo.

Mentre la risorsa di apparizione potrebbe essere gestita cooperativamente da un gruppo di UA senza alcun controllo centrale, ciò è al di fuori dell'ambito di questo documento. È anche possibile che la logica dell'agente di apparizione possa essere distribuita in tutti gli UA nel gruppo. Ad esempio, le regole che governano l'assegnazione dei numeri di apparizione per le richieste in arrivo (ad esempio, il numero di apparizione disponibile più basso) e le regole per la gestione dei conflitti (ad esempio, quando due UA richiedono l'uso dello stesso numero di apparizione, hash degli identificatori di dialogo e confronto con l'hash più basso vincente) dovrebbero essere definite e implementate.

Per soddisfare al meglio REQ-9, il numero di apparizione per un INVITE in arrivo deve essere contenuto nell'INVITE, oltre ad essere consegnato nel NOTIFY del pacchetto di dialogo. Altrimenti, se il NOTIFY viene ritardato o perso, un UA nel gruppo potrebbe ricevere un INVITE in arrivo ma potrebbe non sapere quale numero di apparizione presentare durante l'allerta.

Questa specifica definisce un parametro di estensione, che è definito normativamente nella sezione 7, per il campo di intestazione Alert-Info in RFC 3261 per trasportare il numero di apparizione:

Alert-Info: <urn:alert:service:normal>;appearance=1

Il seguente elenco descrive il funzionamento della funzionalità di apparizioni condivise.

1. Un UA è configurato con l'AOR di un gruppo di apparizioni condivise. Si registra all'AOR, quindi tenta una sottoscrizione dello stato del dialogo all'AOR. Se la sottoscrizione fallisce, torna indietro su se stessa o restituisce un errore, sa che non c'è un agente di stato e, quindi, nessun agente di apparizione e questa funzionalità non è implementata.

2. Se la sottoscrizione riceve un 200 OK, l'UA sa che c'è un agente di stato e che la funzionalità è implementata. L'UA segue quindi i passaggi in questo elenco.

3. Le informazioni apprese sullo stato del dialogo di altri UA nel gruppo vengono presentate all'utente.

4. Le chiamate in arrivo vengono biforcate a tutti gli UA nel gruppo, e qualsiasi può rispondere. Gli UA ricevono il numero di apparizione da utilizzare per presentare la chiamata in arrivo in un NOTIFY dall'agente di apparizione e nell'INVITE stesso. L'UA riceverà anche una notifica se la chiamata viene risposta da un altro UA nel gruppo in modo che queste informazioni possano essere presentate all'utente.

5. Per le chiamate in uscita, il funzionamento dipende dall'implementazione. Se l'utente occupa un particolare numero di apparizione per la chiamata, l'UA pubblica le informazioni di dialogo dello stato di tentativo con il numero di apparizione desiderato e attende una risposta 2xx prima di inviare l'INVITE.

6. Per le chiamate in uscita, se l'utente non occupa un'apparizione particolare o non si preoccupa, l'INVITE può essere inviato immediatamente, e il numero di apparizione appreso man mano che la chiamata procede da una notifica dall'agente di apparizione.

7. Per le chiamate in uscita, se l'utente non desidera che venga assegnato un numero di apparizione (come durante una chiamata di consultazione o se un UA sta recuperando "media di servizio" come musica in attesa [RFC7088]), l'UA pubblica anche prima di inviare l'INVITE ma non include un numero di apparizione nella pubblicazione.

8. Le chiamate stabilite all'interno del gruppo possono essere unite (collegate) o prese da un altro UA. Le informazioni nelle notifiche del pacchetto di dialogo possono essere utilizzate per costruire campi di intestazione Join o Replaces. Poiché lo stesso numero di apparizione viene utilizzato per questi tipi di operazioni, queste informazioni vengono pubblicate prima di inviare l'INVITE Join o l'INVITE Replaces.

9. L'agente di apparizione potrebbe non avere accesso diretto allo stato completo del dialogo di alcuni o tutti gli UA nel gruppo. Se questo è il caso, l'agente di apparizione sottoscriverà lo stato del dialogo dei singoli UA nel gruppo per ottenere queste informazioni. In ogni caso, l'agente di apparizione invierà notifiche normali (tramite le sottoscrizioni stabilite dagli UA nel passaggio 1) ogni volta che lo stato del dialogo aggregato dell'AOR cambia, incluso quando le chiamate vengono effettuate, risposte, messe in attesa e fuori attesa, e riattaccate.