Ivan Salvade’

Il mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    novembre 2017
    L M M G V S D
    « gen    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Tag Cloud

Archivi per la categoria 'Lync Server 2010' Categoria


Creazione di un IVR (Response Group) a più livelli in Lync Server 2010

Scritto da Ivan Salvade' il 5 luglio 2013

In Lync Server 2010, è possibile creare un IVR (Interactive Voice Response) tramite strumenti grafici oppure tramite comandi di powershell.

Il limite imposto dall’uso degli strumenti grafici è quello di poter creare solo 2 domande con un massimo di 4 risposte possibili per ogni domanda.

Se si volesse aumentare il numero delle domande e/o il numero delle risposte, non sarebbe più possibile utilizzare gli strumenti grafici, ma diventerebbe obbligatorio ricorrere ai comandi powershell.

Un IVR creato con comandi powershell, non è più editabile con gli strumenti grafici.

In questo articolo illustrerò come creare un intero IVR con una sola domanda, ma 6 risposte possibili, utilizzando comandi powershell.

La creazione di questo IVR potrà essere presa come esempio per creare IVR contenenti qualunque numero di domande e/o qualunque numero di risposte per ogni domanda.

L’architettura generale del mio IVR di esempio sarà la seguente :

  • Arriva una chiamata ad un numero aziendale associato al IVR
  • Il sistema verifica il giorno e l’orario di ricezione della chiamata, effettuando le seguenti scelte :
    • se la chiamata giunge in un giorno festivo, viene riprodotto un messaggio ”Call Center chiuso per festività”, e la chiamata è terminata
    • se la chiamata giunge in giorni feriali, ma al di fuori degli orari di lavoro, viene riprodotto un messaggio “Call Center chiuso, si prega di richiamare in orari di lavoro”, e la chiamata è terminata
    • se la chiamata giunge in giorni feriali e in orari di lavoro, viene riprodotto un messaggio di benvenuto, e il chiamante è invitato a scegliere una delle seguenti opzioni :
      • digitare 1 per parlare col reparto Vendite
      • digitare 2 per parlare col reparto Amministrazione
      • digitare 3 per parlare col reparto Assistenza Tecnica
      • digitare 4 per parlare col reparto Produzione
      • digitare 5 per parlare col reparto IT
      • digitare 6 per parlare col Centralino (Operatore)
  • In base alle scelte del chiamante, la chiamata è rediretta ad una delle code ”Vendite”, “Amministrazione”, “Assistenza”, “Produzione”, “IT”, “Operatore”, dove risponderanno gli operatori associati a quella determinata coda

I comandi utili alla creazione del IVR sono i seguenti :

New-CsRgsAgentGroup

New-CsRgsAnswer

New-CsRgsCallAction

New-CsRgsHoliday

New-CsRgsHolidaySet

New-CsRgsHoursOfBusiness

New-CsRgsTimeRange

New-CsRgsPrompt

New-CsRgsQuestion

New-CsRgsQueue / Get-CsRgsQueue / Set-CsRgsQueue

New-CsRgsWorkflow / Set-CsRgsWorkflow

Set-CsRgsConfiguration

Import-CsRgsAudioFile

Le operazioni da eseguire sono le seguenti, nel preciso ordine indicato :

  1. Creazione dei Gruppi di Agenti (i vari operatori interni che risponderanno alle chiamate)
  2. Creazione delle Code (mantengono in coda i chiamanti, finchè un agente non risponderà)
  3. Creazione delle Business Hours (ore di lavoro in cui gli agenti sono disponibili)
  4. Creazione degli Holidays (giornate in cui gli agenti non sono disponibili)
  5. Creazione degli Holiday Set (raggruppano gli Holidays, in modo da poterli associare più comodamente al IVR)
  6. Creazione dei Prompt (messaggi vari da riprodurre ai chiamanti)
  7. Creazione delle Azioni (operazioni da eseguire in base alle scelte/comportamenti dei chiamanti)
  8. Configurazione delle Azioni di Timeout e Overflow nelle Code
  9. Creazione delle Risposte (per comprendere le scelte dei chiamanti, e lanciare le Azioni corrispondenti)
  10. Creazione delle Domande (domande poste dal IVR ai chiamanti, per permettere loro di esercitare una scelta)
  11. Creazione della Default Action del Workflow (azione da eseguire se la chiamata al IVR giunge in orari di lavoro)
  12. Creazione del Workflow (il flusso di lavoro finale, completo di domande, risposte, azioni e interconnessioni tra di loro)

Nei seguenti comandi esemplificativi, si suppone che il server Lync di Front-End con il servizio RGS si chiami FE.contoso.com

N.B. : la maggioranza dei comandi seguenti memorizza i risultati in diverse variabili.  Le variabili sono create per poter essere poi utilizzate in comandi successivi.  Le variabili risiedono sempre in RAM, e verrebbero cancellate nel caso si chiudesse la sessione di Lync Powershell ove si stanno digitando i comandi.  Tenere quindi sempre aperta la powershell, altrimenti si perde l’intero lavoro eseguito fino a quel momento.

N.B. : legenda dei comandi :

in grassetto sono indicati i Cmdlet e i parametri, in corsivetto sono indicati i valori da inserire, che possono variare a scelta degli amministratori.  Con la dicitura “(oppure…. ” sono indicate variazioni possibili dei valori dei parametri

Creazione dei Gruppi di Agenti

Ogni gruppo conterrà le utenze abilitate a rispondere per conto di un certo reparto scelto dai chiamanti (Vendite, Produzione, ecc..).

I gruppi di agenti possono anche essere creati nella console di Gestione grafica di Lync.  Il comando powershell per la creazione dei gruppi è “New-CsRgsAgentGroup”, dotato di diversi parametri.

Con il parametro ”-RoutingMethod” si indica la modalità di instradamento delle chiamate alla coda : nel mio esempio ho scelto il valore “Parallel”, che instrada le chiamate contemporaneamente a tutti gli agenti di un certo gruppo (che siano disponibili e non già occupati o fuori linea).

Un parametro non usato nei miei esempi sottostanti, cioè il parametro “-AgentAlertTime”, permette di decidere quanto deve squillare il telefono degli operatori, prima di passare all’eventuale operatore successivo.  Il suo valore di default è 20 secondi.

Ecco i comandi per creare i 6 gruppi necessari al mio IVR esemplificativo :

$GruppoVendite=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoVendite  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserVendite1@contoso.com”,”sip:UserVendite2@contoso.com“)

$GruppoAmministrazione=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoAmministrazione  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserAmm1@contoso.com”,”sip:UserAmm2@contoso.com“)

$GruppoAssistenza=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoAssistenza  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserAss1@contoso.com”,”sip:UserAss2@contoso.com“)

$GruppoIT=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoIT  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserIT1@contoso.com”,”sip:UserIT2@contoso.com“)

$GruppoProduzione=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoProduzione  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserProd1@contoso.com”,”sip:UserProd2@contoso.com“)

$GruppoOperatore=New-CsRgsAgentGroup -Parent “Service:ApplicationServer:FE.contoso.com-Name GruppoOperatore  -ParticipationPolicy Informal (oppure Formal) -RoutingMethod Parallel (oppure LongestIdle, RoundRobin, Serial, Attendant) -AgentsByUri (”sip:UserOperatore1@contoso.com”,”sip:UserOperatore2@contoso.com“)

Creazione delle Code

Per ogni gruppo di operatori, deve esistere una coda di attesa, nella quale vengono inseriti i chiamanti in attesa della risposta da parte di qualche operatore.

Anche le code possono essere create nella console grafica di Lync.  Per chi preferisse utilizzare powershell, il comando per la creazione è “New-CsRgsQueue”, dotato di diversi parametri.

Nei miei esempi sottostanti, ho utilizzato solo i parametri strettamente indispensabili (”-Name” e “-AgentGroupIDList”), ma ne esistono altri :

  • -TimeoutThreshold : quantità di tempo (in secondi) che una chiamata può rimanere in coda senza risposta, prima che si verifichi il Timeout.  A quel punto, l’IVR eseguirà l’azione stabilita dal parametro -TimeoutAction. Per default, non ci sono timeout relativi alle chiamate
  • -TimeoutAction : azione da eseguire se venisse raggiunta la soglia di timeout.  L’azione deve essere creata con il cmdlet “New-CsRgsCallAction” (vedi sezioni successive), e il default prevede l’azione “Terminate”
  • -OverflowThreshold : numero massimo di chiamate inseribili in una coda.  Se venisse raggiunto questo numero, sarebbe eseguita l’azione specificata dal parametro -OverflowAction.  Per default, non ci sono limiti.
  • -OverflowAction : azione da eseguire se venisse raggiunta la soglia di overflow. L’azione deve essere creata con il cmdlet “New-CsRgsCallAction” (vedi sezioni successive), e il default prevede l’azione “Terminate”
  • -OverflowCandidate : indica su quale chiamata agire se si raggiunge l’overflow di coda.  Le opzioni possibili sono “NewestCall” e “OldestCall”.  Per default, l’impostazione è “NewestCall”

Ecco i comandi per creare le 6 code necessarie al mio IVR esemplificativo :

$CodaVendite=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaVendite” -AgentGroupIDList ($GruppoVendite.Identity)

$CodaAmministrazione=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaAmministrazione” -AgentGroupIDList ($GruppoAmministrazione.Identity)

$CodaAssistenza=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaAssistenza” -AgentGroupIDList ($GruppoAssistenza.Identity)

$CodaIT=New-CsRgsQueue -Parent “Service:ApplicationService:FE.contoso.com-Name “CodaIT” -AgentGroupIDList ($GruppoIT.Identity)

$CodaProduzione=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaProduzione” -AgentGroupIDList ($GruppoProduzione.Identity)

$CodaOperatore=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com-Name “CodaOperatore” -AgentGroupIDList ($GruppoOperatore.Identity)

Creazione delle Business Hours

Servono a definire le ore di lavoro in cui il Contact Center è attivo (e quindi gli agenti sono disponibili).

Prima di creare le Business Hours, è necessario specificare i precisi intervalli di tempo nei quali l’IVR è effettivamente attivo (per esempio, dalle 09.00 alle 13.00 e dalle 14.00 alle 18.00).  Questa operazione si esegue utilizzando il cmdlet “New-CsRgsTimeRange” :

$AperturaMattina=New-CsRgsTimeRange -Name OrarioMattina -OpenTime “09:00″ -CloseTime “13:00″

$AperturaPomeriggio=New-CsRgsTimeRange -Name OrarioPomeriggio -OpenTime “14:00″ -CloseTime “18:00″

Se l’orario di apertura fosse continuo (es. dalle 08:00 alle 22:00), sarebbe sufficiente uno solo dei comandi precedenti.

Poi si crea l’effettivo oggetto “Business Hours”, nel quale si indicano anche le giornate precise di apertura, utilizzando il comando “New-CsRgsHoursOfBusiness”.

Questo comando ha un doppio parametro per ogni giorno della settimana : per esempio, MondayHours1 e MondayHours2 per il lunedì, TuesdayHours1 e TuesdayHours2 per il martedì, e via dicendo fino alla domenica.

E’ necessario utilizzare entrambi i parametri di ogni giornata se il turno di apertura è spezzato, mentre è sufficiente utilizzare solo il primo dei parametri di giornata (MondayHours1, TuesdayHours1, WednesdayHours1….) se il turno di apertura è continuo.

Se in alcune giornate il Call Center è totalmente chiuso, non indicare i parametri per quelle giornate.

Ecco il comando per creare gli orari di apertura spezzati, da lunedì a venerdì, per il mio IVR esemplificativo :

$AperturaIVR=New-CsRgsHoursOfBusiness -Parent “Service:ApplicationServer:FE.Contoso.com-Name IVRBusinessHours -MondayHours1 $AperturaMattina -MondayHours2 $AperuraPomeriggio -TuesdayHours1 $AperturaMattina -TuesdayHours2 $AperuraPomeriggio -WednesdayHours1 $AperturaMattina -WednesdayHours2 $AperuraPomeriggio -ThursdayHours1 $AperturaMattina -ThursdayHours2 $AperuraPomeriggio -FridayHours1 $AperturaMattina -FridayHours2 $AperuraPomeriggio

Creazione degli Holidays e degli Holiday Set

Al Response Group è necessario indicare tutte le giornate di festività nazionali.  Alle chiamate che perverranno in queste giornate, verrà riprodotto un messaggio del tipo “Call Center chiuso per festività”.   Ogni giornata festiva deve essere dichiarata con il comando “New-CsRgsHoliday”.  In questo esempio, ecco la dichiarazione di tutte le giornate festive italiane relative all’anno 2014 :

N.B. : il formato della data nei comandi seguenti dipende dalle impostazioni internazionali e dalla lingua del vostro server.  Se tutto è impostato sulle preferenze italiane, allora il formato data è esattamente quello riportato.  Se avete un server in inglese con le opzioni regionali impostate sul modello statunitense, giorno e mese devono essere invertiti.

$capodanno = New-CsRgsHoliday -Name “capodanno” -StartDate “01/01/2014″ -EndDate “02/01/2014″
$25aprile = New-CsRgsHoliday -Name “25aprile” -StartDate “25/04/2014″ -EndDate “26/04/2014″
$1maggio = New-CsRgsHoliday -Name “1maggio” -StartDate “01/05/2014″ -EndDate “02/05/2014″
$2giugno = New-CsRgsHoliday -Name “2giugno” -StartDate “02/06/2014″ -EndDate “03/06/2014″
$15agosto = New-CsRgsHoliday -Name “ferragosto” -StartDate “15/08/2014″ -EndDate “16/08/2014″
$1nov = New-CsRgsHoliday -Name “1novembre” -StartDate “01/11/2014″ -EndDate “02/11/2014″
$8dic = New-CsRgsHoliday -Name “8dicembre” -StartDate “08/12/2014″ -EndDate “09/12/2014″
$natale = New-CsRgsHoliday -Name “natale” -StartDate “25/12/2014″ -EndDate “27/12/2014″
$pasqua = New-CsRgsHoliday -Name “pasqua” -StartDate “20/04/2014″ -EndDate “22/04/2014″

