Comunicazione e collaborazione

L'importanza della voce in OCS 2007

Rajesh Ramanathan

Panoramica:

• Esecuzione di chiamate in OCS 2007
• Protezione delle chiamate
• Conversazioni multimodali in OCS
• Integrazione con Exchange UM per la segreteria telefonica

Indice

Chiamate vocali di base
Utilizzo dei numeri di telefono
Chiamate sicure
Attraversamento di NAT e firewall
Routing sui numeri di telefono
Routing in entrata
Report sulla qualità e risoluzione dei problemi
Combinazione di tutti gli elementi
Comportamento multimodale e conversazioni
Segreteria telefonica
Conclusioni

La prima parte in questa serie su Microsoft OCS (Office Communication Server) 2007 ha illustrato in che modo OCS è stato creato sui punti di forza di LCS (Live Communication Server) 2005 per offrire

capacità ottimizzate di presenza e messaggistica istantanea (MI) a livello aziendale, oltre che funzionalità avanzate per supporti e telefonica (vedere l'articolo di TechNet Magazine di febbraio 2008 in technet.microsoft.com/magazine/cc194409). In questo articolo si continua ad esaminare, con maggiore attenzione, l'aspetto VoIP (Voice over IP) della storia. Spiegherò come vengono effettuate semplici chiamate vocali nel sistema OCS e analizzerò la tecnologia, livello per livello, aggiungendo ogni componente con la corrispondente funzionalità.

Come riportato nell'articolo precedente, OCS può essere configurato per fornire la telefonia agli utenti in molte configurazioni differenti:

Enterprise Voice È una soluzione completa delle comunicazioni unificate, che utilizza OCS insieme al server Microsoft® Mediation senza richiedere PBX. Messaggistica unificata di Exchange (UM) fornisce funzioni di segreteria telefonica in questo sistema. Nella parte restante di questo articolo, farò riferimento agli utenti che dispongono di questo servizio come "utenti UC". Utilizzerò anche la definizione "endpoint UC" per fare riferimento ad un client in questa configurazione.

Enterprise Voice con integrazione PBX Questa configurazione consente agli utenti di conseguire i vantaggi delle comunicazioni unificate mantenendo i telefoni PBX esistenti sui propri desktop. Consente la configurazione di OCS e PBX in parallelo in modo che le chiamate in entrata possano giungere contemporaneamente a Office Communicator e PBX. PBX possiede, tuttavia, il routing di chiamata e fornisce i servizi di segreteria telefonica.

Controllo delle chiamate remote Questa funzione utilizza il telefono PBX come telefono primario e consente di controllare il telefono tramite il client Office Communicator.

Chiamate vocali di base

In questa sezione, porrò l'attenzione sulle attività degli utenti di Enterprise Voice. Le chiamate vocali semplici vengono configurate nel sistema OCS utilizzando il meccanismo SIP INVITE, come descritto nella RFC 3261. Il server OCS agisce come un proxy simile a un postmaster che inoltra i messaggi tra i client (o gli endpoint). Nuovi SIP INVITE vengono generati dai client ogni volta che viene creata una sessione in tempo reale, ad esempio una sessione di chiamata o di messaggistica istantanea. Se l'invito viene riconosciuto con una risposta (ovvero, se l'endpoint remoto invia una risposta 200 OK), la chiamata viene stabilita (vedere la Figura 1).

Figura 1 Formato INVITE e 200 OK

INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

Nella Figura 2, Alice chiama Roberto selezionando Chiamata Communicator da Comunicatore da OC (Office Communicator) 2007 e OC 2007 genera un invito (INVITE) all'URI (Uniform Resource Identifier) SIP di Roberto (sip:bob@example.com). L'invito (INVITE) genera a sua volta il descrittore della sessione audio (denominato SDP, ovvero Session Description Protocol) degli endpoint di supporti in cui Alice può ricevere l'audio. OCS devia l'invito (INVITE) agli endpoint SIP registrati di Roberto (ad esempio, Communicator Phone Edition e il desktop Communicator). L'invito contiene un'intestazione Mittente sip:alice@example.com che viene utilizzata dagli endpoint client di Roberto in una Ricerca inversa di nomi (RNL) per individuare il nome (Alice) da mostrare nella notifica di chiamata in entrata.

Figura 2 Routing di una chiamata a più endpoint (fare clic sull'immagine per ingrandirla)

Per ogni endpoint, viene mostrato il GRUU (Globally Routable User Agent URI). Il GRUU identifica in modo univoco un endpoint SIP e il server OCS lo ottiene durante il processo di registrazione. L'indirizzo GRUU fornisce supporto nel routing dei messaggi SIP, in modo che quando un endpoint risponde alla chiamata, è possibile effettuare una segnalazione SIP successiva per altre operazioni di interne alla chiamata tra gli endpoint utilizzando direttamente l'indirizzo GRUU.

Nella Figura 3 si continua il processo, in cui Roberto risponde dal desktop di Communicator. L'OC di Roberto invia un messaggio 200 OK in cui comunica dove può ricevere l'audio. Non appena il proxy OCS rileva che un endpoint ha risposto, annulla la chiamata agli altri endpoint di Communicator Phone Edition. Non appena la risposta 200 OK raggiunge l'endpoint Communicator di Alice, entrambi gli endpoint di Communicator dispongono di informazioni sufficienti (porte IP, parametri di crittografia e così via) per avviare i supporti.

Figura 3 Risposta da un endpoint (fare clic sull'immagine per ingrandirla)

Utilizzo dei numeri di telefono

Fino ad ora abbiamo esaminato uno scenario in cui l'utente fa clic su Chiamata Communicator per creare l'invito. Il processo è lievemente diverso quando l'utente seleziona o immette un numero di telefono:

• Il client normalizza prima il numero di telefono e lo rappresenta come un URI TEL, che descrive risorse identificate dai numeri di telefono come indicato nella RFC 3966.
• Poiché il server OCS riconosce soltanto URI SIP, i client convertono l'URI TEL in un URI SIP corrispondente aggiungendo il suffisso di dominio e una tag user=phone.
• Se il numero corrisponde ad un utente interno, OCS instrada direttamente l'invito. Se il numero è esterno, l'invito viene instradato al gateway SIP-PSTN più vicino.

Alcune chiamate a un numero PSTN (Public Switched Telephone Network) richiedono che il percorso dei supporti venga configurato prima di rispondere alla chiamata per consentire la riproduzione degli annunci remoti o l'acquisizione di cifre aggiuntive per completare la chiamata. In tali scenari, il gateway PSTN invia un indicatore 183 di avanzamento sessione con un SDP audio. Communicator utilizza queste informazioni per configurare un percorso di supporti bidirezionale con un endpoint di destinazione prima che l'utente remoto risponda alla chiamata.

Una volta configurato il percorso dei supporti, Communicator abilita il tastierino DTMF o Dual-Tone Multi-Frequency (i toni di segnalazione del telefono) per consentire all'utente di inserire eventuali cifre aggiuntive richieste dal sistema remoto. Qualunque cifra DTMF inserita viene inviata al percorso dei supporti come pacchetto RFC 2833. Il gateway PSTN si occupa di generare i segnali di tono DTMF appropriati sul lato PSTN.

Tenere presente che, se Roberto ha abilitato lo squillo simultaneo sul suo telefono cellulare, il proxy OCS instraderà la chiamata al gateway e chiamerà contemporaneamente altri endpoint Communicator di Roberto. In tali scenari, il proxy OCS indica che la deviazione è attiva nella risposta 183 di avanzamento sessione e, di conseguenza, Communicator stabilisce un canale di supporti di sola ricezione con il gateway PSTN.

Chiamate sicure

Una delle funzioni principali delle chiamate vocali configurate da OC è crittografata per impostazione predefinita utilizzando SRTP (Secure Real-Time Transport Protocol), come definito nella RFC 3711. SRTP fornisce riservatezza, autenticazione dei messaggi e protezione delle risposte al traffico RTP. Durante la configurazione delle chiamate, i client negoziano le capacità di sicurezza tra di loro e scambiano chiavi crittografiche come parte del meccanismo INVITE.

L'impostazione di crittografia predefinita per OC è "facoltativa" e consente la configurazione di un canale di supporti crittografato da parte di due endpoint OC. Tale impostazione può essere modificata dall'amministratore per soddisfare le esigenze di conformità dell'organizzazione. Ad esempio, è possibile renderla più rigida per applicare la crittografia su tutte le chiamate o disattivarla completamente.

Attraversamento di NAT e firewall

I client nel sistema OCS utilizzano la tecnologia ICE (Interactive Connectivity Establishment) per fornire connettività dei supporti agli utenti protetti da firewall e dispositivi NAT (Network Address Translation), senza richiedere alcuna modifica ai componenti di NAT esistenti. La tecnologia ICE è attualmente standardizzata da IETF (Internet Engineering Task Force). Ogni client rileva l'A/V (audio/video) Edge Server che soddisfa le sue richieste tramite un meccanismo di provisioning in banda e mantiene un collegamento autenticato ad A/V Edge durante il sign-on.

Prima di effettuare una chiamata, il client assegna le risorse sui possibili percorsi di connettività (gli indirizzi e le porte, noti anche come candidati) sull'A/V Edge Server (per l'inoltro dei supporti), su NAT o sul client host stesso. Quando viene inviato SIP (Session Initiation Protocol ) INVITE, trasmette queste informazioni di connettività come parte dell'invito. La risposta 200 OK contiene informazioni simili sui candidati relative al peer. Quando ogni endpoint contiene un elenco di candidati peer, un elaborato meccanismo di classificazione e controllo seleziona il percorso ottimale tra i due peer in cui il supporto non presenterà problemi.

Routing sui numeri di telefono

Il routing sui numeri di telefono introduce alcune complessità nel meccanismo di chiamata di base, a causa dei seguenti fattori:

• Le organizzazioni potrebbero avere piani di composizione distribuiti internamente per la composizione rapida.
• I numeri potrebbero essere memorizzati in formati non standard (ad esempio, gli utenti potrebbero aver salvato stringhe a sette cifre in Microsoft Office Outlook®).
• Potrebbero esistere criteri diversi associati ai differenti numeri in uscita. Ad esempio, è possibile che le chiamate internazionali siano bloccate per alcuni utenti.

Il sistema OCS richiede che i numeri di telefono abbiano il formato URI TEL della RFC 3966 per poter instradare tali numeri correttamente. I numeri che non presentano tale formato vengono convertiti prima che il client emetta un invito (INVITE). Nel diagramma della Figura 4 viene illustrata tale conversione all'interno del sistema OCS.

Figura 4 Routing di numeri di telefono (fare clic sull'immagine per ingrandirla)

I numeri disponibili sul client possono provenire da diverse fonti. I numeri pre-normalizzati provengono dal Servizio Rubrica, che può presentare regole di normalizzazione definite dall'amministratore per la conversione dei numeri in un formato E. 164 normalizzato. Quando il client emette un SIP INVITE al numero normalizzato, OCS applica un processo di conversione per associare il numero ad un utente interno.

• Nel passaggio 1 viene illustrato che i numeri inseriti nel sistema sono univoci (normalizzati, seguendo il piano di numerazione E. 164) o con un contesto telefonico che identifica la posizione. Tali numeri vengono inviati al server all'interno del meccanismo SIP INVITE. OCS instrada l'invito ad un processo di conversione.
• Il processo di conversione (Passaggio 2) tenta di associare il numero di telefono ad un endpoint UC tramite RNL dal lato server. La conversione può identificare un percorso per tale numero in un routing in uscita o per un utente UC o può impedire la chiamata con un codice 4xx se il numero non può essere convertito correttamente.
• Se il numero viene convertito in un numero esterno o non UC, viene inviato al componente di routing in uscita che reindirizza l'invito (INVITE) al gateway SIP-PSTN appropriato per una ulteriore elaborazione, dopo avere applicato dei criteri per il numero correlato al chiamante (Passaggio 3A). Il routing in uscita si occupa di bilanciare il carico di chiamata tra i gateway o eseguendo il failover su gateway alternativi, se necessario. Il processo di routing in uscita può impedire o rifiutare la chiamata e restituire un codice di risposta SIP 403 se l'accesso viene vietato per un determinato numero. Tenere presente che il routing in uscita applica soltanto quando il chiamante è un utente UC. Negli altri casi, OCS tenta di utilizzare percorsi statici ai gateway configurati per tale URI.
• Se il numero viene convertito in un numero dell'utente UC, l'invito (INVITE) viene instradato all'URI SIP di tale utente (Passaggio 3B). Il routing in entrata è una funzione di OCS che si applica soltanto agli utenti UC e a tutte le chiamate destinate all'URI SIP. Come mostrerò più avanti, il routing in entrata applica delle regole per i timeout di suoneria, l'inoltro di chiamate e l'inoltro della segreteria telefonica per l'utente UC.

Tenere presente che il numero derivante dal processo di normalizzazione può variare in base alla posizione del client. Gli amministratori possono configurare i profili località e assegnare regole di conversione numerica ad una determinata posizione per consentire, ad esempio, di comporre un numero a quattro cifre per tale posizione. Ad ogni utente UC è assegnato un profilo località e tutti i client nel sistema scaricano le regole specifiche per i relativi profili località utilizzando il provisioning in banda. Nella sezione successiva, esaminerò i dettagli del routing in entrata.

Routing in entrata

Le regole del routing in entrata specificano in che modo è necessario instradare le chiamate ad un utente in presenza o assenza di client registrati nel sistema. Il componente del routing in entrata si occupa anche di applicare regole basate sulla presenza alla chiamata in entrata; ad esempio, può inviare delle chiamate in entrata alla segreteria telefonica se l'utente ha impostato lo stato di presenza su Non disturbare. Il routing in entrata rileva i livelli del contenitore di presenze e respinge automaticamente le chiamate provenienti da utenti presenti in contenitori bloccati. Nella Figura 5 viene mostrato un riepilogo di opzioni supportate dal componente di routing in entrata OCS.

Figura 5 Capacità di routing in entrata

Le regole di routing in entrata vengono caricate sul server come schema XML come parte delle informazioni di provisioning automatico di un utente. Nella Figura 6 viene illustrato il funzionamento del routing in entrata. Una chiamata in entrata per un utente nel sistema OCS chiama l'utente per impostazione predefinita (mostrato come "Me"). Se non si risponde alla chiamata entro la durata dello squillo, la chiamata senza risposta viene inviata alla segreteria telefonica per impostazione predefinita. L'utente può scegliere di modificare la configurazione predefinita selezionando l'inoltro immediato ad un numero, ad un'altra persona o direttamente alla segreteria telefonica.

Figura 6 Routing di chiamate (durante le ore lavorative) (fare clic sull'immagine per ingrandirla)

Qualunque chiamata immediatamente inoltrata ad un'altra persona o numero applicherà le regole di routing in entrata per tale persona o numero. L'utente può impostare anche un inoltro delle chiamate senza risposta ad un altro numero o persona.

Se l'utente seleziona l'opzione Applica soltanto durante le ore lavorative di Outlook nelle regole di inoltro, le regole illustrate nella Figura 6 vengono applicate durante le ore lavorative e il comportamento predefinito delle chiamate agli endpoint registrati viene applicato al di fuori di tali ore. Tenere presente che questo comportamento richiede che l'organizzazione abbia distribuito i client Microsoft Exchange Server 2007 ed Outlook 2007 perché Communicator utilizza le informazioni sulle ore lavorative provenienti dal servizio Web Exchange 2007 Availability e il supporto di rilevamento automatico di Outlook 2007 per ottenere la posizione del server.

Report sulla qualità e risoluzione dei problemi

Sebbene i client del sistema OCS 2007 utilizzino RTAudio, un codec audio di nuova generazione in grado di tollerare condizioni di rete imperfette come i tremolii, la perdita di pacchetti e così via, il monitoraggio è comunque essenziale per consentire agli amministratori di individuare e riparare le potenziali aree sensibili. I client nel sistema OCS 2007 riportano la qualità di ogni chiamata e forniscono statistiche dettagliate che includono la larghezza di banda, la latenza, i tremolii, il MOS o mean opinion score (una misura della percezione dell'utente), le periferiche utilizzate e molto altro in un server QoE (Quality of Experience) centrale alla fine di ogni chiamata. Tale risultato si ottiene inviando il payload in una richiesta SIP SERVICE al server QoE, il cui indirizzo è programmato utilizzando un meccanismo di provisioning in banda.

Tenere presente che tutti gli endpoint client riportano la qualità delle chiamate al server QoE in modo indipendente. Nel caso in cui una chiamata dovesse fallire a causa di un errore nella segnalazione, i client riportano tali dati anche ad OCS, che fornisce un repository di tutti gli errori creati dai client.

Combinazione di tutti gli elementi

Dopo avere esaminato diversi aspetti della configurazione di una chiamata, incluso l'inserimento dei numeri, il routing in entrata e in uscita e i controlli di connettività, diamo un'occhiata al processo nella sua totalità. Nella Figura 7 viene riassunto l'intero processo dal momento in cui un utente effettua una chiamata. I client nel sistema OCS hanno un ruolo essenziale nella configurazione di una chiamata e gestiscono l'intero processo di configurazione della chiamata. OCS è coinvolto nel routing iniziale della chiamata, e i server edge aiutano i client a rilevare il percorso dei supporti ottimale. Diamo ora uno sguardo a ciò che succede dopo: la conversazione.

Figura 7 Flusso di chiamate end-to-end (fare clic sull'immagine per ingrandirla)

Comportamento multimodale e conversazioni

Il concetto di conversazioni è fondamentale nel sistema OCS. Una conversazione è una sessione multimodale tra due o più persone e può includere contemporaneamente voce, video e MI, oltre che elementi quali trasferimenti file durante la sessione, messaggi di posta elettronica in Outlook o note memorizzate in Microsoft Office OneNote®.

Diversi aspetti delle conversazioni possono influire sulla progettazione dei sistemi client OCS:

• Tutte le modalità coinvolte in una conversazione utilizzano la stessa finestra. Se un messaggio immediato viene aggiunto ad una conversazione audio, viene associato alla stessa finestra.
• Le conversazioni possono avvenire tra dispositivi. Gli utenti possono scegliere di avere l'audio sulla Communicator Phone Edition e la MI sul desktop di Communicator.
• Tutte le modalità eseguono contemporaneamente l'escalation ad una conferenza: Se si verifica una escalation, tutte le modalità di una conversazione devono essere sottoposte contemporaneamente ad escalation, indipendentemente dal dispositivo su cui è attiva la modalità. Ad esempio, se è disponibile una modalità audio su Communicator Phone Edition ed una modalità MI per la stessa conversazione è disponibile sul desktop di Communicator l'escalation alla conferenza garantisce che sia l'audio che la MI dispongano della stessa serie di partecipanti per tale conversazione.
• Le conversazioni e non le singole sessioni vengono registrate. I registri di chiamate contengono informazioni complete sulla conversazione, inclusi dettagli sulle note prese durante la conversazione, gli scambi di messaggi istantanei, la durata dell'audio durato e così via. Ciò fornisce una visione chiara e consolidata dell'intera conversazione agli utenti quando aprono il registro di chiamate in Outlook.
• Le conversazioni possono continuare dai registri di conversazioni. I client OCS legano le conversazioni tra di loro utilizzando un ID conversazione (ossia un numero che identifica in modo univoco la conversazione su dispositivi e applicazioni. Esiste un meccanismo elaborato per calcolare i delta delle conversazioni vengono avviate nuove conversazioni da un registro cronologico di una precedente conversazione. Lo stesso ID conversazione viene memorizzato anche come ID messaggio di posta elettronica in Outlook.

L'ID conversazione viene trasmesso all'interno del SIP INVITE come proprietà personalizzata, ovvero Ms-Conversation-Id. Nella Figura 8 viene mostrata tale transazione in cui viene prima aggiunta la voce e poi la MI. Alla fine della conversazione multimodale, il registro cronologico memorizzato in Outlook ha lo stesso ID conversazione.

Figura 8 Conversazioni multimodali e ID conversazione (fare clic sull'immagine per ingrandirla)

Exchange UM è il sistema di segreteria telefonica per OCS 2007. OCS instraderà soltanto le chiamate per utenti che supportano UC per Exchange UM. OCS fornisce diverse funzioni per l'integrazione con Exchange UM:

• L'opzione Chiama segreteria telefonica della UI del telefono di Communicator (vedere la Figura 9) consente all'utente di gestire la casella di posta UM, modificare i saluti e altro senza dover inserire il PIN perché è già autenticato.
• L'indicatore di attesa messaggio nella UI di Communicator (vedere la Figura 10) consente all'utente aprire la cartella della segreteria telefonica in Outlook mentre la UI in Communicator Phone Edition consente all'utente di riprodurre i messaggi vocali direttamente dal telefono.
• Le chiamate possono essere inoltrate alla segreteria telefonica dalla UI di Communicator.
• Le chiamate rifiutate vengono instradate automaticamente alla segreteria telefonica.
• L'opzione Ascolta al telefono della segreteria telefonica in Outlook chiama direttamente i client di Office Communicator.

Figura 9 Opzione Chiama segreteria telefonica in Communicator

Figura 10 Indicatore di attesa messaggio in Communicator

Il meccanismo con cui OC riceve la notifica della segreteria telefonica è diverso da quello di Communicator Phone Edition. OC registra le nuove notifiche di posta nella cartella di ricerca della segreteria telefonica in Outlook e riporta i nuovi messaggi in questa cartella. Communicator utilizza anche Conversazioni non effettuate e Registri chiamate.

Conclusioni

In questa sezione ho illustrato il funzionamento delle chiamate vocali in OCS 2007, un sistema creato su SIP che utilizza diverse RFC. Gli endpoint client hanno un ruolo centrale nella gestione delle chiamate in OCS. Tutte le chiamate vocali sono crittografate in modo sicuro per impostazione predefinita. OCS fornisce dei componenti flessibili per consentire la gestione dei numeri e del relativo flusso in tutto il sistema.

Le conversazioni sono un concetto fondamentale in OCS, poiché coinvolgono voce, MI e video. OCS si integra con Exchange UM e consente di inviare notifiche relative alla segreteria telefonica agli endpoint di Communicator e di accedere a tale segreteria da Outlook o direttamente dal server.

Rajesh Ramanathan lavora nelle comunicazioni da 14 anni e ha progettato protocolli vocali, procedure per l'utente e strumenti per voce e conferenze per Office Communicator 2007. È possibile contattarlo all'indirizzo rajeshra@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.