Le giornate festive devono poi essere raccolte in un “set” di festività, che più avanti verrà agganciato al workflow finale.  La creazione del set di festività si esegue con il comando “New-CsRgsHolidaySet” :

$FestiviIVR=New-CsRgsHolidaySet -Parent “Service:ApplicationServer:FE.contoso.com-Name Feste2014 -HolidayList ($capodanno,$25aprile,$1maggio,$2giugno,$15agosto,$1nov,$8dic,$natale,$pasqua)

In ogni anno seguente, l’elenco delle festività dovrà essere aggiornato, inserendo quelle nuove ed agganciandole al workflow.

Creazione dei Prompt

Si tratta di file audio da riprodurre (oppure stringhe di testo letti da una voce robotica), utili allo scopo di fornire informazioni aggiuntive ai chiamanti (per es. “Benvenuti al Call Center di Contoso” oppure “Attendere in linea mentre la mettiamo in contatto con il reparto vendite”, oppure “Gli uffici sono chiusi. La preghiamo di richiamare tra le 08.00 e le 18.00″ …).

La procedura di creazione varia a seconda che si utilizzino files audio preregistrati, oppure stringhe di testo che la voce automatica dovrà leggere.

Nel mio IVR esemplificativo, suppongo di voler utilizzare i seguenti Prompt :

  • Prompt di benvenuto al Call Center (da riprodurre negli orari di apertura del Call Center; contiene la domanda principale del IVR)
  • Prompt di Call Center chiuso per festività (da riprodurre nei festivi)
  • Prompt di Call Center fuori orario di lavoro (da riprodurre negli orari di chiusura del Call Center)
  • Prompt di attesa (da riprodurre quando i chiamanti vengono messi in attesa in coda di risposta)
  • Prompt di risposta sbagliata (da riprodurre quando i chiamanti digitano una risposta sbagliata, cioè non compresa tra 1 e 6)
  • Prompt di risposta assente (da riprodurre quando i chiamanti non indicano risposte alla domanda del IVR)
  • Prompt di coda in overflow o tempo di attesa troppo lungo (da riprodurre se la coda a cui è rediretto un chiamante è già satura, oppure gli operatori non rispondono al chiamante entro una certa tempistica)

Ho deciso di pre-registrare nei files .WAV i primi quattro prompt, e di utilizzare un Text-to-Speech per gli ultimi tre prompt.  Questa scelta ha unicamente lo scopo di farvi vedere la creazione di entrambi i tipi di Prompt : voi potreste optare per l’utilizzo unico di files audio, per esempio.

N.B. : per evitare un errore del IVR con codice evento 31117 e una descrizione simile a questa :

(System.ArgumentNullException: Value cannot be null. Parameter name: alternateText at Microsoft.Speech.Synthesis.PromptBuilder.AppendAudio(Uri audioFile, String alternateText)

… è necessario inserire un Text-to-Speech anche nei prompt nei quali intendete utilizzare una registrazione audio.  Il Text-to-Speech verrà utilizzato solo se il file audio dovesse risultare corrotto e non riproducibile.

Cominciamo a creare i quattro prompt basati su voci preregistrate.  I files WAV devono essere posizionati in una cartella del Front-End (es. “C:\AudioFiles”). Si utilizzano poi i comandi “Import-CsRgsAudioFile” e “New-CsRgsPrompt” per la creazione dei prompt :

$AudioBenvenuto=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptBenvenuto.wav -Content (Get-Content C:\Audiofiles\PromptBenvenuto.wav” -Encoding Byte -ReadCount 0)

$PromptBenvenuto=New-CsRgsPrompt -AudioFilePrompt $AudioBenvenuto -TextToSpeechPrompt “messaggio di benvenuto e proposizione della prima domanda di scelta”

$AudioFesta=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptFesta.wav -Content (Get-Content C:\Audiofiles\PromptFesta.wav” -Encoding Byte -ReadCount 0)

$PromptFesta=New-CsRgsPrompt -AudioFilePrompt $AudioFesta -TextToSpeechPrompt “Siamo chiusi per festività. Si prega di richiamare in giornate feriali”

$AudioChiusura=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptChiusura.wav -Content (Get-Content C:\Audiofiles\PromptChiusura.wav” -Encoding Byte -ReadCount 0)

$PromptChiusura=New-CsRgsPrompt -AudioFilePrompt $AudioChiusura -TextToSpeechPrompt “In questo momento siamo chiusi. Si prega di richiamare in orari di lavoro”

$AudioAttesa=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptAttesa.wav -Content (Get-Content C:\Audiofiles\PromptAttesa.wav” -Encoding Byte -ReadCount 0)

$PromptAttesa=New-CsRgsPrompt -AudioFilePrompt $AudioAttesa -TextToSpeechPrompt “Siete pregati di rimanere in attesa della risposta degli operatori”

Ora creiamo i Prompt basati su stringhe di testo (Text-to-Speech : ci penserà la voce robotica di Lync a leggere la stringa ai chiamanti) :

$PromptErroreScelta=New-CsRgsPrompt -TextToSpeechPrompt “La risposta non è tra quelle consentite. Si prega di correggere la selezione”

$PromptNessunaScelta=New-CsRgsPrompt -TextToSpeechPrompt “Non è stata digitata alcuna scelta. Si prega di riprovare”

$PromptOverflow=New-CsRgsPrompt -TextToSpeechPrompt “In questo momento il Call Center è sovraccarico. Si prega di riprovare più tardi”

Creazione delle Azioni

Le Azioni rappresentano le operazioni che l’IVR deve eseguire all’accadimento di un certo evento. Esempi possono essere :

  • azione da eseguire se giunge al IVR una chiamata in giorni festivi
  • azione da eseguire se giunge al IVR una chiamata fuori orari di lavoro
  • azione da eseguire se giunge al IVR una chiamata in orario di lavoro
  • azione da eseguire se il chiamante esercita una certa scelta in risposta ad una domanda del IVR
  • azione da eseguire se un chiamante viene inserito in una coda che risulta già piena (overflow di coda)
  • azione da eseguire se un operatore non risponde ad un chiamante entro una certa tempistica (time-out di coda)

Le azioni si creano con il cmdlet New-CsRgsCallAction.  Il suo parametro più importante è “-Action“, che può avere i seguenti valori :

  • Terminate : termina direttamente la chiamata
  • TransferToQueue : trasferisce una chiamata alla coda specificata
  • TransferToQuestion : trasferisce una chiamata ad una domanda successiva posta dal IVR
  • TransferToURI : trasferisce una chiamata ad uno specifico SIP URI
  • TransferToVoiceMailURI : trasferisce una chiamata ad una segreteria telefonica (es. Exchange Unified Messaging)
  • TransferToPSTN : trasferisce una chiamata ad un numero telefonico PSTN (rete pubblica)

Si crea l’azione da eseguire se giunge una chiamata in giornate festive :

$AzioneFesta=New-CsRgsCallAction -Prompt $PromptFesta -Action Terminate

Si crea l’azione da eseguire se giunge una chiamata in orari di chiusura del Call Center :

$AzioneChiusura=New-CsRgsCallAction -Prompt $PromptChiusura -Action Terminate

Si crea l’azione da eseguire se la coda a cui è rediretto il chiamante è piena, oppure se gli operatori non rispondono al chiamante entro una certa tempistica (parametri impostabili nelle proprietà delle code) :

$AzioneOverflow=New-CsRgsCallAction -Prompt $PromptOverflow -Action Terminate

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 1 :

$Azione1=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaVendite.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 2 :

$Azione2=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaAmministrazione.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 3 :

$Azione3=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaAssistenza.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 4 :

$Azione4=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaProduzione.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 5 :

$Azione5=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaIT.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Si crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 6 :

$Azione6=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaOperatore.Identity    (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)

Configurazione delle Azioni di Timeout e Overflow nelle Code

Ora che abbiamo creato tutte le azioni possibili, è possibile tornare sulle Code (già create precedentemente) per agganciare loro l’azione di Overflow/Timeout (cioè l’azione da eseguire se le code dovessero già essere piene e/o se gli operatori non rispondono entro il tempo di timeout impostato nelle code stesse).

Ecco i comandi per impostare l’azione di Overflow/Timeout sulle code (queste sono ancora memorizzate nelle variabili utilizzate nella sezione di creazione delle code) :

N.B. : il comando Set-CsRgsQueue serve a fissare definitivamente nel Front-End di Lync le modifiche sulle code.  Fino a quel momento, le modifiche risiedono esclusivamente in memoria (nelle variabili).

$CodaVendite.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaVendite

$CodaAmministrazione.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaAmministrazione

$CodaAssistenza.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaAssistenza

$CodaIT.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaIT

$CodaProduzione.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaProduzione

$CodaOperatore.OverflowAction=$AzioneOverflow

Set-CsRgsQueue -Instance $CodaOperatore

Creazione delle Risposte

Le Risposte devono essere create per permettere al IVR di comprendere la risposta digitata o pronunciata da un chiamante, ed eseguire le opportune azioni.  Per esempio, l’IVR deve capire se l’utente ha composto il numero 1 per scegliere la prima opzione (oppure se ha enunciato la parola “uno”), e in quel caso eseguire l’azione prevista per questa opzione.

Le Risposte si creano con il comando “New-CsRgsAnswer”.  I suoi parametri più importanti sono :

  • -DTMFResponse : indica il tasto da premere sul tastierino da parte del chiamante, per esercitare una scelta
  • -VoiceResponseList : indica la parola da enunciare da parte del chiamante, per esercitare una scelta
  • -Action : indica l’azione da eseguire.  Questa deve essere già stata creata con il comando New-CsRgsCallAction (vedi sezione precedente)

N.B. : non è obbligatorio inserire entrambi i parametri “-DTMFResponse” e “-VoiceResponseList” : è sufficiente almeno uno dei due.

Creiamo ora tutte le Risposte necessarie ad intercettare le varie opzioni di scelta (da 1 a 6) del mio IVR esemplificativo :

$Risposta1=New-CsRgsAnswer -DTMFResponse 1 -VoiceResponseList “uno” -Action $Azione1

$Risposta2=New-CsRgsAnswer -DTMFResponse 2 -VoiceResponseList “due” -Action $Azione2

$Risposta3=New-CsRgsAnswer -DTMFResponse 3 -VoiceResponseList “tre” -Action $Azione3

$Risposta4=New-CsRgsAnswer -DTMFResponse 4 -VoiceResponseList “quattro” -Action $Azione4

$Risposta5=New-CsRgsAnswer -DTMFResponse 5 -VoiceResponseList “cinque” -Action $Azione5

$Risposta6=New-CsRgsAnswer -DTMFResponse 6 -VoiceResponseList “sei” -Action $Azione6

Creazione delle Domande (nel mio esempio, una sola domanda)

La domanda da creare sarà quella (posta dal IVR) in cui viene chiesto ai chiamanti di scegliere le opzioni da 1 a 6.  Dopo la domanda, il sistema dovrà aspettare la risposta del chiamante, e poi eseguire l’azione appropriata.  La domanda si crea con il comando “New-CsRgsQuestion”.  A questo comando è necessario fornire almeno un Prompt (già creati precedentemente, che rappresentano la registrazione audio della domanda o il Text-to-Speech della stessa), e un gruppo di risposte supportate (già create precedentemente, che intercettano le risposte del chiamante ed eseguono le azioni previste in base alla scelta effettuata).  E’ possibile anche indicare un Prompt da utilizzare nel caso di risposte errate da parte del chiamante (per esempio se dovesse digitare 7, valore non compreso tra quelli possibili), e un Prompt da utilizzare nel caso di mancata risposta da parte del chiamante.

$Domanda1=New-CsRgsQuestion -Prompt $PromptBenvenuto -AnswerList $Risposta1,$Risposta2,$Risposta3,$Risposta4,$Risposta5,$Risposta6  -InvalidAnswerPrompt $PromptErroreScelta -NoAnswerPrompt $PromptNessunaScelta

Creazione della Default Action del Workflow

La “Default Action” del IVR è l’azione che deve essere eseguita quando giunge una chiamata negli orari di apertura del Call Center.  La Default Action deve semplicemente indicare al IVR di porre al chiamante la prima domanda contenente il primo livello di scelte (nel mio esempio, questa sarà anche l’unica domanda del IVR) :

$AzioneDefault=New-CsRgsCallAction -Action TransferToQuestion -Question $Domanda1

Creazione del Workflow finale

Ora siamo pronti ad inserire tutti gli oggetti creati nel Workflow finale, che darà vita al IVR vero e proprio.

Il Workflow si crea con il comando “New-CsRgsWorkflow”.  Eventuali successive interrogazioni/modifiche del workflow possono essere eseguite con l’utilizzo congiunto dei comandi “Get-CsRgsWorkflow” e “Set-CsRgsWorkflow”.

I parametri più importanti del comando “New-CsRgsWorkflow” sono i seguenti :

  • -LineURI : indica il numero di telefono a cui è raggiungibile il Call Center dall’esterno
  • -Active : indica se il Call Center deve essere subito attivo ($True) oppure no ($False)
  • -Anonymous : rende anonimi gli operatori che rispondono ($True) oppure visibili ($False)
  • -BusinessHoursID : indica gli orari di apertura del IVR (in questa caso verrà riprodotta la “Default Action”)
  • -DefaultAction : azione da eseguire in orari di apertura.  L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction (vedi sezione precedente), e deve contenere un’azione di trasferimento (TransferToQuestion) alla prima domanda del IVR ($Domanda1 nel mio esempio)
  • -NonBusinessHoursAction : azione da eseguire in orari di chiusura.  L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction
  • -HolidayAction : azione da eseguire in giornate festive. L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction

$Workflow=New-CsRgsWorkflow -Parent “Service:ApplicationServer:FE.contoso.com” -Name “IVR aziendale” -Description “Il Call Center dell’azienda XXX” -PrimaryURI “sip:IVR@contoso.com” -LineURI “tel:+3902123456″ -DisplayNumber “0039 02 123456″ -Active $True -Anonymous $True -BusinessHoursID $AperturaIVR.identity -HolidaySetIDList $FestiviIVR.identity -HolidayAction $AzioneFesta -NonBusinessHoursAction $AzioneChiusura -DefaultAction $AzioneDefault -CustomMusicOnHoldFile $AudioAttesa

Set-CsRgsWorkflow -Instance $Workflow

L’ultimo comando mette in effettiva “produzione” l’intero workflow : supponendo il corretto inserimento del numero di telefono per raggiungere l’IVR (parametro -LineUri del workflow) e la corretta configurazione dei componenti Enterprise Voice di Lync Server (Dial Plans, Voice Policy, Routes, Trunk, integrazione con un Gateway IP), l’IVR è già da ora pronto all’uso.

Buon Call Center!!! :-)

  • Share/Bookmark

Pubblicato in Lync Server 2010 | 2 Commenti »

Novità nella versione 4.2 di Lync 2010 Client per Ipad

Scritto da Ivan Salvade' il 25 giugno 2012

Il Lync client per Ipad è recentemente stato aggiornato alla sua versione 4.2 (secondo iTunes) o 1.5 (secondo Microsoft).

La nuova versione è gratuitamente scaricabile da iTunes dal 22 giugno 2012.

Un’ottima novità contenuta in questa nuova release è la possibilità di vedere le presentazioni Powerpoint condivise da un relatore (o da un partecipante) durante un meeting Lync schedulato; è inoltre possibile vedere anche la lista dei partecipanti ed essere avvisati se il relatore condivide altri tipi di contenuto durante la sessione.

Per poter sfruttare questa novità, è necessario installare sui server Lync il “Lync Server 2010 Cumulative Update for June 2012″, disponibile in download al seguente link :

http://support.microsoft.com/?kbid=2493736

Quando ci si collega al meeting da Ipad, si riceve la richiesta di connettersi alla porzione audio del meeting utilizzando il numero configurato per la tecnica Call-Via-Work.  Questo è un numero PSTN di callback a cui si viene richiamati. 

Dopo aver accettato la richiamata, è possibile visualizzare subito le presentazioni condivise da qualunque partecipante al meeting.  E’ possibile visualizzarle anche a schermo intero con un tap.

Ed ora… aspettiamoci magari anche l’inserimento della parte video in qualche futura release :-)

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Problema con il comando Test-CsMcxP2PIM e Lync Server 2010 Mobility Service

Scritto da Ivan Salvade' il 16 aprile 2012

N.B. : questo articolo è stato aggiornato in data 18 aprile 2012.  Gli aggiornamenti sono indicati in rosso in calce all’articolo.

Sono disponibili  ”Mobility Service” e ”Autodiscover Service” per Lync Server 2010, che permettono agli utenti di sfruttare dispositivi mobili come Windows Phone, Nokia, Android, iPAD, iPhone per utilizzare buona parte delle caratteristiche di Lync Server 2010 (es. chat, presenza, unione a conferenze e alcune delle features di VoIP).   I servizi di mobilità e autodiscover sono scaricabili al seguente link :

http://www.microsoft.com/download/en/details.aspx?id=28356

La guida per l’installazione è al seguente link :

http://www.microsoft.com/download/en/details.aspx?id=28355

Quando si installa il “Lync Server 2010 Mobility Service” e il “Lync Server 2010 Autodiscover Service” su un server Front-End di un’infrastruttura Lync, si può eseguire un test del corretto deployment utilizzando il comando di powershell Test-CsMcxP2PIM, che verifica l’abilità di due utenti a scambiarsi messaggi istantanei utilizzando il Mobility Service.   La procedura corretta da utilizzare è la seguente :

Memorizzare le credenziali di due utenze in due variabili (per es. $SenderCred e $ReceiverCred) :

  • $Cred1=Get-Credential  (inserire le credenziali nel popup grafico)
  • $Cred2=Get-Credential  (inserire le credenziali nel popup grafico)

Ora eseguire il seguente comando :

Test-CsMcxP2PIM -TargetFQDN nome_FrontEnd_pool_interno -SenderSipAddress “sip:utente1@dominio_SIP” -SenderCredential $Cred1 -ReceiverSipAddress “sip:utente2@dominio_SIP” -ReceiverCredential $Cred2 -verbose

Ecco in Fig. 1 il comando eseguito su un Front-End (sono opportunamente nascosti i nomi di dominio e degli utenti) :

2tck.JPG      Fig. 1

E’ possibile che il comando restituisca il seguente errore (Fig. 2) :

3tck.JPG      Fig. 2

Ci possono essere diverse cause per questo errore : una (già capitata) è la risoluzione in IPv6 dell’indirizzo IP del server Front-End.  Lync Server 2010 non supporta IPv6, e quindi dovrebbe essere disabilitato sui server con ruoli Lync installati.

Un’altra casistica in cui capita questo errore (e sotto indagine da parte di MS), è quando abbiamo un server con multiple schede di rete e con i ruoli Front-End e Mediation collocati assieme.  Se nella topologia Lync abbiamo indicato di separare gli indirizzi IP usati dai servizi di Front-End e dai servizi di Mediation (Fig. 3), allora capita l’errore di Fig. 2 :

7tck.JPG     Fig. 3

Questo è dovuto al fatto che il FQDN del Front-End non viene risolto nel corretto indirizzo IP primario (nel mio caso 10.0.10.12), e quindi IIS nega la connessione ai suoi servizi.  Infatti, un ulteriore problema che compare, è l’impossibilità ad accedere al Lync Control Panel (Fig. 4) :

9tck.JPG      Fig. 4

Se controlliamo IIS in questa casistica, il binding di “Lync Server Internal Web Site” è impostato proprio su singolo indirizzo IP (nel mio caso 10.0.10.12) e non su “All unassigned” (Fig. 5) :

1tck.JPG      Fig. 5

Abbiamo due modi per risolvere il problema : inserire una mappatura statica nel file Hosts del Front-End, oppure modificare in “All Unassigned” il binding https di Lync Server Internal Web Site.  Il metodo meno invasivo è sicuramente la mappatura nel file Hosts (Fig. 6) :

8tck.JPG      Fig. 6

L’altra soluzione è illustrata in Fig. 7 :

4tck.JPG      Fig. 7

Dopo la modifica del binding in IIS, ricordarsi di restartare i servizi IIS (o almeno il Lync Server Internal Web Site).

Entrambe le soluzioni portano ai risultati desiderati, ovvero la possibilità di riaccedere al Lync Control Panel e la corretta esecuzione del comando Test-CsMcxP2PIM (Fig. 8 ) :

5tck.JPG      Fig. 8

In Fig. 9 ho indicato l’esito “verbose” del comando :

6tck.JPG      Fig. 9

Se ancora dovessero sussistere gli errori, ricordate di disabilitare IPv6 sui server Front-End.

Aggiornamento

Come accennato poco sopra, Microsoft aveva già preso in esame lo strano comportamento di Lync nello scenario in cui i ruoli Front-End e Mediation sono collocati assieme, ed è selezionata la voce “Limit Service Usage to specified addresses” come visibile in Fig. 3.   Microsoft ha confermato che il comportamento è dovuto ad un errato tentativo di utilizzare il PSTN IP Address, quando questo non è registrato nel DNS.   A questo proposito, è stata rilasciata la KB 2675221, rintracciabile al seguente link :

http://support.microsoft.com/kb/2675221

Per risolvere definitivamente il problema, è stato anche rilasciato un hotfix, inserito nel “Cumulative update for Lync Server 2010, Mobility Service, February 2012″, scaricabile dal seguente link :

http://support.microsoft.com/kb/2675053

Quindi, per una risoluzione “esemplare” del problema illustrato in questo articolo, consiglio l’adozione di questo fixup, ma solo se vi trovate nell’esatto scenario indicato.

Segnalo anche che, in alcuni articoli, è indicata la NON-compatibilità del Mobility Service di Lync 2010 negli scenari in cui il Mediation Server è collocato con il Front-End.   Questo può essere vero, ma solo in alcuni casi.   Per esempio, segnalo l’articolo technet a questo link :

http://technet.microsoft.com/en-us/library/hh690037.aspx

L’articolo è stato aggiornato da Microsoft proprio ieri!!  In calce all’articolo, è visibile una nota importante che dice testualmente :

In some configurations, the Mobility Service is not supported on dual-homed Front End Servers that are collocated with a the Mediation Server role. Specifically, you cannot use this topology with Mobility Service if you define a Primary IP address and a public switched telephone network (PSTN) IP address in Topology Builder and register only the Primary IP address in Domain Name System (DNS)”.

E’ esattamente lo scenario del mio articolo!  Quindi se NON si è in questo preciso scenario, il Mobility Service è compatibile con la collocazione del Mediation assieme al Front-End.  Se si è in questo scenario, bisogna ricordarsi di installare il Cumulative Update appena indicato, e registrare nel DNS anche il PSTN IP Address.

Questo scenario è in fase di test avanzato da parte mia.  Vi terrò aggiornati su ulteriori sviluppi.

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

“Adoption and Training Kit” di Lync 2010

Scritto da Ivan Salvade' il 23 gennaio 2012

E’ disponibile sui siti di Microsoft l’”Adoption and Training Kit” di Lync 2010. La Home page della documentazione si trova al seguente link :

http://lync.microsoft.com/adoption-and-training-kit/Pages/default.aspx

Si tratta di un insieme di risorse per aiutare i professionisti IT e il personale di supporto a Lync 2010 ad operare correttamente in tutte le fasi di adozione del prodotto (analisi preliminare, progetto, implementazione, manutenzione, training finale agli utenti).

Fanno parte della documentazione numerose guide, video e FAQ suddivise per tipologia di ruolo (per amministratori, per help desk, per IT manager, per utenti finali) e per timing di consultazione (in fase di progetto, un mese prima dell’implementazione, durante l’implementazione, subito dopo il deployment e l’adozione finale di Lync, ecc.).

Sono raccolti inoltre un insieme di strumenti e utility da assegnare in uso agli utenti per aumentare il loro interesse nell’utilizzo dell’infrastruttura Lync (e farli anche divertire :-) ). Per ogni strumento è indicato il link per il download e una rapida guida per il suo utilizzo. Molti degli strumenti sono utili anche per gli amministratori.

Infine c’è una sezione dedicata alla panoramica di Lync Online, servizio offerto tramite la Suite Office 365 e il cloud di Microsoft. Lync Online offre features simili a Lync 2010, includendo Chat istantanea, collaborazione e condivisione documenti, Voice peer-to-peer e chiamate video, riunioni online. Numerosi documenti visualizzabili online, ed altri scaricabili, ci illustrano le differenze tra la piattaforma Lync On-Premise e quella Online, al fine di guidare i responsabili aziendali verso la scelta migliore.

Buona lettura!! :-)

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Cosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 4

Scritto da Ivan Salvade' il 15 gennaio 2012

Nella Parte 1 di questo articolo ho analizzato i concetti base di TDM (Time Division Multiplexing), VoIP (Voice over IP), sistemi PBX (Private Branch eXchange) e IP-PBX, apparati Media Gateway.

Nella Parte 2 ho trattato i protocolli H.323 e SIP e la differenza fra traffico di “signaling” e traffico di “media“.

Nella Parte 3 ho illustrato le nozioni fondamentali dei protocolli RTP e RTCP e dei Codecs Audio e Video.

In quest’ultima parte descriverò sommariamente il funzionamento dei ”Dial Plan” e della tecnica “Media Bypass” utilizzabile in Lync Server 2010.

I Dial Plan

Possiamo definire un Dial Plan come “un insieme ben preciso di regole che trasformano i numeri di telefono digitati dagli utenti in un formato unico e standard (il formato E.164).  Questo formato è richiesto da Lync, in particolare per riuscire ad eseguire la Reverse Number Lookup (RNL) dei numeri telefonici”.

Cos’è il formato E.164?   E’ una raccomandazione di ITU-T che definisce il piano di numerazione telefonica internazionale da utilizzare sulla rete PSTN (prefissi internazionali, nazionali, regionali e lunghezza dei numeri telefonici locali), nonchè il formato stesso dei numeri telefonici.   Per esempio, per quanto riguarda l’Italia, ITU-T ha stabilito che il nostro prefisso internazionale è 0039 e che i numeri telefonici nazionali devono essere lunghi al massimo 11 cifre (compresi i prefissi nazionali).

Secondo E.164, i numeri telefonici devono essere preceduti dal simbolo + ed essere lunghi al massimo 15 cifre.  Devono inoltre contenere il codice della nazione (prefisso internazionale, es. 39 per l’Italia), il codice di area (prefisso nazionale, es. 06 per la zona di Roma), e il numero “significativo” (numero proprio dell’utenza telefonica).

Quando si crea un Dial-Plan in Lync Server 2010, è raccomandato crearlo basandosi sul formato E.164, anche se bisogna verificare che i vostri Gateway e/o PBX che instradano verso PSTN sappiano riconoscere questo formato.   In tale evenienza, nella configurazione del Trunk di Lync verso i Gateway o PBX, si possono implementare ulteriori regole di traslazione che trasformano un numero telefonico in E.164 in un formato riconoscibile dal Gateway.

Quindi, in definitiva, la raccomandazione è dotare tutti gli utenti interni di un numero telefonico in preciso formato E.164, come in questo esempio :

Tel: +390612345678

E’ anche vero che gli utenti aziendali, solitamente, non sono abituati a digitare in puro formato E.164 un certo numero di telefono (per esempio, per chiamare un’utenza di Roma un utente digiterà 0612345678 invece di +390612345678, oppure per comporre un interno aziendale verrà digitato il semplice numero di interno, es. 123, piuttosto che l’intero numero E.164 associato all’utente, es. +3902111111123).

Il Dial Plan avrà il compito di rilevare tutte le “modalità personali di digitazione” dei numeri telefonici da parte degli utenti, e trasformarli in precisi numeri telefonici in formato E.164.

E’ quindi importante raccogliere il maggior numero di informazioni dagli utenti aziendali sulle loro abitudini di composizione dei numeri : un Dial Plan dovrebbe accomodarle tutte.

Si possono condurre interviste direttamente agli utenti, oppure raccogliere queste informazioni dagli impianti di telefonia già esistenti (per esempio dai PBX). Generalmente, le informazioni necessarie sono le seguenti :

  • lista di tutte le sedi aziendali dove si utilizza la telefonia
  • lista dei numeri interni utilizzati in ogni sede
  • lista dei prefissi nazionali e numeri telefonici significativi utilizzati in ogni sede aziendale per essere raggiunti dalla rete PSTN
  • capacità dei PBX esistenti di permettere o meno la raggiungibilità diretta da PSTN degli utenti aziendali, tramite il loro numero di interno
  • possibilità di utilizzare un unico Dial Plan o necessità di utilizzare multipli Dial Plan
  • tipologia di numeri interni da utilizzare (a 2 cifre, a 3 cifre, a 4 cifre ecc.)
  • abitudini degli utenti nel comporre gli interni
  • abitudini degli utenti nel comporre i numeri nazionali
  • abitudini degli utenti nel comporre i numeri internazionali
  • abitudini degli utenti nel comporre i numeri di emergenza
  • abitudini degli utenti nel comporre i numeri verdi e/o a tariffazione speciale

Una volta raccolte queste informazioni, gli elementi fondamentali da creare nei Dial Plan sono le “Normalization Rules”, che trasformano le digitazioni degli utenti in numeri di telefono in preciso formato E.164.

Ecco alcuni esempi (descritti in forma letterale, a scopo teorico; devono poi opportunamente essere tradotti nelle effettive Normalization Rule all’interno dei Dial Plan di Lync Server 2010) :

  • per ottenere la linea esterna, digitare il 9
  • se l’utente, allo scopo di chiamare un numero interno, digita un numero di 3 cifre che comincia per 1,2,3 o 4, preponi la stringa “+3902123456″ in modo da ottenere il numero di telefono E.164 completo dell’utente
  • se l’utente, allo scopo di chiamare un numero PSTN nazionale,  digita un numero di almeno 6 cifre, dove la prima cifra è uno zero e la seconda è un numero compreso tra 1 e 9, preponi  la stringa “+39″
  • se l’utente, allo scopo di chiamare un numero PSTN internazionale, digita un numero di almeno 8 cifre, dove le prime due sono degli zeri, la terza è un numero compreso tra 1 e 9 e la quarta un numero compreso tra 1 e 8 (questo per escludere il prefisso internazionale italiano), togli i primi due zeri e preponi il “+”

I precedenti sono tutti esempi di trasformazione di un numero telefonico, digitato dagli utenti nella maniera a loro più consona, in un numero standard in formato E.164.

Il “Media Bypass” di Lync Server 2010

Ho già trattato nella Parte 3 dell’articolo dei Codecs Audio e Video utilizzati da Lync Server 2010.    Quando si progetta la topologia dei Mediation Server in un’infrastruttura Lync, è importante capire con esattezza quali codecs vengono utilizzati nelle chiamate voce e nelle conferenze : se una chiamata deve attraversare un link di rete lento, il principale criterio di scelta del codec è la banda che esso consuma.

Lync ci aiuta in questa scelta permettendoci di utilizzare la tecnica “Media Bypass” : con questa tecnica è possibile rimuovere il Mediation Server dal percorso del traffico di Media (non da quello di Signaling), se e quando è possibile.   In questo modo, si migliora la qualità delle chiamate in quanto si riducono la latenza, la necessità di traslazione e la probabilità di perdita dei pacchetti.  Inoltre c’è un carico di lavoro inferiore sul Mediation Server, che può essere progettato per un miglior uso delle sue risorse e il controllo di multipli gateway.

Ecco una sintetica rappresentazione grafica del Media Bypass :

medbyp.jpg

Nel primo caso (”No Media Bypass”, cioè senza utilizzare il Media Bypass) si nota come sia il traffico di signaling che il traffico di Media transitano dal Mediation Server per poi fluire verso la rete PSTN tramite Gateway, PBX o Sip Trunk.

Se, per esempio, l’utente Lync effettua una chiamata verso PSTN, il Mediation Server deve, in questo caso, continuamente trasformare il traffico di Media dal codec RTAudio nativamente usato da Lync nel codec G.711 comunemente usato su rete PSTN : questo crea sovraccarico di processore al Mediation Server.   Addirittura, se il client Lync si trova in una sede collegata al Mediation Server da un link di rete lento, costringere il client a raggiungere il Mediation Server porterebbe anche ad una saturazione della banda disponibile sul link lento.

Nel secondo caso (”Media Bypass” attivo) si nota come il traffico di signaling deve ancora transitare dal Mediation Server (ma il traffico SIP è piuttosto leggero), mentre il traffico di Media “salta” il Mediation Server e collega il client direttamente all’apparato di collegamento alla rete PSTN : questo riduce notevolemente il carico di lavoro del Mediation Server.

In generale, la best practice di Microsoft è quella di cercare di utilizzare sempre il Media Bypass; ma, naturalmente, ciò non è sempre possibile.  I prerequisiti per poterlo utilizzare sono i seguenti :

  • l’apparato di collegamento alla rete PSTN (Gateway PSTN, IP-PBX) deve saper supportare la tecnica (molti apparati certificati per Lync hanno anche la dichiarazione di compatibilità con Media Bypass)
  • il provider di un eventuale SIP Trunk deve consentire di ricevere traffico direttamente dagli endpoint di Lync (alcuni provider accettano traffico solo se proveniente dal Mediation Server)
  • il link che collega gli endpoint di Lync ai Gateway PSTN, agli IP-PBX o al provider del SIP Trunk, deve essere piuttosto veloce ed affidabile

—————————————————————————————————————————————————————————————————————————————————–

Bene!  Con tutte le informazioni di base illustrate in questa serie di 4 articoli, potete ora gestire e comprendere meglio la vostra infrastruttura Lync.   Per gli utenti di già provata esperienza, si è trattato di un utile ripasso delle proprie conoscenze :-)

Buon Lync 2010 a tutti !!!  :-)

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Cosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 3

Scritto da Ivan Salvade' il 4 gennaio 2012

Nella Parte 1 di questo articolo ho analizzato i concetti base di TDM (Time Division Multiplexing), VoIP (Voice over IP), sistemi PBX (Private Branch eXchange) e IP-PBX, apparati Media Gateway.

Nella Parte 2  ho trattato i protocolli H.323 e SIP e la differenza fra traffico di “signaling” e traffico di “media“.

In questa terza parte discuterò dei protocolli RTP e RTCP e dei Codecs Audio e Video.

I protocolli RTP (Real-Time Transport Protocol) e RTCP (RTP Control Protocol)

Il protocollo RTP è usato per trasmettere segnali audio e video digitalizzati sulle reti IP, mentre il protocollo RTCP serve a monitorare la qualità della trasmissione dei dati e a rilevarne le statistiche.  Essi lavorano in stretta collaborazione.

Sono stati  sviluppati e standardizzati da IETF, inizialmente con la RFC 1889 del 1996, e poi con la RFC 3550 del 2003.

Le applicazioni tipicamente usano RTP sopra UDP, ma RTP può anche essere usato con altri protocolli di trasporto.  Inoltre RTP supporta il trasferimento dei dati verso multiple destinazioni usando una distribuzione di tipo “multicast”, se resa disponibile dalla rete sottostante.

RTP non fornisce meccanismi per assicurare la consegna puntuale e qualitativa dei dati, nè si incarica di controllare che la rete sottostante sia affidabile e che consegni i pacchetti nella giusta sequenza : questi compiti devono essere svolti da servizi/protocolli a livello inferiore.

Non voglio tediarvi con la spiegazione simil-RFC del protocollo (come ho fatto per SIP, ma era più interessante); mi limito ad illustrarvi gli scenari di utilizzo di RTP.

RTP si può usare in questi due scenari principali (ma ne esistono altri) :

  1. Conferenze Audio in modalità Multicast : in questo caso i dati audio sono trasmessi in sessione unica utilizzando opportuni indirizzi IP di tipo multicast e 2 porte, una utilizzata da RTP per indirizzare il traffico audio vero e proprio (circa il 90% o più del traffico), l’altra utilizzata da RTCP per indirizzare i pacchetti di controllo (circa il 10% o meno del traffico).
  2. Conferenze miste Audio/Video in modalità Multicast : in questo caso i dati audio e video sono trasmessi in sessioni separate (per permettere agli utenti di disattivare l’audio o il video, a loro scelta).  Ogni sessione utilizzerà il proprio indirizzo IP di multicast e la propria coppia di porte (la prima coppia gestirà “audio+rtcp”, la seconda coppia gestirà “video+rtcp”)

Le porte possono essere scelte a livello applicativo, anche se ne sono state standardizzate due :

  • 5004 RTP
  • 5005 RTCP

Tipicamente, le applicazioni utilizzano RTP e RTCP nel range di porte tra 1025 e 65535.  L’unica regola che di solito è sempre rispettata, è far utilizzare una porta pari a RTP e la porta dispari immediatamente successiva al RTCP che lavora nella stessa sessione.

RTP/RTCP sono i protocolli di Media utilizzati da Lync Server 2010.

I “Media Codecs”

I Codec rappresentano un modo di codificare i dati audio e video in bits (quindi in formato digitale), allo scopo di trasmetterli poi su una rete.  I codec possono essere dei dispositivi hardware, oppure dei programmi.  Tipicamente, nei sistemi operativi Microsoft, i codec non sono altro che opportune librerie (DLL) “agganciate” ai software che gestiscono le comunicazioni audio e video su reti IP.

Per due utenti che vogliono effettuare un comunicazione audio/video, il codec usato da entrambi deve essere uguale, per permettere una corretta codifica e decodifica del traffico.

I codec eseguono il loro lavoro utilizzando opportuni algoritmi di codifica e di compressione.  La compressione è indispensabile per ridurre lo spazio di occupazione del traffico audio/video, e quindi riuscire a trasmetterlo in una rete con il minor spreco di banda possibile.

Esistono molti tipi di codec, che differiscono tra loro per :

  • algoritmo di codifica/compressione
  • tipo di segnale che devono campionare
  • Bit Rate : il Bit Rate è il numero di bits processati per ogni unità di tempo, ed è solitamente indicato in bps (bit per secondo), Mbps (Megabit per secondo) o Gbps (Gigabit per secondo)
  • Frequenza di campionamento (sampling rate) : indica quante volte in un secondo il segnale analogico viene campionato (misurato) e trasformato in digitale; è tipicamente indicata in Hz, KHz, MHz
  • larghezza di banda utilizzata per la trasmissione dei pacchetti contenenti i dati audio (audio payload)

Si possono suddividere i Media Codecs in due categorie : Audio Codecs e Video Codecs.

Codecs Audio

Codificano e comprimono i dati audio in digitale.

Ecco l’elenco dei Codec Audio supportati da Lync Server 2010 :

  • RTAudio (Wideband e Narrowband) : codec di produzione Microsoft, campiona a 16 KHz (Wideband) o a 8 KHz (Narrowband), il Bit Rate del payload audio varia da 8 Kbps circa a 30 Kbps circa
  • G.722 : codec standardizzato ITU-T, campiona a 16 KHz, il Bit Rate del payload audio è 48/56/64 Kbps
  • G.711 : codec standardizzato ITU-T, campiona a 8 KHz e 16 KHz (G.711.1), il Bit Rate del payload audio è 64 Kbps
  • Siren : codec di produzione Polycom, campiona a 16 KHz, il Bit Rate del payload audio è 16 Kbps circa

Lync 2010 cerca di usare primariamente il codec RTAudio : è un codec che si auto-adatta alle condizioni della rete (per esempio può cambiare il suo bit-rate, il suo consumo di banda e altro ancora per cercare di garantire la migliore trasmissione audio possibile).

Per comunicazioni peer-to-peer tra endpoint Lync Server 2010, è sicuramente usato RTAudio.

Quando si effettuano comunicazioni verso PSTN, si controlla la banda di rete disponibile : con buona banda si utilizza G.711, con banda ristretta ci si affida sempre a RTAudio.

Per il traffico delle chiamate in conferenza, il codec di default utilizzato è invece G.722, mentre viene utilizzato il codec Siren se la banda è troppo scarsa o se si connettono a Lync Server 2010 dei client OCS 2007 o OCS 2007 R2.   In Lync Server 2010 il codec Siren è disabilitato per default : per poterlo utilizzare, bisogna attivarlo da linea di comando.

In generale, si può dire che RTAudio ha maggiori funzionalità avanzate e migliori performance generali degli altri, ma bisogna ricordare che G.711 (soprattutto) è ampiamente compatibile con la maggior parte degli endopint VoIP, in quanto è lo standard più conosciuto ed utilizzato : in chiamate verso PSTN diventa allora probabilmente quello più sfruttato.

Codecs Video

Codificano e comprimono i dati video in digitale.

Lync Server 2010 utilizza un unico codec video : RTVideo

RTVideo  è un codec di produzione Microsoft, derivato dallo standard VC-1.  Può essere configurato in diversi modi (profili), e a seconda della sua modalità di funzionamento può ottenere :

  • Bit Rate compreso tra 96 Kbps e 135 Mbps
  • Risoluzione video compresa tra (176 X 144) e (2048 X 1536)

Nella Parte 4 dell’articolo tratterò dei Dial Plan (o Dialing Plan) e della tecnica “Media Bypass” di Lync Server 2010.

  • Share/Bookmark

Pubblicato in Lync Server 2010 | 1 Commento »

Cosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 2

Scritto da Ivan Salvade' il 28 dicembre 2011

Nella Parte 1 di questo articolo ho analizzato i concetti base di TDM (Time Division Multiplexing), VoIP (Voice over IP), sistemi PBX (Private Branch eXchange) e IP-PBX, apparati Media Gateway.

In questa seconda parte tratterò in maniera concettuale di SIP, H.323 e della differenza fra traffico di “Signaling” e traffico di “Media”.

“Signaling” e “Media”

Nell’ambito dell’industria telefonica, il termine “Signaling” (”Segnalazione” in italiano) viene utilizzato per indicare il processo di realizzazione di una chiamata telefonica.

Più precisamente, il Signaling è l’insieme di operazioni e di segnali necessari ad instaurare la chiamata telefonica, a gestirne i dettagli e gli stati transitori (per es. inoltro della chiamata, condizioni di errore, stato di occupato del destinatario), e ad abbattere la chiamata, quando uno dei due interlocutori interrompe la comunicazione.

Nella rete telefonica pubblica tradizionale (PSTN), il meccanismo standard più comune per l’effettuazione delle operazioni di signaling è la suite di protocolli SS7 (Signaling System n° 7).

Utilizzare IP per effettuare chiamate telefoniche, obbliga a rendere disponibile su protocollo IP i meccanismi di signaling.  La telefonia IP deve però rimanere in tutto e per tutto compatibile con il sistema telefonico tradizionale.  Sono quindi stati proposti da ITU  e IETF degli standard (già accennati nella Parte 1 dell’articolo) che permettono di “inserire” il traffico di signaling nei pacchetti IP : gli standard più conosciuti sono H.323 e SIP.

Il termine “Media” (o Traffico di Media) viene invece utilizzato per indicare l’insieme di “segnali informativi” (tipicamente audio e video) da trasportare lungo un canale di trasmissione.  Per esempio, in una chiamata telefonica, il Traffico di Media è rappresentato dalla voce degli interlocutori, opportunamente codificata e trasmessa lungo il canale di trasmissione.

Anche in questo caso, per poter rendere disponibile il Traffico di Media su IP, si devono utilizzare opportuni protocolli : il più conosciuto ed utilizzato nella stragrande maggioranza dei casi è RTP.

H.323

Nella Parte 1 di questo articolo ho sommariamente inserito lo standard H.323 nella categoria di protocolli responsabili di gestire il traffico di signaling.  La categorizzazione è corretta, ma H.323 è qualcosa in più…

Lo standard H.323, proposto da ITU,  è una suite di protocolli inizialmente progettata per fornire servizi di teleconferenza con voce, video e dati su reti IP locali, e successivamente estesa anche alle reti IP internet (quindi, reti a commutazione di pacchetto).

H.323 definisce il modo in cui diversi protocolli devono cooperare per formare un sitema telefonico IP funzionante, e su qualunque tipo di rete IP.  Oltre che garantire la comunicazione voce e video in tempo reale, la suite H.323 consente anche ai partecipanti di trasferire dati (per esempio inviarsi documenti, condividere una lavagna virtuale, condividere i desktop, condividere applicazioni).

I protocolli della suite H.323 gestiscono la telecomunicazione in tutte le sue fasi, e cioè :

  • registrazione dei dispositivi comunicanti
  • signaling
  • codifica e trasferimento dati in tempo reale
  • funzionalità avanzate e sicurezza
  • controllo

Ecco un sommario dei protocolli più importanti della suite H.323, suddivisi per categoria :

Registrazione, signaling e controllo

  • H.225        Call signaling e pacchettizzazione del traffico di media
  • RAS           Registration, Admission, Status
  • H.245        Controllo delle comunicazioni multimediali

Gestione Audio

  • G.711 (chiamato anche PCM - Pulse Code Modulation)
  • G.722
  • G.723.1
  • G.728
  • G.729

I precedenti sono tutti dei Codec Audio Standard, ratificati da ITU-T.  Hanno il compito di campionare, codificare in digitale e comprimere i segnali audio.  G.711 è sicuramente quello più utilizzato nelle reti telefoniche.

Gestione Video

  • H.261
  • H.263
  • H.264

I precedenti sono dei Codec Video Standard, ratificati da ITU-T.   Hanno il compito di campionare, codificare in digitale e comprimere i contenuti video.

Data Conferencing

  • T.120  

Suite di protocolli che ha il compito di stabilire e mantenere le conferenze senza dipendenze da alcuna piattaforma, gestire multipli partecipanti e multipli programmi, spedire e ricevere dati accuratamente su una varietà di connessioni di rete supportate.    Garantiscono condivisione di dati e programmi, trasferimento dei files.

La suite comprende molti protocolli :  T.121, T.122, T.123, T.124, T.125, T.126, T.127, T.128, T.134, T.135, T.136, T.137

Trasporto del traffico di Media

  • RTP
  • RTCP

Sicurezza delle trasmissioni

  • H.235         Garantisce criptazione del traffico tra terminali multimediali

Servizi avanzati o supplementari

  • H.450.1   H.450.2   H.450.3   H.450.4   H.450.5   H.450.6   H.450.7   H.450.8   H.450.9

Ognuno dei precedenti protocolli permette l’utilizzo di un certo servizio supplementare durante le telecomunicazioni.  Degli esempi possono essere :

  • chiamata in attesa
  • inoltro chiamata
  • parcheggio e successivo recupero della chiamata
  • trasferimento di chiamata
  • … tanti altri, e in continua evoluzione…

SIP (Session Initiation Protocol)

E’ un protocollo di controllo e di signaling sviluppato dalla IETF,  standardizzato con la RFC 2546 del 1999 e con la più recente RFC 3261 del 2002.

E’ un protocollo Application-Layer (al pari, per esempio, di HTTP, SMTP, SNMP, DNS ecc. ecc.), proposto da IETF come alternativa a H.323.

Ha il compito di creare, modificare e terminare sessioni con uno o più partecipanti, dove con sessioni si possono intendere le chiamate telefoniche Internet, le distribuzioni di contenuto multimediale e le conferenze multimediali.

A differenza di H.323, SIP si occupa solo del traffico di signaling e di registrazione : le altre features sono coperte da altri protocolli separati, sui quali SIP deve fare affidamento per fornire servizi completi agli utenti.   La suite di protocolli H.323 copre invece, come appena visto, la quasi totalità dei servizi presenti in una comunicazione multimediale.

Le funzionalità base di SIP sono le seguenti :

  • localizzazione degli endpoint (i terminali della comunicazione)
  • segnalazione della volontà di comunicare
  • negoziazione dei parametri della sessione
  • gestione della sessione
  • terminazione della sessione

Ogni risorsa in una rete SIP deve essere identificata da un URI (Uniform Resource Identifier). Ogni URI deve essere espresso nell’opportuna sintassi prevista dalla RFC 3261. Il prefisso (o “schema”) di un SIP URI deve essere :

  • sip: se la trasmissione del URI avviene in chiaro
  • sips: se la trasmissione del URI avviene in maniera sicura (criptata con TLS)

La sintassi generale di un SIP URI è la seguente :

sip:user:password@host:port;uri-parameters?headers

Ecco la spiegazione sommaria dei vari termini della sintassi :

  • user : l’identificatore di una particolare risorsa da contattare. Nelle comunicazioni VoIP aziendali, questo è molto frequentemente il nome diretto dell’utente da chiamare
  • password : la password dell’utente. Sebbene concessa dalla sintassi, per ragioni di sicurezza è consigliato non usare questo parametro, soprattutto se l’URI è utilizzato in chiaro
  • @host : l’host che fornisce la risorsa SIP. Può contenere un FQDN o un indirizzo IPv4/IPv6. La raccomandazione è di utilizzare un FQDN
  • port : la porta dove la richiesta deve essere spedita. Se non indicata, per default la porta è 5060 per un URI SIP che usa TCP o UDP in chiaro; la porta è 5061 per un URI SIP che usa TCP over TLS o per un URI SIPS che usa TCP
  • uri-parameters : parametri aggiuntivi che possono (o meno) essere indicati; tipicamente servono a modificare il meccanismo di trasporto dei messaggi SIP, o a modificarne il routing. Il protocollo di trasporto di default è UDP per SIP, mentre è TCP per SIPS

Ecco alcuni esempi di SIP URI, tratti dalla RFC 3261 :

sip:alice@atlanta.com (quello più comunemente associato ad ogni utente aziendale che usa Lync Server 2010)
sip:alice:secretword@atlanta.com;transport=tcp
sip:+1-212-555-1212:1234@gateway.com;user=phone
sips:1212@gateway.com
sip:alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com

Le funzionalità base di SIP menzionate poco fa, vengono garantite utilizzando diversi componenti :

  • UA (User Agent) : un endpoint di comunicazione. Può fungere da client (UAC) o server (UAS) o entrambi (per esempio un telefono SIP)
  • UAC (User Agent Client) : entità logica che spedisce richieste SIP e riceve risposte a queste richieste
  • UAS (User Agent Server) : entità logica che spedisce risposte alle richieste SIP
  • Server SIP : sebbene due endpoint SIP possano comunicare anche direttamente tra loro senza un’infrastruttura SIP, questo è impraticabile in una rete pubblica (es. Internet).  Allora deve intervenire un’opportuna infrastruttura SIP, al cui interno si devono trovare diversi dispositivi (chiamati proprio Server SIP), che possono essere :
    • Proxy Server : funzionano come entità intermedia, hanno il compito di routare le richieste provenienti da altre entità, funzionano come client e/o come server, allo scopo di stabilire le chiamate tra gli utenti
    • Registrar Server : accettano le richieste di registrazione di un utente.  Un utente SIP si registra con il suo SIP URI del tipo “sip:utente@sipdomain.xxx”, indipendentemente dalla sua locazione geografica.  Inoltre registra anche i suoi User Agent endpoint (cioè l’elenco di dispositivi che può utilizzare per effettuare chiamate SIP).  Tutte queste informazioni vengono passate al Location Service
  • Location Service : comparabile al lavoro eseguito dai server DNS, ha il compito di risolvere un SIP URI in forma “sip:nome@FQDN” nei reali endpoint fisici (anche più di uno) su cui lavora l’utente (es. “sip:nome@192.168.50.102:1234″).  Il Location Service è in effetti una sorta di database contenente queste risoluzioni, ed è popolato costantemente dalle operazioni di registrazione effettuate dai Registrar Server

Ecco un esempio di comunicazione SIP.  Suppongo che l’utente Alice usi un applicazione SIP sul suo computer (pc1.source.com) per chiamare l’utente Bob sul suo telefono SIP, tramite Internet.  Alice ha un SIP URI ”alice@source.com” e Bob ha un SIP URI “bob@dest.com”.  Le fasi che avverranno sono le seguenti (in rosso sono evidenziati i messaggi SIP) :

  1. Alice clicca sul nome di Bob nella propria rubrica degli indirizzi
  2. L’applicazione SIP di alice spedisce un messaggio INVITE al SIP URI di Bob.  Il messaggio INVITE, come minimo,  contiene :
    1. l’indirizzo IP (o nome FQDN) a cui Alice desidera ricevere risposta (pc1.source.com)
    2. un numero di transazione
    3. il Display Name e il SIP URI di Bob (Bob <sip:bob@dest.com>)
    4. il Display Name e il SIP URI di Alice (Alice <sip:alice@source.com>)
    5. un Tag usato a scopo di identificazione dall’applicazione o telefono SIP
    6. un GUID per la chiamata, ottenuto combinando una stringa casuale con l’indirizzo IP o FQDN dell’host chiamante
    7. un SIP URI ulteriore che rappresenta una via diretta per raggiungere Alice (<sip:alice@pc1.source.com>)
  3. Dato che l’applicazione di Alice non conosce nè la posizione di Bob nè il SIP Server di dest.com, il messaggio INVITE è spedito al SIP Server del dominio di Alice (source.com), configurato nell’applicazione di Alice
  4. Il SIP Server di Alice è il “Proxy Server”.  Risponde all’applicazione di Alice con un messaggio 100 TRYING.  La risposta indica che l’invito è stato ricevuto e che il Proxy sta lavorando per routare correttamente la richiesta
  5. Il Proxy Server di Alice localizza il Proxy Server di Bob (tramite DNS) nel dominio dest.com
  6. Una volta ottenuto l’indirizzo IP del Proxy di dest.com, inserisce nel messaggio INVITE il proprio indirizzo, e lo inoltra al Proxy Server dest.com
  7. Il Proxy dest.com risponde al Proxy source.com con un messaggio 100 TRYING
  8. Il Proxy dest.com consulta il suo Location Service che contiene il corrente/i indirizzo/i IP di Bob
  9. Il Proxy dest.com inserisce nel messaggio INVITE il proprio indirizzo, e lo inoltra al/i telefono/i SIP di Bob
  10. Il telefono di Bob riceve il messaggio INVITE e comincia a squillare.  Questa azione è confermata da un messaggio 180 RINGING che viene rispedito indietro, tramite i due proxy, fino al mittente (Alice)
  11. Quando l’applicazione di Alice riceve il messaggio 180 RINGING, essa segnala ad Alice l’esecuzione della chiamata, emettendo il tono acustico di chiamata o visualizzando a schermo opportuni avvisi
  12. Bob risponde alla chiamata : il suo telefono SIP spedisce un messaggio 200 OK ad Alice, sempre tramite i due proxy
  13. L’applicazione di Alice conferma la chiamata con un messaggio ACK spedito direttamente al telefono di Bob (ormai si conoscono, non servono più i due proxy)
  14. Bob e Alice si accordano sul tipo di sessione che vogliono stabilire
  15. Lo scambio di dati nella sessione viene effettuato con gli opportuni protocolli di Media (es. RTP/RTCP)
  16. L’utente che decide di terminare la chiamata invia direttamente all’altro un messaggio BYE
  17. L’altro risponde con un messaggio conclusivo 200 OK

SIP è stato adottato come protocollo di signaling da Lync Server 2010.

Nella Parte 3 dell’articolo discuterò dei protocolli RTP e RTCP e dei Codecs Audio e Video.

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Cosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 1

Scritto da Ivan Salvade' il 20 dicembre 2011

Ritengo che un sistemista/progettista di infrastrutture Lync Server 2010 debba avere conoscenze almeno concettuali di alcune tecnologie di telecomunicazione (ed argomenti annessi).

Altre conoscenze richieste possono essere :

  • Active Directory
  • Exchange Messaging
  • SQL Server
  • Powershell
  • TCP/IP e DNS
  • PKI (Public Key Infrastructure)

Mi interessa, in questa serie di articoli, illustrare i concetti base di argomenti riguardanti le telecomunicazioni, e in particolare :

  • TDM (Time Division Multiplexing) e VoIP
  • Media Gateways e PBX (Private Branch eXchange)
  • Differenze tra “Signaling” e “Media”
  • SIP (Session Initiation Protocol) e H.323
  • RTP (Real-Time Transport Protocol) e RTCP (RTP Control Protocol)
  • Tecnica “Media Bypass” di Lync Server 2010
  • Codecs
  • Dialing Plans

Queste brevi informazioni possono essere di aiuto a chi si affaccia per le prime volte alla gestione di un sistema di Unified Communications.

In questa prima parte dell’articolo, comincio a trattare i concetti di TDM, VoIP, PBX, Media Gateway.

TDM (Time Division Multiplexing)

Tecnica conosciuta in Italia come “Multiplazione a Divisione di Tempo”.

Multiplexing (o “multiplazione”) significa ricevere diversi segnali in ingresso, e modularli ottenendo un unico segnale in uscita, trasmettibile su un unico collegamento fisico.

Volendo utilizzare questa tecnica in un sistema di telecomunicazioni, possiamo dire che è la tecnica che ci permette di trasmettere multiple chiamate utilizzando un singolo cavo, cioè di far convivere più “segnali informativi” sullo stesso mezzo di trasmissione.

Ovviamente all’altro capo del mezzo di trasmissione dovrà essere eseguita l’operazione inversa (cioè il “Demultiplexing”) per ricostruire i segnali informativi originali.

Sono evidenti i vantaggi di questa tecnica :

  • possibilità di occupare tutta la banda messa a disposizione dal mezzo di trasmissione
  • massimizzare l’utilizzo del mezzo trasmissivo (spesso qualche sorgente non è costantemente attiva)
  • semplificare la gestione dei collegamenti a lunga distanza (ne devo creare in minor numero)

Il Multiplexing può essere eseguito in diversi modi, e uno di questi è proprio il TDM : con questa tecnica, la condivisione del mezzo di trasmissione è ottenuta assegnando ad ogni sorgente un certo intervallo di tempo in cui trasmettere i suoi dati.  Il dispositivo di multiplexing raccoglie i dati delle varie sorgenti, e li trasmette in un flusso continuo verso il sistema di multiplexing destinatario.    Se una sorgente genera dati ad una velocità maggiore rispetto alle altre, il Multiplexer deve inserire in un buffer il flusso di dati troppo veloce, oppure deve campionare i dati da quella sorgente più velocemente rispetto alle altre.

Perchè ci interessa TDM ?  Il TDM è adatto per flussi di dati analogici e digitali e per trasmissioni di fonia nelle reti telefoniche.  Inoltre molti dei sistemi PBX collegabili a Lync Server 2010 sono tuttora basati su TDM.

VoIP (Voice over IP)

Tecnologia che rende possibile effettuare comunicazioni telefoniche utilizzando una qualunque rete IP (per esempio Internet).

La voce viene tradotta in formato digitale da un convertitore A/D (analogico/digitale), i dati digitali sono divisi in pacchetti e instradati sulla rete IP verso la destinazione.  Qui vengono ricevuti, riassemblati e riconvertiti in voce da un convertitore D/A (digitale/analogico).  Per espletare il loro compito, i convertitori A/D utilizzano particolari codec audio e video, che tratterò nella terza parte dell’articolo.

Le reti IP si possono definire “a commutazione di pacchetto”, e sono in antitesi con le tradizionali reti telefoniche, che invece sfruttano la “commutazione di circuito” : in quest’ultimo caso, una telefonata utilizza un circuito fisso dedicato su una giunzione tra centrali telefoniche, cioè la rete telefonica elabora il numero digitato e alloca una serie di circuiti fino a raggiungere il destinatario della chiamata.

Con la “commutazione di circuito” la banda utilizzata da ogni telefonata è fissa e riservata.

Con la “commutazione di pacchetto” la banda è sfruttata in maniera dinamica e migliore, in quanto i pacchetti vengono instradati (e quindi occupano banda) solo quando necessario, cioè quando i due utenti parlano.

Ecco alcuni vantaggi del VoIP :

  1. Minor costo delle chiamate, soprattutto quelle a lunga distanza
  2. Minore spesa in infrastrutture (è sufficiente una rete IP !!)
  3. Future nuove opzioni non richiederanno sostituzione di hardware
  4. Chiamate locali e a lunga distanza sono praticamente identiche
  5. Maggiore efficienza dei Fax
  6. Maggiore sicurezza delle chiamate (anche se non criptate)

VoIP funziona appoggiandosi a diversi protocolli.  Ci sono due categorie fondamentali di protocolli :

  • Protocolli per il trasporto di segnali audio e video
  • Protocolli per la gestione del traffico di “signaling”

Nella prima categoria rientra il protocollo RTP (Real-Time Transport Protocol), usato nella stragrande maggioranza delle implementazioni VoIP.

Nella seconda categoria rientrano diversi protocolli, proposti da diversi organismi internazionali di standardizzazione (ITU, IETF, ETSI).  I più conosciuti sono gli standard proposti da ITU e IETF, ma ne esistono tanti altri :

  • H.323 (ITU)
  • SIP (IETF)
  • SCCP (Skinny Call Control Protocol, o semplicemente “Skinny”) della CISCO
  • MGCP - Media Gateway Control Protocol (ETSI)
  • MEGACO (chiamato anche H.248) (ETSI)
  • MiNET della Mitel
  • XMPP - eXtensible Messaging and Presence Protocol (conosciuto anche come “Jabber”) (IETF)

Sistemi PBX (Private Branch eXchange)

Un sistema PBX non è altro che una “centralina telefonica” utilizzata dalle aziende per fornire una rete telefonica interna.  Piuttosto che assegnare una linea diretta verso l’esterno ad ogni utente (operazione costosa), il PBX assegna un canale di fonia interno e privato ad ogni utente: in questo modo gli utenti aziendali possono colloquiare tra di loro.  Inoltre il sistema PBX è in grado di condividere un certo numero di linee esterne, per permettere agli utenti aziendali di inoltrare e ricevere chiamate dalla rete telefonica PSTN pubblica.

Il centralino PBX svolge tre funzioni fondamentali :

  1. Creare la connessione (o il circuito) tra gli apparati telefonici che si stanno chiamando, mappando i numeri chiamanti e chiamati ai corrispondenti telefoni fisici
  2. Mantenere la connessione per il tempo voluto dagli utenti, tramite apposito traffico di “Signaling”
  3. Fornire informazioni sulla durata della conversazione

Oltre alle funzioni fondamentali, ogni PBX può offrire ulteriori servizi, in base al Vendor e al modello acquistato.  Alcuni esempi :

  • Avviso di chiamata
  • Trasferimento di chiamata
  • Musiche di attesa
  • Risposta automatica in caso di assenza
  • Blocco delle chiamate in arrivo
  • Blocco degli apparecchi telefonici con codice di sblocco
  • Selezione diretta di un numero con un tasto
  • Composizione diretta degli interni (DID, “Direct Inward Dialing”)
  • Risposta a chiamata in arrivo su un altro interno
  • Registrazione conversazioni

Al giorno d’oggi, con il termine PBX si intendono sempre i centralini PBX Legacy (chiamati anche ”TDM PBX”). Un sistema PBX Legacy non dispone di un adattatore di rete che permetta di trasmettere i segnali sottoforma di pacchetti IP.   Molte aziende hanno allora scelto di affidarsi a sistemi PBX più moderni, chiamati IP-PBX.

Per poter utilizzare un sistema TDM PBX con Lync Server 2010, è necessario implementare un Gateway IP opportunamente supportato (per es. quelli di AudioCodes e Dialogic).

I Sistemi TDM PBX sono generalmente collegati alla compagnia telefonica tramite opportune linee telefoniche speciali (linee T1 o E1), che dispongono di più canali. I TDM PBX possono essere utilizzati con linee analogiche o ISDN.

Essi, inoltre, sono in grado di instradare il numero di telefono composto verso uno specifico apparecchio telefonico.  Per esempio, potrebbe capitare che un utente esterno componga il numero interno diretto di un utente aziendale : la compagnia telefonica, utilizzando un particolare servizio DNIS (Dialed Number Identification Service), spedisce al PBX il numero DID per il raggiungimento dell’interno.  Il PBX, utilizzando il proprio Dial Plan, è poi in grado di inoltrare la chiamata al corretto telefono interno.

Un’ultima distinzione che si può fare, è quella tra sistemi TDM PBX Analogici o Digitali.

Un PBX Analogico invia comunicazioni vocali e signaling (per esempio i toni DTMF di chiamata) sottoforma di suono analogico, che non viene mai convertito in digitale.

Un PBX Digitale, invece, codifica il suono analogico in digitale, utilizzando dei Codec Audio che devono rispettare gli standard internazionali definiti da ITU-T  (tipicamente lo standard G.711).

Sistemi IP-PBX

Un sistema IP-PBX (più moderno) è come un PBX Legacy, ma è dotato di scheda di rete che gli permette di supportare IP.  Il protocollo IP è usato per inviare comunicazioni vocali e signaling in pacchetti, piuttosto che sottoforma di suono analogico o digitalizzato.

Esistono IP-PBX Tradizionali e IP-PBX Ibridi.  La differenza sostanziale tra i due è che quelli Ibridi permettono il collegamento anche di apparecchi telefonici analogici e digitali, mentre quelli tradizionali permettono il collegamento solo di telefoni IP (VoIP).

Un IP-PBX Tradizionale solitamente ha le seguenti caratteristiche :

  • Dispone di una o più interfacce di rete Ethernet; con queste può collegarsi ad altri host VoIP presenti in rete (cioè altri IP-PBX, telefoni VoIP, Gateway IP, Server di tipo Unified Communications come Lync Server 2010)
  • Dispone di una o più interfacce di telefonia per collegarsi a rete PSTN
  • Poichè è già in grado di convertire i protocolli basati su circuito della rete PSTN in protocolli VoIP a commutazione di pacchetto, l’utilizzo di un Gateway IP potrebbe non essere necessario per comunicare con i server UC interni

Un IP-PBX Ibrido solitamente ha le seguenti caratteristiche :

  • Dispone di una o più interfacce di rete Ethernet; con queste può collegarsi ad altri host VoIP presenti in rete (cioè altri IP-PBX, telefoni VoIP, Gateway IP, Server di tipo Unified Communications come Lync Server 2010)
  • Dispone di una o più interfacce di telefonia per collegarsi a rete PSTN
  • Dispone di una o più interfacce analogico/digitale per il collegamento di telefoni analogici e digitali
  • Poichè è già in grado di convertire i protocolli basati su circuito della rete PSTN in protocolli VoIP a commutazione di pacchetto, l’utilizzo di un Gateway IP potrebbe non essere necessario per comunicare con i server UC interni.  Diventa necessario se il sistema IP-PBX utilizza protocolli VoIP non compatibili con i server UC interni

Media Gateway (termine generico)

Il “Media Gateway” è generalmente considerato una unità di connessione e transcodificazione tra differenti tipi di rete aventi differenti tecniche di trasmissione e di codifica dei loro dati.  Per esempio, un Media Gateway può collegare tra loro reti PSTN, reti radio 3G, sistemi TDM-PBX o IP-PBX, reti IP, e altro ancora.

Ne esistono di parecchi tipi, e ognuno ha minori o maggiori capacità di supporto dei diversi tipi di rete.  Per questo motivo, nel linguaggio comune vengono utilizzati numerosi sinonimi di “Media Gateway”, che più o meno fanno capire la sua funzionalità principale.  Ecco un elenco dei sinonimi più comuni :

  • VoIP Media Gateway
  • VoIP Gateway
  • Voice IP Gateway
  • VoIP SIP Gateway
  • SIP VoIP Gateway
  • VoIP Telephone Gateway
  • VoIP to PSTN Gateway
  • IP Gateway
  • PSTN Gateway
  • IP-PSTN Gateway

Un’azienda potrebbe già averlo implementato in rete, oppure, se ancora non lo ha fatto, deve attentamente valutare la necessità di farlo o meno, quando sta pensando di migrare ad un’infrastruttura Lync Server 2010.  Devono anche essere definite la capacità e le precise funzionalità del Media Gateway da implementare, in base alle reti, agli apparati, ai server, alle applicazioni, ai link di collegamento presenti nella propria infrastruttura.

I compiti fondamentali del Media Gateway in un’infrastruttura Lync Server 2010 possono essere i seguenti (N.B. : non è detto che un’azienda abbia bisogno di tutti questi servizi) :

  • Codificare il traffico di “signaling” e il traffico di “media” tra il Mediation Server e la rete PSTN
  • Funzionare come punto di terminazione per i SIP Trunk
  • Funzionare come apparato intermedio tra Lync 2010 e qualunque TDM-PBX o IP-PBX non supportato da Lync
  • Connettere telefoni analogici e apparecchi Fax all’infrastruttura Lync

Detto questo, ecco alcune generali regole per decidere l’implementazione o meno di un Media gateway in un’infrastruttura Lync :

  • E’ necessario un Media Gateway per connettere Lync ad un TDM-PBX (che non supporta IP)
  • E’ necessario un Media Gateway per connettere Lync ad un IP-PBX non supportato da Lync (per es. quelli non conformi con la RFC 3261, la quale dichiara che un apparato IP-PBX deve supportare il protocollo SIP sia su UDP che su TCP)
  • Se l’azienda ha un IP-PBX conforme alla RFC 3261, il Mediation Server può collegarsi anche direttamente al IP-PBX usando il protocollo SIP/TLS o SIP/TCP, senza necessità di un Media Gateway
  • Se l’azienda si connette alla rete PSTN tramite un SIP Trunk realizzato in collaborazione con un Provider di Servizi di Telefonia (ITSP), il Mediation server può trasmettere il traffico di “signaling” tramite SIP/TCP e il traffico di “media” tramite RTP direttamente al provider, utilizzando una connesione IP : quest’ultima può essere realizzata tramite VPN, MPLS dedicata o normale connessione non criptata.  In questo caso, ai fini del collegamento con PSTN, non sono necessari nè un Media Gateway, nè un IP-PBX

Per un elenco di Gateway e apparati PBX compatibili con Lync Server 2010, si può consultare questo link :

http://technet.microsoft.com/en-us/lync/gg131938.aspx

Nella Parte 2 dell’articolo discuterò dei protocolli SIP e H.323, e delle differenze fra traffico di “signaling” e traffico di “media”.

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Elementi fondamentali di progettazione di un’infrastruttura Lync Server 2010

Scritto da Ivan Salvade' il 15 dicembre 2011

Lync Server 2010 è un prodotto che si integra con numerosi servizi di infrastruttura, software, protocolli e apparati di rete.  Per questo motivo la sua corretta progettazione riveste un’importanza fondamentale per ottenere il perfetto funzionamento di tutte le sue features.

Lo scopo di questo articolo è indicarvi quali sono i componenti fondamentali di un’infrastruttura Lync, a cosa servono, e come devono essere implementati e utilizzati.

Comincio col dire che, per progettare e poi gestire un’infrastruttura Lync, sarebbe molto utile avere :

  • Conoscenze di Active Directory, DNS e servizi di infrastruttura
  • Esperienza sulla precedente piattaforma OCS 2007 R2
  • Conoscenza di tecnologie correlate, come per esempio Exchange Unified Messaging
  • Conoscenze concettuali di tecnologie di telecomunicazione, tra cui :
    • TDM (Time Division Multiplexing) e integrazione con VoIP
    • Gateways e PBX (Private Branch eXchange)
    • Differenze tra “Signaling” e “Media”
    • SIP (Session Initiation Protocol) e H.323
    • Codecs
    • Normalizzazione dei Dial Plan

La conoscenza delle tecnologie di telecomunicazione è utile, oltre che per la fase di progettazione, anche per risolvere in futuro eventuali problemi di integrazione tra Lync e i vostri apparati di telecomunicazione.

Ecco i concetti fondamentali di progettazione da tenere presente.

Disponibilità di Lync Server 2010

E’ disponibile solo in edizione a 64 bit, e richiede un sistema operativo Windows Server 2008 SP2 Standard, Enterprise, Datacenter, oppure Windows Server 2008 R2 Standard, Enterprise, Datacenter. Tutti i ruoli di Lync richiedono uno dei suddetti sistemi operativi. I client, invece, non richiedono hardware o software a 64 bit.

Differenze tra Lync Server 2010 “Standard Edition” e “Enterprise Edition”

La Standard Edition è consigliabile per piccole aziende, tutte le sue features (compresi i database) risiedono su un unico server; dimensionando opportunamente il server, può arrivare a gestire anche 5000 utenze, ma non garantisce alta disponibilità.

La Enterprise Edition garantisce anche l’alta disponibilità delle features, richiede un minimo di due server nell’infrastruttura (il Front-End e il Back-End), è totalmente scalabile e può arrivare a supportare centinaia di migliaia di utenze!

Ruoli di Lync obbligatori

Il “Front-End Server” e il “Back-End Server” (nella Standard Edition sono sullo stesso server, nella Enterprise Edition sono due server diversi), e il “Audio/Video Conferencing Server”.

Ruoli di Lync opzionali

Edge Server, Mediation Server, Monitoring Server, Archiving Server, Director Server : da installare, sullo stesso server o su server diversi (o su pool di server diversi) a seconda delle necessità organizzative.

Ruolo “Front-End Server” (obbligatorio)

E’ il ruolo centrale e più importante di Lync 2010. In una Standard Edition si installa su un unico server (unitamente al ruolo Back-End), mentre in una Enterprise Edition si installa su un server (o un pool di servers, per la ridondanza) separatamente dal ruolo Back-End. Il Front-End Server ha diversi compiti :

  • gestire le registrazioni di presenza e di telefonia degli utenti (utilizzando il componente denominato “Registrar”)
  • fornire servizi di conferenza audio/video, conferenza Web, conferenza dial-in, condivisione applicazioni, chat
  • gestire il CMS (Central Management Store), che comunica i dati di configurazione a tutti i server Lync dell’infrastruttura
  • fornire aggiornamenti ai client Lync 2010

Ruolo “Back-end Server” (obbligatorio)

E’ rappresentato dal server (con un’installazione di SQL) che fornisce i servizi di database al ruolo Front-End.  In una Standard Edition è installato assieme al ruolo Front-End, in una Enterprise Edition deve per forza essere un server separato dal Front-End, con possibilità di utilizzare più server in cluster per ottenere ridondanza.   In effetti, il Back-End Server non esegue nessun servizio specifico di Lync, ma solo i servizi di database.  Nel database sono memorizzate parecchie informazioni, tra cui :

  • presenza degli utenti
  • liste dei contatti
  • dati inerenti le conferenze e la loro schedulazione

Ruolo “Audio/Video Conferencing Server” (obbligatorio)

E’ di solito collocato con il Front-End Server, ma può anche essere collocato in un pool di server separato per ottenere scalabilità e ridondanza.  Richiede molta potenza di processore per le aziende che usano ampiamente questo tipo di conferenze.

Le conferenze audio/video permettono le comunicazioni audio e video in diretta tra gli utenti, semprechè gli utenti siano dotati di opportuni dispositivi come le cuffie/microfono per le conferenze audio, e le webcam per le conferenze video.

Questo ruolo gestisce anche le conferenze Web, che danno la possibilità agli utenti di vedere, condividere e collaborare su documenti online, oppure di condividere i loro desktop o le loro applicazioni.

Ruolo “Edge Server” (opzionale)

Dovrebbe essere sistemato nella DMZ aziendale, ha il compito di gestire le connessioni esterne degli utenti remoti, degli utenti federati, degli utenti anonimi che devono partecipare a conferenze Web, e degli utenti che utilizzano sistemi di chat pubblici.  Non serve se non si vuole garantire l’accesso dall’esterno alle features di Lync.

Più nel dettaglio, ecco di cosa si occupa il ruolo Edge :

  • fornire servizi di accesso agli utenti esterni per quanto riguarda il “signaling SIP”, la presenza e la chat (servizio “Access Edge”)
  • fornire servizi di conferenza web (servizio “Web Conferencing Edge”)
  • fornire servizi audio/video, di condivisione desktop e applicazioni e di trasferimento files (servizio “A/V Edge”)

Si può utilizzare un pool di server Edge per ottenere ridonandaza, opportunamente integrati con soluzioni di DNS Load balancing o Hardware Load Balancing.

Ruolo “Mediation Server” (opzionale)

Può essere collocato con il Front-End Server su singola macchina, oppure su un pool di server separati dal FE.  E’ il ruolo essenziale per l’implementazione della parte VoIP (Enterprise Voice).  Non serve se non si implementa e utilizza il VoIP.

Il suo compito primario è quello di “transcodificare” il traffico di Signaling e, in alcuni casi, il traffico di Media tra l’infrastruttura VoIP interna e i Gateway PSTN o gli apparati PBX o i SIP Trunk utilizzati per accedere alla rete PSTN pubblica.

Può essere configurato in diversi modi a seconda della topologia di rete aziendale, degli apparati di telecomunicazione presenti e del tipo di uscita verso la rete PSTN pubblica.

Ruolo “Director” (opzionale)

Ha il compito di autenticare utenti interni ed esterni, redirezionandoli al corretto pool di server.  E’ utile se l’azienda ha implementato diversi pool nell’infrastruttura (quindi solo per aziende di grosse dimensioni), garantendo anche l’accesso dall’esterno agli utenti.   Se implementato, toglie ai pool di server Front-End il sovraccarico di lavoro per eseguire le autenticazioni, e questo migliora le performance : in questo caso tutte le richieste di accesso fluiscono prima verso il Director, che poi ne esegue il routing verso il corretto pool di Front-End.

Il Director è sempre un server separato dal Front-End, e non collocato con altri ruoli Lync.  E’ possibile creare un pool di Directors per la ridondanza, a patto di implementare anche soluzioni di Load Balancing.

Ruolo “Monitoring Server” (opzionale)

Ha il compito di collezionare informazioni su QOE (Quality of Experience) e CDR (Call Details Record).  Richiede la presenza di database che usino SQL Server : questi possono essere collocati sul Monitoring Server stesso, o su server differenti.  Se si decide di utilizzare anche la reportistica, bisogna prevedere la presenza anche di SQL Server Reporting Services.

Il Monitoring Server non può essere collocato con il Front-End.  Può invece essere collocato assieme all’Archiving Server : in questo caso, i loro database possono essere collocati sul server stesso, oppure separati su differenti server.   Il server che ospita i database del Monitoring Server può anche ospitare altri database utilizzati da altri tuoli di Lync, oppure database utilizzati da prodotti di terze parti.

Ruolo “Archiving Server” (opzionale)

Ha il compito di archiviare i messaggi di chat e le conferenze, specificando per quali utenti è abilitata l’archiviazione.

Si può abilitare l’archiviazione per comunicazioni tra utenti interni, o tra interni ed esterni.

Alcuni tipi di contenuto non sono archiviabili :

  • trasferimenti di files peer-to-peer
  • condivisione di applicazioni
  • annotazioni e sondaggi nelle conferenze

Per la collocazione dell’Archiving Server, valgono le stesse regole del Monitoring Server.

Cosa sono i “Siti” in Lync Server 2010 e come bisogna progettarli

Generalmente, un “Sito” rappresenta una locazione geografica della rete aziendale. Più precisamente, possiamo definire “Sito” un insieme di computers ben connessi fra loro su una rete ad alta velocità e bassa latenza (per esempio una singola LAN, o due diverse LAN connesse da fibra ottica).

Segnalo subito che i Siti di Lync sono un concetto separato dai Siti di Active Directory o da quelli di Exchange.  I Siti di Lync non devono necessariamente corrispondere ai Siti di Active Directory.

La prima cosa da definire progettando Lync, è il posizionamento del o dei “Central Site” e degli eventuali “Branch Sites”.

I “Central Sites” devono contenere il ruolo “Front-End Server”, che fornisce i servizi Lync essenziali : si può scegliere se installare un unico server Standard Edition, oppure un Pool di servers, che rappresenteranno il cosiddetto “Front-End Pool” (questo per questioni di ridondanza).  Ci deve essere per forza almeno un Central Site.  Il Central Site è tipicamente una locazione in cui esiste un datacenter e in cui ci siano persone IT esperte per la gestione.  Si possono creare anche diversi Central Site.

I “Branch Sites” possono essere assenti dalla topologia (per esempio chi non ha nessuna sede esterna), oppure essere presenti in gran numero.  Ogni Branch Site deve essere “affiliato” con un (e solo un) Central Site, in relazione padre-figlio.  Gli utenti presenti nel Branch Site ricevono i servizi Lync dai server presenti nel loro Central Site “padre”.   I Branch Site sono quindi consigliati per le sedi esterne e di ridotte dimensioni dell’azienda, dove probabilmente latita anche il personale IT esperto per la gestione.

In un Branch Site si può prevedere la presenza, a scelta, dei seguenti dispositivi :

  1. Un “Survivable Branch Appliance” (SBA) : è un nuovo dispositivo introdotto in Lync Server 2010.  Si tratta di un Blade Server, con pre-installati dal vendor Windows Server 2008 R2 e i servizi di Registrar e di Mediation di Lync Server 2010; inoltre contiene un PSTN Gateway. L’SBA è progettato per siti contenenti da 25 a 1000 utenze
  2. Un “Survivable Branch Server” (SBS) : è un nuovo dispositivo introdotto in Lync Server 2010. Si tratta di un regolare server che esegue Windows Server 2008 R2, anch’esso con i componenti Registrar e Mediation di Lync installati. Deve connettersi ad un PSTN Gateway oppure ad un SIP Trunk stabilito con un provider di servizi di telefonia (ITSP). L’SBS è progettato per siti contenenti da 1000 a 5000 utenze
  3. Un semplice PSTN Gateway e, opzionalmente, un Mediation Server

Per Branch Sites dove non esiste ridondanza del collegamento di rete verso il sito centrale, è indicato il deploy di SBA o SBS (le precedenti opzioni 1 e 2), che forniscono ridondanza in caso di interruzione del collegamento WAN : per esempio, gli utenti possono ancora fare e ricevere chiamate VoIP anche senza il collegamento al sito centrale.

Per Branch Sites con le linee WAN già ridondate, è utile la terza opzione : si possono connettere al sito centrale con il PSTN Gateway, ed opzionalmente possono anche usare il Mediation Server.

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

Implementare Lync Server 2010 : Parte 7

Scritto da Ivan Salvade' il 6 novembre 2011

In questa settima parte dell’articolo vedremo come configurare l’accesso degli utenti esterni alla nostra infrastruttura Lync.

Ecco i link alle precedenti parti pubblicate :

—————————————————————————————————————————————————————————————————————————-

Ci sono diverse tipologie di utenze esterne che possono collegarsi alla nostra infrastruttura Lync 2010 :

  • Utenti Remoti : utenti con utenza di dominio interna, che si trovano in siti esterni.  Hanno accesso a tutte le features di Lync
  • Utenti Federati : utenti di un’azienda partner esterna.  Possono accedere alla maggior parte delle features di Lync
  • Utenti Anonimi : non hanno account nel vostro dominio o in quello di un’azienda federata.  Possono partecipare, su invito, a chat e conferenze audio/video ospitate nell’infrastruttura Lync interna

Il componente principale necessario per il supporto delle connessioni esterne è il ruolo Edge di Lync Server 2010, installato in DMZ e possibilmente su server in workgroup.   I suoi servizi principali sono :

  • Access Edge Service : invia e riceve comunicazioni su protocollo SIP
  • Web Conferencing Edge Service : connette gli utenti esterni a conferenze e meeting ospitati sui Lync Server interni
  • A/V Edge Service : rende disponibile agli utenti esterni la condivisione di video, audio, applicazioni, desktop e il trasferimento di files

I passi generali per l’implementazione dell’accesso esterno ai servizi Lync sono i seguenti :

  1. Riconfigurare la topologia Lync ad includere un server Edge (o un pool di server Edge) e i suoi relativi componenti (si usa il Topology Builder)
  2. Esportare la nuova configurazione verso il server Edge
  3. Installare il server Edge
  4. Richiedere ed assegnare gli opportuni certificati
  5. Far partire i servizi Lync del server Edge
  6. Creare i necessari record DNS
  7. Testare l’accesso dall’esterno

N.B. : la topologia dell’accesso di utenti esterni ai servizi Lync può essere configurata in numerosi modi, dipendenti da parecchie variabili.  I task spiegati in questo articolo funzioneranno per la tipologia di rete (che tra poco indicherò) presente nello scenario del mio esempio.   Ulteriori e/o diversi task si possono rendere necessari se un’azienda ha un’architettura di rete diversa.   Quindi questo articolo non può essere esaustivo e valido per qualunque configurazione.   Consiglio di leggere con attenzione la “Lync Server 2010 Planning Guide”, scaricabile gratuitamente al seguente link, e di consultare il capitolo 6 “Planning for External User Access” :

http://www.microsoft.com/download/en/details.aspx?id=21646

Ecco alcune variabili che possono modificare le fasi di implementazione dell’accesso esterno :

  • Presenza di un singolo server Front-End o di un Pool
  • Utilizzo di un singolo server Edge o di un Pool
  • Utilizzo o meno di DNS Load Balancing
  • Utilizzo o meno di Bilanciatori Hardware
  • Quantità di servizi da rendere disponibile all’esterno
  • Utilizzo di uno o più domini SIP
  • Utilizzo di dominio SIP uguale al dominio Active Directory, oppure diverso
  • Utilizzo o meno di Reverse Proxy
  • In caso di utilizzo di Reverse Proxy, se singolo o in bilanciamento di carico
  • Utilizzo o meno della configurazione automatica dei client esterni
  • Conformazione della DMZ aziendale
  • Utilizzo o meno di NAT tra le interfacce esterne di Edge e Reverse Proxy e Internet
  • Presenza o meno di un Director Server interno
  • Restrizioni sulle porte apribili nei firewall aziendali

Come potete vedere, ogni modifica di una singola variabile può portare a differenze di configurazione;  quindi questo articolo deve essere inteso come PURAMENTE DIMOSTRATIVO.

Ecco lo scenario della mia dimostrazione :

  • MIA-DC1     indirizzo IP interno 10.0.10.10     è DNS interno, Domain Controller e Certification Authority
  • MIA-LS1      indirizzo IP interno 10.0.10.12     è il server Lync Front-End standalone, membro di dominio
  • MIA-ED1     sarà il server Lync con il ruolo Edge, in workgroup.   E’ dotato di vari indirizzi IP :
    • 10.0.10.14          indirizzo IP interno
    • 172.16.10.100    indirizzo IP esterno; sarà utilizzato dal servizio Access Edge
    • 172.16.10.101     indirizzo IP esterno; sarà utilizzato dal servizio Web Conferencing Edge
    • 172.16.10.102    indirizzo IP esterno; sarà utilizzato dal servizio A/V Edge
  • MIA-RAS1    è un server RRAS che esegue il routing tra rete interna (10.0.10.0/24) e rete esterna (172.16.10.0/24).  Simula anche un DNS server esterno.  E’ dotato di due interfacce di rete con i seguenti indirizzi IP :
    • interfaccia interna  10.0.10.1
    • interfaccia esterna  172.16.10.1
  • INT-CL4     indirizzo IP 172.16.10.20     è un client che simula di stare su Internet
  • Ulteriori informazioni :
    • il dominio Active Directory è “Fabrikam.com”; il dominio SIP è “Fabrikam.com”; il dominio esterno è “Fabrikam.com”.   Quindi, nel mio esempio, i 3 domini coincidono : in realtà, potrebbe NON essere il caso di tutti
    • ho scelto di non utilizzare NAT tra le interfacce esterne del server Edge e Internet
    • non implementerò il Reverse Proxy
    • non implementerò bilanciamenti di carico (nè DNS, nè hardware)
    • DMZ e Internet sono la stessa rete : 172.16.0.0

Cominciamo con la riconfigurazione della topologia esistente, creata fino alla parte 6 dell’articolo.  Si apre il Lync Server Topology Builder sulla macchina dove è stato installato (nel mio esempio, il server di Front-End), e si scarica la topologia già esistente (Fig. 1) :

ed1.JPG    Fig. 1

Si indica di salvare la nuova topologa in un file di appoggio (Fig. 2) :

ed2.JPG    Fig. 2

Si procede alla definizione di un nuovo Edge Pool (Figg. 3 e 4) :

ed3.JPG    Fig. 3

ed4.JPG    Fig. 4

Si inserisce il nome del pool, specificando che useremo un singolo computer nel pool (MIA-ED1.fabrikam.com) (Fig. 5) :

ed5.JPG    Fig. 5

Nella lista delle features, scegliere se abilitare o no la federazione con aziende partner.  Avrei anche potuto scegliere se utilizzare un unico nome e indirizzo IP per i tre servizi fondamentali del ruolo Edge, e se nattare l’indirizzo IP esterno.  Nel mio esempio, abilito la federazione, ma scelgo di non nattare gli indirizzi esterni, nè di utilizzare un singolo IP (Fig. 6) :

ed6.JPG    Fig. 6

Nella definizione dei FQDN esterni, utilizzo le seguenti configurazioni (Fig. 7) :

  • SIP Access : “sip.fabrikam.com”, su porta 443
  • Web Conferencing : “webconf .fabrikam.com”, su porta 443
  • Audio/Video : “avconf.fabrikam.com”, su porta 443

ed7.JPG    Fig. 7

Dichiaro l’indirizzo IP interno del server Edge (10.0.10.14) (Fig. 8 ) :

ed8.JPG    Fig. 8

Dichiaro gli indirizzi IP esterni del server Edge, come da prospetto seguente (Fig 9) :

  • SIP Access : 172.16.10.100
  • Web Conferencing : 172.16.10.101
  • A/V Conferencing : 172.16.10.102

ed9.JPG    Fig. 9

Come “Next hop pool”, indico il Front-End Server (Figg. 10 e 11) :

eda.JPG    Fig. 10

edb.JPG    Fig. 11

Ecco il riassunto della nuova configurazione (Fig. 12) :

edc.JPG    Fig. 12

Modifico le proprietà del sito per attivare la federazione (se necessario) (Figg. 13 e 14) :

edd.JPG    Fig. 13

ede.JPG    Fig. 14

Ora pubblico la nuova topologia (Figg. 15 e 16) :

edf.JPG    Fig. 15

edg.JPG    Fig. 16

Con un comando di powershell, esporto la nuova topologia in un file, che poi importerò nel server Edge (Fig. 17 e 18).   Il comando powershell è il seguente :

Export-CSConfiguration -Filename c:\Config.zip

edh.JPG    Fig. 17

edi.JPG      Fig. 18

Ora, su MIA-ED1, inizio la procedura di installazione del ruolo Edge, utilizzando la nuova topologia appena esportata.  Devo ovviamente prima eseguire un copia e incolla su MIA-ED1 della topologia (Fig. 19) :

edj.JPG    Fig. 19

Si lancia il setup di Lync dal DVD (Figg. 20 e 21) :

edk.JPG    Fig. 20

edl.JPG    Fig. 21

Su ogni server della topologia Lync, devo creare il Local Configuration Store; questa volta l’importazione avviene utilizzando il file precedentemente esportato da MIA-LS1 (Figg. 22, 23, 24) :

edm.JPG    Fig. 22

edn.JPG    Fig. 23

edo.JPG    Fig. 24

Ora eseguo lo Step 2 che installa i componenti Edge (Figg. 25 e 26) :

edp.JPG    Fig. 25

edq.JPG    Fig. 26

Si lancia lo Step 3 che assegna i corretti certificati (Fig. 27) :

edr.JPG    Fig. 27

Prima si richiede alla CA interna il certificato per l’interfaccia interna del ruolo Edge (Fig. 28) :

eds.JPG   Fig. 28

Avendo una CA interna, spedisco direttamente la richiesta (Fig. 29) :

edt.JPG    Fig. 29

MIA-ED1 è una macchina di workgroup, quindi non può rilevare la CA da Active Directory. Allora la specifichiamo noi (Fig. 30) :

edu.JPG    Fig. 30

Se la password di Amministratore locale di MIA-ED1 è uguale alla password di Amministratore di dominio, non serve specificare credenziali alternative; altrimenti sì (Fig. 31) :

edv.JPG    Fig. 31

Assegnare un nome amichevole al certificato interno (Fig. 32) :

edw.JPG    Fig. 32

Compilare le informazioni da inserire nella richiesta (Figg. 33 e 34) :

edx.JPG    Fig. 33

edy.JPG    Fig. 34

Il certificato viene rilasciato; lasciare impostato il flag di Fig. 35, per accedere alla procedura di assegnazione (Fig. 36) :

edz1.JPG    Fig. 35

edz2.JPG    Fig. 36

Verificare che il certificato venga correttamente assegnato (Figg. 37 e 38) :

edz3.JPG    Fig. 37

edz4.JPG    Fig. 38

Ora si richiede alla CA interna il certificato per le interfacce esterne del ruolo Edge (Fig. 39) :

edz5.JPG   Fig. 39

La procedura è molto simile alla precedente.  Per brevità, non riporto tutte le schermate.  Accettate i valori di default nelle scermate non mostrate (Figg 40,41,42) :

edz6.JPG    Fig. 40

edz7.JPG    Fig. 41

edz8.JPG    Fig. 42

Ecco l’esito finale (Fig. 43) :

edz9.JPG    Fig. 43

Nello Step 4 si fanno partire i servizi Edge (Fig. 44).  In Fig. 45 un estratto della console dei Servizi :

edza.JPG    Fig. 44

edzb.JPG    Fig. 45

Ora si devono creare i necessari record DNS esterni per l’accesso degli utenti esterni.  Il server MIA-RAS1 simula proprio un DNS su Internet; su di lui esiste già la zona “Fabrikam.com” (Fig. 46) :

edzc.JPG    Fig. 46

Tre record di tipo A devono essere creati, che risolvono i nomi Sip, Webconf e AVconf ai giusti IP esterni (Fig. 47) :

edze.JPG    Fig. 47

Inoltre bisogna creare i seguenti record SRV (Figg. 48, 49, 50, 51) :

  • _sipexternaltls  che utilizzi protocollo TCP su porta 443 e il nome “sip.fabrikam.com”
  • _sipfederationtls che utilizzi protocollo TCP su porta 5061 e il nome “sip.fabrikam.com”
  • _sip che utilizzi protocollo TLS su porta 443 e il nome “sip.fabrikam.com”

N.B. : se il dominio AD e il dominio SIP sono diversi (es. dominio AD = azienda.local e dominio SIP = azienda.com), con questa configurazione si avrebbero problemi ad effettuare l’autoconfigurazione dei client interni.  Bisogna utilizzare una strategia DNS opportuna (testimoniata nella Planning Guide di Lync 2010), che consiste nel creare anche sul DNS interno una copia della zona esterna, oppure utilizzare le zone “pin-point”, creabili nel DNS solo da linea di comando.   Non escludo la possibilità, in un futuro articolo, di spiegarvi step-by-step uno scenario simile.

edzf.JPG    Fig. 48

edzg.JPG    Fig. 49

edzh.JPG    Fig. 50

edzi.JPG    Fig. 51

Si attiva ora la possibiltà di accesso agli utenti esterni dal Lync Server Control Panel (Figg. 52 e 53) :

edzl.JPG    Fig. 52

edzm.JPG    Fig. 53

edzn.JPG    Fig. 54

Come procedura di controllo, affinchè tutto funzioni è necessario accertarsi che nel DNS interno (MIA-DC1) sia presente il record di tipo A riferito all’interfaccia interna del server Edge (Fig. 55), oltre ai record già indicati nella parte 6 dell’articolo :

edzo-intern-dns-must-exist-a-rec-mia-ed1.JPG    Fig. 55

Ora il tentativo di autoconfigurazione e connessione di un client esterno deve dare esito positivo.

Questo era l’ultimo articolo della serie…

… e allora buon Lync a tutti!!!  :-)  :-)

  • Share/Bookmark

Pubblicato in Lync Server 2010 | 8 Commenti »

 
Usiamo i cookie per assicurarti la migliore esperienza di navigazione nel nostro sito web.
Ok