Lync Server 2010 | Ivan Salvade'\nIl mio punto di vista su Virtualizzazione, Sicurezza, Messaggistica, Network Management…\nCorsi e Certificazioni (8)\nExchange Server 2007 (9)\nExchange Server 2010 (37)\nExchange Server 2013 (19)\nGestione dei Sistemi (15)\nLync Server 2013 (5)\nSystem Center Configuration Manager 2012 (9)\nSystem Center Data Protection Manager 2012 (2)\nSystem Center Operations Manager 2012 (2)\nSystem Center Virtual Machine Manager 2012 (2)\nSeleziona mese gennaio 2016 (1) ottobre 2015 (2) maggio 2015 (1) agosto 2014 (1) luglio 2014 (2) giugno 2014 (1) marzo 2014 (2) febbraio 2014 (3) gennaio 2014 (1) novembre 2013 (1) ottobre 2013 (3) settembre 2013 (1) agosto 2013 (1) luglio 2013 (2) giugno 2013 (11) maggio 2013 (10) aprile 2013 (6) marzo 2013 (2) febbraio 2013 (2) gennaio 2013 (1) novembre 2012 (3) ottobre 2012 (6) settembre 2012 (10) luglio 2012 (3) giugno 2012 (6) maggio 2012 (4) aprile 2012 (4) marzo 2012 (2) febbraio 2012 (2) gennaio 2012 (4) dicembre 2011 (5) novembre 2011 (7) ottobre 2011 (8) settembre 2011 (7) luglio 2011 (6) giugno 2011 (6) maggio 2011 (6) aprile 2011 (6) marzo 2011 (6) febbraio 2011 (5) gennaio 2011 (4) novembre 2010 (1) ottobre 2010 (1)\nWindows 10 non visualizza e non installa gli aggiornamenti\nRoadmap dei prodotti Microsoft 2015-2016\nAlessandro Spiandore su Quante CAL servono al mio server Exchange 2013?\nIvan Salvade' su Come compattare i files .pst di Outlook\nDanilo su Come compattare i files .pst di Outlook\nAntonella su Precisazioni sul licensing della suite System Center 2012\nFabrizio su Bloccare lo spam interno (dal proprio dominio di posta) in Exchange Server\nIvan's TOP Articles\nLync Server 2010 : creare IVR a più livelli con Powershell\nPipeline (CPLS Microsoft Gold Partner)\nAccesso C$ Cluster Shared Volumes Condivisione amministrativa CSV Datacenter Domain Controller Enterprise Event ID Exchange 2007 Exchange 2010 Exchange 2010 SP1 Exchange 2010 SP3 Exchange 2013 Exchange Server 2010 Exchange Server 2013 Front-end G.711 Hyper-V Installare installazione Ivan Salvade Live Migration LUN Lync Server 2010 Lync Server 2013 R2 Roadmap RTM RU1 RU4 SAN SCCM 2012 Server Virtualization SP1 STandard System Center 2012 Update Rollup 1 Update Rollup 4 Windows 7 Windows 8 Windows 2008 Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2\nArchivi per la categoria 'Lync Server 2010' Categoria\nCreazione di un IVR (Response Group) a più livelli in Lync Server 2010\nScritto da Ivan Salvade' il 5 luglio 2013\nIn Lync Server 2010, è possibile creare un IVR (Interactive Voice Response) tramite strumenti grafici oppure tramite comandi di powershell.\nIl limite imposto dall’uso degli strumenti grafici è quello di poter creare solo 2 domande con un massimo di 4 risposte possibili per ogni domanda.\nSe 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.\nUn IVR creato con comandi powershell, non è più editabile con gli strumenti grafici.\nIn questo articolo illustrerò come creare un intero IVR con una sola domanda, ma 6 risposte possibili, utilizzando comandi powershell.\nLa 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.\nL’architettura generale del mio IVR di esempio sarà la seguente :\nArriva una chiamata ad un numero aziendale associato al IVR\nIl sistema verifica il giorno e l’orario di ricezione della chiamata, effettuando le seguenti scelte :\nse la chiamata giunge in un giorno festivo, viene riprodotto un messaggio ”Call Center chiuso per festività”, e la chiamata è terminata\nse 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\nse 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 :\ndigitare 1 per parlare col reparto Vendite\ndigitare 2 per parlare col reparto Amministrazione\ndigitare 3 per parlare col reparto Assistenza Tecnica\ndigitare 4 per parlare col reparto Produzione\ndigitare 5 per parlare col reparto IT\ndigitare 6 per parlare col Centralino (Operatore)\nIn 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\nI comandi utili alla creazione del IVR sono i seguenti :\nNew-CsRgsQueue / Get-CsRgsQueue / Set-CsRgsQueue\nNew-CsRgsWorkflow / Set-CsRgsWorkflow\nLe operazioni da eseguire sono le seguenti, nel preciso ordine indicato :\nCreazione dei Gruppi di Agenti (i vari operatori interni che risponderanno alle chiamate)\nCreazione delle Code (mantengono in coda i chiamanti, finchè un agente non risponderà)\nCreazione delle Business Hours (ore di lavoro in cui gli agenti sono disponibili)\nCreazione degli Holidays (giornate in cui gli agenti non sono disponibili)\nCreazione degli Holiday Set (raggruppano gli Holidays, in modo da poterli associare più comodamente al IVR)\nCreazione dei Prompt (messaggi vari da riprodurre ai chiamanti)\nCreazione delle Azioni (operazioni da eseguire in base alle scelte/comportamenti dei chiamanti)\nConfigurazione delle Azioni di Timeout e Overflow nelle Code\nCreazione delle Risposte (per comprendere le scelte dei chiamanti, e lanciare le Azioni corrispondenti)\nCreazione delle Domande (domande poste dal IVR ai chiamanti, per permettere loro di esercitare una scelta)\nCreazione della Default Action del Workflow (azione da eseguire se la chiamata al IVR giunge in orari di lavoro)\nCreazione del Workflow (il flusso di lavoro finale, completo di domande, risposte, azioni e interconnessioni tra di loro)\nNei seguenti comandi esemplificativi, si suppone che il server Lync di Front-End con il servizio RGS si chiami FE.contoso.com\nN.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.\nN.B. : legenda dei comandi :\nin 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\nCreazione dei Gruppi di Agenti\nOgni gruppo conterrà le utenze abilitate a rispondere per conto di un certo reparto scelto dai chiamanti (Vendite, Produzione, ecc..).\nI 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.\nCon 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).\nUn 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.\nEcco i comandi per creare i 6 gruppi necessari al mio IVR esemplificativo :\n$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“)\n$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“)\n$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“)\n$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“)\n$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“)\n$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“)\nCreazione delle Code\nPer 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.\nAnche 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.\nNei miei esempi sottostanti, ho utilizzato solo i parametri strettamente indispensabili (”-Name” e “-AgentGroupIDList”), ma ne esistono altri :\n-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\n-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”\n-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.\n-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”\n-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”\nEcco i comandi per creare le 6 code necessarie al mio IVR esemplificativo :\n$CodaVendite=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com” -Name “CodaVendite” -AgentGroupIDList ($GruppoVendite.Identity)\n$CodaAmministrazione=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com” -Name “CodaAmministrazione” -AgentGroupIDList ($GruppoAmministrazione.Identity)\n$CodaAssistenza=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com” -Name “CodaAssistenza” -AgentGroupIDList ($GruppoAssistenza.Identity)\n$CodaIT=New-CsRgsQueue -Parent “Service:ApplicationService:FE.contoso.com” -Name “CodaIT” -AgentGroupIDList ($GruppoIT.Identity)\n$CodaProduzione=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com” -Name “CodaProduzione” -AgentGroupIDList ($GruppoProduzione.Identity)\n$CodaOperatore=New-CsRgsQueue -Parent “Service:ApplicationServer:FE.contoso.com” -Name “CodaOperatore” -AgentGroupIDList ($GruppoOperatore.Identity)\nCreazione delle Business Hours\nServono a definire le ore di lavoro in cui il Contact Center è attivo (e quindi gli agenti sono disponibili).\nPrima 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” :\n$AperturaMattina=New-CsRgsTimeRange -Name OrarioMattina -OpenTime “09:00″ -CloseTime “13:00″\n$AperturaPomeriggio=New-CsRgsTimeRange -Name OrarioPomeriggio -OpenTime “14:00″ -CloseTime “18:00″\nSe l’orario di apertura fosse continuo (es. dalle 08:00 alle 22:00), sarebbe sufficiente uno solo dei comandi precedenti.\nPoi si crea l’effettivo oggetto “Business Hours”, nel quale si indicano anche le giornate precise di apertura, utilizzando il comando “New-CsRgsHoursOfBusiness”.\nQuesto 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.\nE’ 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.\nSe in alcune giornate il Call Center è totalmente chiuso, non indicare i parametri per quelle giornate.\nEcco il comando per creare gli orari di apertura spezzati, da lunedì a venerdì, per il mio IVR esemplificativo :\n$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\nCreazione degli Holidays e degli Holiday Set\nAl 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 :\nN.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.\n$capodanno = New-CsRgsHoliday -Name “capodanno” -StartDate “01/01/2014″ -EndDate “02/01/2014″\n$25aprile = New-CsRgsHoliday -Name “25aprile” -StartDate “25/04/2014″ -EndDate “26/04/2014″\n$1maggio = New-CsRgsHoliday -Name “1maggio” -StartDate “01/05/2014″ -EndDate “02/05/2014″\n$2giugno = New-CsRgsHoliday -Name “2giugno” -StartDate “02/06/2014″ -EndDate “03/06/2014″\n$15agosto = New-CsRgsHoliday -Name “ferragosto” -StartDate “15/08/2014″ -EndDate “16/08/2014″\n$1nov = New-CsRgsHoliday -Name “1novembre” -StartDate “01/11/2014″ -EndDate “02/11/2014″\n$8dic = New-CsRgsHoliday -Name “8dicembre” -StartDate “08/12/2014″ -EndDate “09/12/2014″\n$natale = New-CsRgsHoliday -Name “natale” -StartDate “25/12/2014″ -EndDate “27/12/2014″\n$pasqua = New-CsRgsHoliday -Name “pasqua” -StartDate “20/04/2014″ -EndDate “22/04/2014″\nLe 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” :\n$FestiviIVR=New-CsRgsHolidaySet -Parent “Service:ApplicationServer:FE.contoso.com” -Name Feste2014 -HolidayList ($capodanno,$25aprile,$1maggio,$2giugno,$15agosto,$1nov,$8dic,$natale,$pasqua)\nIn ogni anno seguente, l’elenco delle festività dovrà essere aggiornato, inserendo quelle nuove ed agganciandole al workflow.\nCreazione dei Prompt\nSi 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″ …).\nLa procedura di creazione varia a seconda che si utilizzino files audio preregistrati, oppure stringhe di testo che la voce automatica dovrà leggere.\nNel mio IVR esemplificativo, suppongo di voler utilizzare i seguenti Prompt :\nPrompt di benvenuto al Call Center (da riprodurre negli orari di apertura del Call Center; contiene la domanda principale del IVR)\nPrompt di Call Center chiuso per festività (da riprodurre nei festivi)\nPrompt di Call Center fuori orario di lavoro (da riprodurre negli orari di chiusura del Call Center)\nPrompt di attesa (da riprodurre quando i chiamanti vengono messi in attesa in coda di risposta)\nPrompt di risposta sbagliata (da riprodurre quando i chiamanti digitano una risposta sbagliata, cioè non compresa tra 1 e 6)\nPrompt di risposta assente (da riprodurre quando i chiamanti non indicano risposte alla domanda del IVR)\nPrompt 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)\nHo 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.\nN.B. : per evitare un errore del IVR con codice evento 31117 e una descrizione simile a questa :\n(System.ArgumentNullException: Value cannot be null. Parameter name: alternateText at Microsoft.Speech.Synthesis.PromptBuilder.AppendAudio(Uri audioFile, String alternateText)\n… è 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.\nCominciamo 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 :\n$AudioBenvenuto=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptBenvenuto.wav -Content (Get-Content “C:\_Audiofiles\_PromptBenvenuto.wav” -Encoding Byte -ReadCount 0)\n$PromptBenvenuto=New-CsRgsPrompt -AudioFilePrompt $AudioBenvenuto -TextToSpeechPrompt “messaggio di benvenuto e proposizione della prima domanda di scelta”\n$AudioFesta=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptFesta.wav -Content (Get-Content “C:\_Audiofiles\_PromptFesta.wav” -Encoding Byte -ReadCount 0)\n$PromptFesta=New-CsRgsPrompt -AudioFilePrompt $AudioFesta -TextToSpeechPrompt “Siamo chiusi per festività. Si prega di richiamare in giornate feriali”\n$AudioChiusura=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptChiusura.wav -Content (Get-Content “C:\_Audiofiles\_PromptChiusura.wav” -Encoding Byte -ReadCount 0)\n$PromptChiusura=New-CsRgsPrompt -AudioFilePrompt $AudioChiusura -TextToSpeechPrompt “In questo momento siamo chiusi. Si prega di richiamare in orari di lavoro”\n$AudioAttesa=Import-CsRgsAudioFile -Identity Service:ApplicationServer:FE.Contoso.com -Filename PromptAttesa.wav -Content (Get-Content “C:\_Audiofiles\_PromptAttesa.wav” -Encoding Byte -ReadCount 0)\n$PromptAttesa=New-CsRgsPrompt -AudioFilePrompt $AudioAttesa -TextToSpeechPrompt “Siete pregati di rimanere in attesa della risposta degli operatori”\nOra creiamo i Prompt basati su stringhe di testo (Text-to-Speech : ci penserà la voce robotica di Lync a leggere la stringa ai chiamanti) :\n$PromptErroreScelta=New-CsRgsPrompt -TextToSpeechPrompt “La risposta non è tra quelle consentite. Si prega di correggere la selezione”\n$PromptNessunaScelta=New-CsRgsPrompt -TextToSpeechPrompt “Non è stata digitata alcuna scelta. Si prega di riprovare”\n$PromptOverflow=New-CsRgsPrompt -TextToSpeechPrompt “In questo momento il Call Center è sovraccarico. Si prega di riprovare più tardi”\nLe Azioni rappresentano le operazioni che l’IVR deve eseguire all’accadimento di un certo evento. Esempi possono essere :\nazione da eseguire se giunge al IVR una chiamata in giorni festivi\nazione da eseguire se giunge al IVR una chiamata fuori orari di lavoro\nazione da eseguire se giunge al IVR una chiamata in orario di lavoro\nazione da eseguire se il chiamante esercita una certa scelta in risposta ad una domanda del IVR\nazione da eseguire se un chiamante viene inserito in una coda che risulta già piena (overflow di coda)\nazione da eseguire se un operatore non risponde ad un chiamante entro una certa tempistica (time-out di coda)\nLe azioni si creano con il cmdlet New-CsRgsCallAction. Il suo parametro più importante è “-Action“, che può avere i seguenti valori :\nTerminate : termina direttamente la chiamata\nTransferToQueue : trasferisce una chiamata alla coda specificata\nTransferToQuestion : trasferisce una chiamata ad una domanda successiva posta dal IVR\nTransferToURI : trasferisce una chiamata ad uno specifico SIP URI\nTransferToVoiceMailURI : trasferisce una chiamata ad una segreteria telefonica (es. Exchange Unified Messaging)\nTransferToPSTN : trasferisce una chiamata ad un numero telefonico PSTN (rete pubblica)\nSi crea l’azione da eseguire se giunge una chiamata in giornate festive :\n$AzioneFesta=New-CsRgsCallAction -Prompt $PromptFesta -Action Terminate\nSi crea l’azione da eseguire se giunge una chiamata in orari di chiusura del Call Center :\n$AzioneChiusura=New-CsRgsCallAction -Prompt $PromptChiusura -Action Terminate\nSi 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) :\n$AzioneOverflow=New-CsRgsCallAction -Prompt $PromptOverflow -Action Terminate\nSi crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 1 :\n$Azione1=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaVendite.Identity (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)\nSi crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 2 :\n$Azione2=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaAmministrazione.Identity (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)\nSi crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 3 :\n$Azione3=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaAssistenza.Identity (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)\nSi crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 4 :\n$Azione4=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaProduzione.Identity (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)\nSi crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 5 :\n$Azione5=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaIT.Identity (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)\nSi crea l’azione da eseguire se giunge una chiamata in orario di apertura del Call Center, e il chiamante sceglie l’opzione 6 :\n$Azione6=New-CsRgsCallAction -Prompt $PromptAttesa -Action TransferToQueue (oppure TransferToQuestion, Terminate, TransferToUri, TransferToVoiceMailUri, TransferToPstn) -QueueID $CodaOperatore.Identity (questo parametro è obbligatorio se Action è impostato su “TransferToQueue”)\nOra 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).\nEcco i comandi per impostare l’azione di Overflow/Timeout sulle code (queste sono ancora memorizzate nelle variabili utilizzate nella sezione di creazione delle code) :\nN.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).\nSet-CsRgsQueue -Instance $CodaVendite\nSet-CsRgsQueue -Instance $CodaAmministrazione\nSet-CsRgsQueue -Instance $CodaAssistenza\nSet-CsRgsQueue -Instance $CodaIT\nSet-CsRgsQueue -Instance $CodaProduzione\nSet-CsRgsQueue -Instance $CodaOperatore\nCreazione delle Risposte\nLe 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.\nLe Risposte si creano con il comando “New-CsRgsAnswer”. I suoi parametri più importanti sono :\n-DTMFResponse : indica il tasto da premere sul tastierino da parte del chiamante, per esercitare una scelta\n-VoiceResponseList : indica la parola da enunciare da parte del chiamante, per esercitare una scelta\n-Action : indica l’azione da eseguire. Questa deve essere già stata creata con il comando New-CsRgsCallAction (vedi sezione precedente)\nN.B. : non è obbligatorio inserire entrambi i parametri “-DTMFResponse” e “-VoiceResponseList” : è sufficiente almeno uno dei due.\nCreiamo ora tutte le Risposte necessarie ad intercettare le varie opzioni di scelta (da 1 a 6) del mio IVR esemplificativo :\n$Risposta1=New-CsRgsAnswer -DTMFResponse 1 -VoiceResponseList “uno” -Action $Azione1\n$Risposta2=New-CsRgsAnswer -DTMFResponse 2 -VoiceResponseList “due” -Action $Azione2\n$Risposta3=New-CsRgsAnswer -DTMFResponse 3 -VoiceResponseList “tre” -Action $Azione3\n$Risposta4=New-CsRgsAnswer -DTMFResponse 4 -VoiceResponseList “quattro” -Action $Azione4\n$Risposta5=New-CsRgsAnswer -DTMFResponse 5 -VoiceResponseList “cinque” -Action $Azione5\n$Risposta6=New-CsRgsAnswer -DTMFResponse 6 -VoiceResponseList “sei” -Action $Azione6\nCreazione delle Domande (nel mio esempio, una sola domanda)\nLa 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.\n$Domanda1=New-CsRgsQuestion -Prompt $PromptBenvenuto -AnswerList $Risposta1,$Risposta2,$Risposta3,$Risposta4,$Risposta5,$Risposta6 -InvalidAnswerPrompt $PromptErroreScelta -NoAnswerPrompt $PromptNessunaScelta\nCreazione della Default Action del Workflow\nLa “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) :\n$AzioneDefault=New-CsRgsCallAction -Action TransferToQuestion -Question $Domanda1\nCreazione del Workflow finale\nOra siamo pronti ad inserire tutti gli oggetti creati nel Workflow finale, che darà vita al IVR vero e proprio.\nIl 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”.\nI parametri più importanti del comando “New-CsRgsWorkflow” sono i seguenti :\n-LineURI : indica il numero di telefono a cui è raggiungibile il Call Center dall’esterno\n-Active : indica se il Call Center deve essere subito attivo ($True) oppure no ($False)\n-Anonymous : rende anonimi gli operatori che rispondono ($True) oppure visibili ($False)\n-BusinessHoursID : indica gli orari di apertura del IVR (in questa caso verrà riprodotta la “Default Action”)\n-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)\n-NonBusinessHoursAction : azione da eseguire in orari di chiusura. L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction\n-HolidayAction : azione da eseguire in giornate festive. L’azione deve essere stata precedentemente creata con un comando New-CsRgsCallAction\n$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\nL’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.\nBuon Call Center!!!\nPubblicato in Lync Server 2010 | 2 Commenti »\nNovità nella versione 4.2 di Lync 2010 Client per Ipad\nScritto da Ivan Salvade' il 25 giugno 2012\nIl Lync client per Ipad è recentemente stato aggiornato alla sua versione 4.2 (secondo iTunes) o 1.5 (secondo Microsoft).\nLa nuova versione è gratuitamente scaricabile da iTunes dal 22 giugno 2012.\nUn’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.\nPer poter sfruttare questa novità, è necessario installare sui server Lync il “Lync Server 2010 Cumulative Update for June 2012″, disponibile in download al seguente link :\nQuando 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.\nDopo 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.\nEd ora… aspettiamoci magari anche l’inserimento della parte video in qualche futura release\nPubblicato in Lync Server 2010 | Nessun commento »\nProblema con il comando Test-CsMcxP2PIM e Lync Server 2010 Mobility Service\nScritto da Ivan Salvade' il 16 aprile 2012\nN.B. : questo articolo è stato aggiornato in data 18 aprile 2012. Gli aggiornamenti sono indicati in rosso in calce all’articolo.\nSono 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 :\nLa guida per l’installazione è al seguente link :\nQuando 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 :\nMemorizzare le credenziali di due utenze in due variabili (per es. $SenderCred e $ReceiverCred) :\n$Cred1=Get-Credential (inserire le credenziali nel popup grafico)\n$Cred2=Get-Credential (inserire le credenziali nel popup grafico)\nOra eseguire il seguente comando :\nTest-CsMcxP2PIM -TargetFQDN nome_FrontEnd_pool_interno -SenderSipAddress “sip:utente1@dominio_SIP” -SenderCredential $Cred1 -ReceiverSipAddress “sip:utente2@dominio_SIP” -ReceiverCredential $Cred2 -verbose\nEcco in Fig. 1 il comando eseguito su un Front-End (sono opportunamente nascosti i nomi di dominio e degli utenti) :\nE’ possibile che il comando restituisca il seguente errore (Fig. 2) :\nCi 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.\nUn’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 :\nQuesto è 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) :\nSe 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) :\nAbbiamo 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) :\nL’altra soluzione è illustrata in Fig. 7 :\nDopo la modifica del binding in IIS, ricordarsi di restartare i servizi IIS (o almeno il Lync Server Internal Web Site).\nEntrambe 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 ) :\nIn Fig. 9 ho indicato l’esito “verbose” del comando :\nSe ancora dovessero sussistere gli errori, ricordate di disabilitare IPv6 sui server Front-End.\nCome 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 :\nPer 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 :\nQuindi, 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.\nSegnalo 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 :\nL’articolo è stato aggiornato da Microsoft proprio ieri!! In calce all’articolo, è visibile una nota importante che dice testualmente :\n“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)”.\nE’ 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.\nQuesto scenario è in fase di test avanzato da parte mia. Vi terrò aggiornati su ulteriori sviluppi.\n“Adoption and Training Kit” di Lync 2010\nScritto da Ivan Salvade' il 23 gennaio 2012\nE’ disponibile sui siti di Microsoft l’”Adoption and Training Kit” di Lync 2010. La Home page della documentazione si trova al seguente link :\nSi 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).\nFanno 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.).\nSono 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.\nInfine 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.\nCosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 4\nScritto da Ivan Salvade' il 15 gennaio 2012\nNella 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.\nNella Parte 2 ho trattato i protocolli H.323 e SIP e la differenza fra traffico di “signaling” e traffico di “media“.\nNella Parte 3 ho illustrato le nozioni fondamentali dei protocolli RTP e RTCP e dei Codecs Audio e Video.\nIn quest’ultima parte descriverò sommariamente il funzionamento dei ”Dial Plan” e della tecnica “Media Bypass” utilizzabile in Lync Server 2010.\nI Dial Plan\nPossiamo 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”.\nCos’è 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).\nSecondo 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).\nQuando 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.\nQuindi, in definitiva, la raccomandazione è dotare tutti gli utenti interni di un numero telefonico in preciso formato E.164, come in questo esempio :\nE’ 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).\nIl 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.\nE’ quindi importante raccogliere il maggior numero di informazioni dagli utenti aziendali sulle loro abitudini di composizione dei numeri : un Dial Plan dovrebbe accomodarle tutte.\nSi 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 :\nlista di tutte le sedi aziendali dove si utilizza la telefonia\nlista dei numeri interni utilizzati in ogni sede\nlista dei prefissi nazionali e numeri telefonici significativi utilizzati in ogni sede aziendale per essere raggiunti dalla rete PSTN\ncapacità dei PBX esistenti di permettere o meno la raggiungibilità diretta da PSTN degli utenti aziendali, tramite il loro numero di interno\npossibilità di utilizzare un unico Dial Plan o necessità di utilizzare multipli Dial Plan\ntipologia di numeri interni da utilizzare (a 2 cifre, a 3 cifre, a 4 cifre ecc.)\nabitudini degli utenti nel comporre gli interni\nabitudini degli utenti nel comporre i numeri nazionali\nabitudini degli utenti nel comporre i numeri internazionali\nabitudini degli utenti nel comporre i numeri di emergenza\nabitudini degli utenti nel comporre i numeri verdi e/o a tariffazione speciale\nUna 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.\nEcco 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) :\nper ottenere la linea esterna, digitare il 9\nse 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\nse 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″\nse 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 “+”\nI 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.\nIl “Media Bypass” di Lync Server 2010\nHo 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.\nLync 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.\nEcco una sintetica rappresentazione grafica del Media Bypass :\nNel 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.\nSe, 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.\nNel 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.\nIn 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 :\nl’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)\nil 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)\nil 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\nBene! 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\nBuon Lync 2010 a tutti !!!\nCosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 3\nScritto da Ivan Salvade' il 4 gennaio 2012\nIn questa terza parte discuterò dei protocolli RTP e RTCP e dei Codecs Audio e Video.\nI protocolli RTP (Real-Time Transport Protocol) e RTCP (RTP Control Protocol)\nIl 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.\nSono stati sviluppati e standardizzati da IETF, inizialmente con la RFC 1889 del 1996, e poi con la RFC 3550 del 2003.\nLe 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.\nRTP 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.\nNon 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.\nRTP si può usare in questi due scenari principali (ma ne esistono altri) :\nConferenze 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).\nConferenze 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”)\nLe porte possono essere scelte a livello applicativo, anche se ne sono state standardizzate due :\nTipicamente, 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.\nRTP/RTCP sono i protocolli di Media utilizzati da Lync Server 2010.\nI “Media Codecs”\nI 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.\nPer 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.\nI 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.\nEsistono molti tipi di codec, che differiscono tra loro per :\nalgoritmo di codifica/compressione\ntipo di segnale che devono campionare\nBit 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)\nFrequenza 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\nlarghezza di banda utilizzata per la trasmissione dei pacchetti contenenti i dati audio (audio payload)\nSi possono suddividere i Media Codecs in due categorie : Audio Codecs e Video Codecs.\nCodificano e comprimono i dati audio in digitale.\nEcco l’elenco dei Codec Audio supportati da Lync Server 2010 :\nRTAudio (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\nG.722 : codec standardizzato ITU-T, campiona a 16 KHz, il Bit Rate del payload audio è 48/56/64 Kbps\nG.711 : codec standardizzato ITU-T, campiona a 8 KHz e 16 KHz (G.711.1), il Bit Rate del payload audio è 64 Kbps\nSiren : codec di produzione Polycom, campiona a 16 KHz, il Bit Rate del payload audio è 16 Kbps circa\nLync 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).\nPer comunicazioni peer-to-peer tra endpoint Lync Server 2010, è sicuramente usato RTAudio.\nQuando 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.\nPer 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.\nIn 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.\nCodificano e comprimono i dati video in digitale.\nLync Server 2010 utilizza un unico codec video : RTVideo\nRTVideo è 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 :\nBit Rate compreso tra 96 Kbps e 135 Mbps\nRisoluzione video compresa tra (176 X 144) e (2048 X 1536)\nNella Parte 4 dell’articolo tratterò dei Dial Plan (o Dialing Plan) e della tecnica “Media Bypass” di Lync Server 2010.\nPubblicato in Lync Server 2010 | 1 Commento »\nCosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 2\nScritto da Ivan Salvade' il 28 dicembre 2011\nIn questa seconda parte tratterò in maniera concettuale di SIP, H.323 e della differenza fra traffico di “Signaling” e traffico di “Media”.\n“Signaling” e “Media”\nNell’ambito dell’industria telefonica, il termine “Signaling” (”Segnalazione” in italiano) viene utilizzato per indicare il processo di realizzazione di una chiamata telefonica.\nPiù 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.\nNella 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).\nUtilizzare 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.\nIl 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.\nAnche 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.\nNella 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ù…\nLo 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).\nH.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).\nI protocolli della suite H.323 gestiscono la telecomunicazione in tutte le sue fasi, e cioè :\nregistrazione dei dispositivi comunicanti\ncodifica e trasferimento dati in tempo reale\nfunzionalità avanzate e sicurezza\nEcco un sommario dei protocolli più importanti della suite H.323, suddivisi per categoria :\nRegistrazione, signaling e controllo\nH.225 Call signaling e pacchettizzazione del traffico di media\nRAS Registration, Admission, Status\nH.245 Controllo delle comunicazioni multimediali\nG.711 (chiamato anche PCM - Pulse Code Modulation)\nI 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.\nI precedenti sono dei Codec Video Standard, ratificati da ITU-T. Hanno il compito di campionare, codificare in digitale e comprimere i contenuti video.\nSuite 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.\nLa 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\nTrasporto del traffico di Media\nSicurezza delle trasmissioni\nH.235 Garantisce criptazione del traffico tra terminali multimediali\nServizi avanzati o supplementari\nH.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\nOgnuno dei precedenti protocolli permette l’utilizzo di un certo servizio supplementare durante le telecomunicazioni. Degli esempi possono essere :\nparcheggio e successivo recupero della chiamata\n… tanti altri, e in continua evoluzione…\nE’ 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.\nE’ un protocollo Application-Layer (al pari, per esempio, di HTTP, SMTP, SNMP, DNS ecc. ecc.), proposto da IETF come alternativa a H.323.\nHa 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.\nA 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.\nLe funzionalità base di SIP sono le seguenti :\nlocalizzazione degli endpoint (i terminali della comunicazione)\nsegnalazione della volontà di comunicare\nnegoziazione dei parametri della sessione\nterminazione della sessione\nOgni 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 :\nsip: se la trasmissione del URI avviene in chiaro\nsips: se la trasmissione del URI avviene in maniera sicura (criptata con TLS)\nLa sintassi generale di un SIP URI è la seguente :\nEcco la spiegazione sommaria dei vari termini della sintassi :\nuser : l’identificatore di una particolare risorsa da contattare. Nelle comunicazioni VoIP aziendali, questo è molto frequentemente il nome diretto dell’utente da chiamare\npassword : la password dell’utente. Sebbene concessa dalla sintassi, per ragioni di sicurezza è consigliato non usare questo parametro, soprattutto se l’URI è utilizzato in chiaro\n@host : l’host che fornisce la risorsa SIP. Può contenere un FQDN o un indirizzo IPv4/IPv6. La raccomandazione è di utilizzare un FQDN\nport : 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\nuri-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\nEcco alcuni esempi di SIP URI, tratti dalla RFC 3261 :\nsip:alice@atlanta.com (quello più comunemente associato ad ogni utente aziendale che usa Lync Server 2010)\nLe funzionalità base di SIP menzionate poco fa, vengono garantite utilizzando diversi componenti :\nUA (User Agent) : un endpoint di comunicazione. Può fungere da client (UAC) o server (UAS) o entrambi (per esempio un telefono SIP)\nUAC (User Agent Client) : entità logica che spedisce richieste SIP e riceve risposte a queste richieste\nUAS (User Agent Server) : entità logica che spedisce risposte alle richieste SIP\nServer 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 :\nProxy 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\nRegistrar 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\nLocation 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\nEcco 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) :\nAlice clicca sul nome di Bob nella propria rubrica degli indirizzi\nL’applicazione SIP di alice spedisce un messaggio INVITE al SIP URI di Bob. Il messaggio INVITE, come minimo, contiene :\nl’indirizzo IP (o nome FQDN) a cui Alice desidera ricevere risposta (pc1.source.com)\nun numero di transazione\nil Display Name e il SIP URI di Bob (Bob <sip:bob@dest.com>)\nil Display Name e il SIP URI di Alice (Alice <sip:alice@source.com>)\nun Tag usato a scopo di identificazione dall’applicazione o telefono SIP\nun GUID per la chiamata, ottenuto combinando una stringa casuale con l’indirizzo IP o FQDN dell’host chiamante\nun SIP URI ulteriore che rappresenta una via diretta per raggiungere Alice (<sip:alice@pc1.source.com>)\nDato 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\nIl 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\nIl Proxy Server di Alice localizza il Proxy Server di Bob (tramite DNS) nel dominio dest.com\nUna 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\nIl Proxy dest.com risponde al Proxy source.com con un messaggio 100 TRYING\nIl Proxy dest.com consulta il suo Location Service che contiene il corrente/i indirizzo/i IP di Bob\nIl Proxy dest.com inserisce nel messaggio INVITE il proprio indirizzo, e lo inoltra al/i telefono/i SIP di Bob\nIl 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)\nQuando 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\nBob risponde alla chiamata : il suo telefono SIP spedisce un messaggio 200 OK ad Alice, sempre tramite i due proxy\nL’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)\nBob e Alice si accordano sul tipo di sessione che vogliono stabilire\nLo scambio di dati nella sessione viene effettuato con gli opportuni protocolli di Media (es. RTP/RTCP)\nL’utente che decide di terminare la chiamata invia direttamente all’altro un messaggio BYE\nL’altro risponde con un messaggio conclusivo 200 OK\nSIP è stato adottato come protocollo di signaling da Lync Server 2010.\nNella Parte 3 dell’articolo discuterò dei protocolli RTP e RTCP e dei Codecs Audio e Video.\nCosa bisogna conoscere per gestire al meglio Lync Server 2010 : Parte 1\nScritto da Ivan Salvade' il 20 dicembre 2011\nRitengo che un sistemista/progettista di infrastrutture Lync Server 2010 debba avere conoscenze almeno concettuali di alcune tecnologie di telecomunicazione (ed argomenti annessi).\nAltre conoscenze richieste possono essere :\nTCP/IP e DNS\nMi interessa, in questa serie di articoli, illustrare i concetti base di argomenti riguardanti le telecomunicazioni, e in particolare :\nTDM (Time Division Multiplexing) e VoIP\nMedia Gateways e PBX (Private Branch eXchange)\nDifferenze tra “Signaling” e “Media”\nSIP (Session Initiation Protocol) e H.323\nRTP (Real-Time Transport Protocol) e RTCP (RTP Control Protocol)\nTecnica “Media Bypass” di Lync Server 2010\nQueste brevi informazioni possono essere di aiuto a chi si affaccia per le prime volte alla gestione di un sistema di Unified Communications.\nIn questa prima parte dell’articolo, comincio a trattare i concetti di TDM, VoIP, PBX, Media Gateway.\nTecnica conosciuta in Italia come “Multiplazione a Divisione di Tempo”.\nMultiplexing (o “multiplazione”) significa ricevere diversi segnali in ingresso, e modularli ottenendo un unico segnale in uscita, trasmettibile su un unico collegamento fisico.\nVolendo 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.\nOvviamente all’altro capo del mezzo di trasmissione dovrà essere eseguita l’operazione inversa (cioè il “Demultiplexing”) per ricostruire i segnali informativi originali.\nSono evidenti i vantaggi di questa tecnica :\npossibilità di occupare tutta la banda messa a disposizione dal mezzo di trasmissione\nmassimizzare l’utilizzo del mezzo trasmissivo (spesso qualche sorgente non è costantemente attiva)\nsemplificare la gestione dei collegamenti a lunga distanza (ne devo creare in minor numero)\nIl 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.\nPerchè 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.\nTecnologia che rende possibile effettuare comunicazioni telefoniche utilizzando una qualunque rete IP (per esempio Internet).\nLa 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.\nLe 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.\nCon la “commutazione di circuito” la banda utilizzata da ogni telefonata è fissa e riservata.\nCon 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.\nEcco alcuni vantaggi del VoIP :\nMinor costo delle chiamate, soprattutto quelle a lunga distanza\nMinore spesa in infrastrutture (è sufficiente una rete IP !!)\nFuture nuove opzioni non richiederanno sostituzione di hardware\nChiamate locali e a lunga distanza sono praticamente identiche\nMaggiore efficienza dei Fax\nMaggiore sicurezza delle chiamate (anche se non criptate)\nVoIP funziona appoggiandosi a diversi protocolli. Ci sono due categorie fondamentali di protocolli :\nProtocolli per il trasporto di segnali audio e video\nProtocolli per la gestione del traffico di “signaling”\nNella prima categoria rientra il protocollo RTP (Real-Time Transport Protocol), usato nella stragrande maggioranza delle implementazioni VoIP.\nNella 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 :\nSCCP (Skinny Call Control Protocol, o semplicemente “Skinny”) della CISCO\nMGCP - Media Gateway Control Protocol (ETSI)\nMEGACO (chiamato anche H.248) (ETSI)\nMiNET della Mitel\nXMPP - eXtensible Messaging and Presence Protocol (conosciuto anche come “Jabber”) (IETF)\nSistemi PBX (Private Branch eXchange)\nUn 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.\nIl centralino PBX svolge tre funzioni fondamentali :\nCreare la connessione (o il circuito) tra gli apparati telefonici che si stanno chiamando, mappando i numeri chiamanti e chiamati ai corrispondenti telefoni fisici\nMantenere la connessione per il tempo voluto dagli utenti, tramite apposito traffico di “Signaling”\nFornire informazioni sulla durata della conversazione\nOltre alle funzioni fondamentali, ogni PBX può offrire ulteriori servizi, in base al Vendor e al modello acquistato. Alcuni esempi :\nRisposta automatica in caso di assenza\nBlocco delle chiamate in arrivo\nBlocco degli apparecchi telefonici con codice di sblocco\nSelezione diretta di un numero con un tasto\nComposizione diretta degli interni (DID, “Direct Inward Dialing”)\nRisposta a chiamata in arrivo su un altro interno\nAl 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.\nPer poter utilizzare un sistema TDM PBX con Lync Server 2010, è necessario implementare un Gateway IP opportunamente supportato (per es. quelli di AudioCodes e Dialogic).\nI 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.\nEssi, 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.\nUn’ultima distinzione che si può fare, è quella tra sistemi TDM PBX Analogici o Digitali.\nUn 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.\nUn 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).\nUn 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.\nEsistono 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).\nUn IP-PBX Tradizionale solitamente ha le seguenti caratteristiche :\nDispone 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)\nDispone di una o più interfacce di telefonia per collegarsi a rete PSTN\nPoichè è 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\nUn IP-PBX Ibrido solitamente ha le seguenti caratteristiche :\nDispone di una o più interfacce analogico/digitale per il collegamento di telefoni analogici e digitali\nPoichè è 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\nMedia Gateway (termine generico)\nIl “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.\nNe 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 :\nVoice IP Gateway\nVoIP to PSTN Gateway\nUn’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.\nI 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) :\nCodificare il traffico di “signaling” e il traffico di “media” tra il Mediation Server e la rete PSTN\nFunzionare come punto di terminazione per i SIP Trunk\nFunzionare come apparato intermedio tra Lync 2010 e qualunque TDM-PBX o IP-PBX non supportato da Lync\nConnettere telefoni analogici e apparecchi Fax all’infrastruttura Lync\nDetto questo, ecco alcune generali regole per decidere l’implementazione o meno di un Media gateway in un’infrastruttura Lync :\nE’ necessario un Media Gateway per connettere Lync ad un TDM-PBX (che non supporta IP)\nE’ 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)\nSe 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\nSe 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\nPer un elenco di Gateway e apparati PBX compatibili con Lync Server 2010, si può consultare questo link :\nNella Parte 2 dell’articolo discuterò dei protocolli SIP e H.323, e delle differenze fra traffico di “signaling” e traffico di “media”.\nElementi fondamentali di progettazione di un’infrastruttura Lync Server 2010\nScritto da Ivan Salvade' il 15 dicembre 2011\nLync 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.\nLo scopo di questo articolo è indicarvi quali sono i componenti fondamentali di un’infrastruttura Lync, a cosa servono, e come devono essere implementati e utilizzati.\nComincio col dire che, per progettare e poi gestire un’infrastruttura Lync, sarebbe molto utile avere :\nConoscenze di Active Directory, DNS e servizi di infrastruttura\nEsperienza sulla precedente piattaforma OCS 2007 R2\nConoscenza di tecnologie correlate, come per esempio Exchange Unified Messaging\nConoscenze concettuali di tecnologie di telecomunicazione, tra cui :\nTDM (Time Division Multiplexing) e integrazione con VoIP\nGateways e PBX (Private Branch eXchange)\nNormalizzazione dei Dial Plan\nLa 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.\nEcco i concetti fondamentali di progettazione da tenere presente.\nDisponibilità di Lync Server 2010\nE’ 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.\nDifferenze tra Lync Server 2010 “Standard Edition” e “Enterprise Edition”\nLa 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à.\nLa 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!\nRuoli di Lync obbligatori\nIl “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”.\nRuoli di Lync opzionali\nEdge 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.\nRuolo “Front-End Server” (obbligatorio)\nE’ 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 :\ngestire le registrazioni di presenza e di telefonia degli utenti (utilizzando il componente denominato “Registrar”)\nfornire servizi di conferenza audio/video, conferenza Web, conferenza dial-in, condivisione applicazioni, chat\ngestire il CMS (Central Management Store), che comunica i dati di configurazione a tutti i server Lync dell’infrastruttura\nfornire aggiornamenti ai client Lync 2010\nRuolo “Back-end Server” (obbligatorio)\nE’ 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 :\npresenza degli utenti\nliste dei contatti\ndati inerenti le conferenze e la loro schedulazione\nRuolo “Audio/Video Conferencing Server” (obbligatorio)\nE’ 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.\nLe 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.\nQuesto 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.\nRuolo “Edge Server” (opzionale)\nDovrebbe 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.\nPiù nel dettaglio, ecco di cosa si occupa il ruolo Edge :\nfornire servizi di accesso agli utenti esterni per quanto riguarda il “signaling SIP”, la presenza e la chat (servizio “Access Edge”)\nfornire servizi di conferenza web (servizio “Web Conferencing Edge”)\nfornire servizi audio/video, di condivisione desktop e applicazioni e di trasferimento files (servizio “A/V Edge”)\nSi può utilizzare un pool di server Edge per ottenere ridonandaza, opportunamente integrati con soluzioni di DNS Load balancing o Hardware Load Balancing.\nRuolo “Mediation Server” (opzionale)\nPuò 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.\nIl 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.\nPuò 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.\nRuolo “Director” (opzionale)\nHa 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.\nIl 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.\nRuolo “Monitoring Server” (opzionale)\nHa 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.\nIl 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.\nRuolo “Archiving Server” (opzionale)\nHa il compito di archiviare i messaggi di chat e le conferenze, specificando per quali utenti è abilitata l’archiviazione.\nSi può abilitare l’archiviazione per comunicazioni tra utenti interni, o tra interni ed esterni.\nAlcuni tipi di contenuto non sono archiviabili :\ntrasferimenti di files peer-to-peer\ncondivisione di applicazioni\nannotazioni e sondaggi nelle conferenze\nPer la collocazione dell’Archiving Server, valgono le stesse regole del Monitoring Server.\nCosa sono i “Siti” in Lync Server 2010 e come bisogna progettarli\nGeneralmente, 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).\nSegnalo 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.\nLa prima cosa da definire progettando Lync, è il posizionamento del o dei “Central Site” e degli eventuali “Branch Sites”.\nI “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.\nI “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.\nIn un Branch Site si può prevedere la presenza, a scelta, dei seguenti dispositivi :\nUn “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\nUn “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\nUn semplice PSTN Gateway e, opzionalmente, un Mediation Server\nPer 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.\nPer 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.\nImplementare Lync Server 2010 : Parte 7\nScritto da Ivan Salvade' il 6 novembre 2011\nIn questa settima parte dell’articolo vedremo come configurare l’accesso degli utenti esterni alla nostra infrastruttura Lync.\nEcco i link alle precedenti parti pubblicate :\nParte 1 (Introduzione) : http://ivansalvade.it/2011/09/12/implementare-lync-server-2010-parte-1/\nParte 2 (Preparazione di Active Directory) : http://ivansalvade.it/2011/09/16/implementare-lync-server-2010-parte-2/\nParte 3 (Creazione della topologia col Topology Builder) : http://ivansalvade.it/2011/09/21/implementare-lync-server-2010-parte-3/\nParte 4 (Pubblicazione della topologia di Lync) : http://ivansalvade.it/2011/09/25/implementare-lync-server-2010-parte-4/\nParte 5 (Deploy del server Front-End) : http://ivansalvade.it/2011/09/29/implementare-lync-server-2010-parte-5/\nParte 6 (Regolazione dei record DNS) : http://ivansalvade.it/2011/10/15/implementare-lync-server-2010-parte-6/\nCi sono diverse tipologie di utenze esterne che possono collegarsi alla nostra infrastruttura Lync 2010 :\nUtenti Remoti : utenti con utenza di dominio interna, che si trovano in siti esterni. Hanno accesso a tutte le features di Lync\nUtenti Federati : utenti di un’azienda partner esterna. Possono accedere alla maggior parte delle features di Lync\nUtenti 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\nIl 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 :\nAccess Edge Service : invia e riceve comunicazioni su protocollo SIP\nWeb Conferencing Edge Service : connette gli utenti esterni a conferenze e meeting ospitati sui Lync Server interni\nA/V Edge Service : rende disponibile agli utenti esterni la condivisione di video, audio, applicazioni, desktop e il trasferimento di files\nI passi generali per l’implementazione dell’accesso esterno ai servizi Lync sono i seguenti :\nRiconfigurare la topologia Lync ad includere un server Edge (o un pool di server Edge) e i suoi relativi componenti (si usa il Topology Builder)\nEsportare la nuova configurazione verso il server Edge\nInstallare il server Edge\nRichiedere ed assegnare gli opportuni certificati\nFar partire i servizi Lync del server Edge\nCreare i necessari record DNS\nTestare l’accesso dall’esterno\nN.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” :\nEcco alcune variabili che possono modificare le fasi di implementazione dell’accesso esterno :\nPresenza di un singolo server Front-End o di un Pool\nUtilizzo di un singolo server Edge o di un Pool\nUtilizzo o meno di DNS Load Balancing\nUtilizzo o meno di Bilanciatori Hardware\nQuantità di servizi da rendere disponibile all’esterno\nUtilizzo di uno o più domini SIP\nUtilizzo di dominio SIP uguale al dominio Active Directory, oppure diverso\nUtilizzo o meno di Reverse Proxy\nIn caso di utilizzo di Reverse Proxy, se singolo o in bilanciamento di carico\nUtilizzo o meno della configurazione automatica dei client esterni\nConformazione della DMZ aziendale\nUtilizzo o meno di NAT tra le interfacce esterne di Edge e Reverse Proxy e Internet\nPresenza o meno di un Director Server interno\nRestrizioni sulle porte apribili nei firewall aziendali\nCome potete vedere, ogni modifica di una singola variabile può portare a differenze di configurazione; quindi questo articolo deve essere inteso come PURAMENTE DIMOSTRATIVO.\nEcco lo scenario della mia dimostrazione :\nMIA-DC1 indirizzo IP interno 10.0.10.10 è DNS interno, Domain Controller e Certification Authority\nMIA-LS1 indirizzo IP interno 10.0.10.12 è il server Lync Front-End standalone, membro di dominio\nMIA-ED1 sarà il server Lync con il ruolo Edge, in workgroup. E’ dotato di vari indirizzi IP :\n10.0.10.14 indirizzo IP interno\n172.16.10.100 indirizzo IP esterno; sarà utilizzato dal servizio Access Edge\n172.16.10.101 indirizzo IP esterno; sarà utilizzato dal servizio Web Conferencing Edge\n172.16.10.102 indirizzo IP esterno; sarà utilizzato dal servizio A/V Edge\nMIA-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 :\ninterfaccia interna 10.0.10.1\ninterfaccia esterna 172.16.10.1\nINT-CL4 indirizzo IP 172.16.10.20 è un client che simula di stare su Internet\nil 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\nho scelto di non utilizzare NAT tra le interfacce esterne del server Edge e Internet\nnon implementerò il Reverse Proxy\nnon implementerò bilanciamenti di carico (nè DNS, nè hardware)\nDMZ e Internet sono la stessa rete : 172.16.0.0\nCominciamo 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) :\nSi indica di salvare la nuova topologa in un file di appoggio (Fig. 2) :\nSi procede alla definizione di un nuovo Edge Pool (Figg. 3 e 4) :\nSi inserisce il nome del pool, specificando che useremo un singolo computer nel pool (MIA-ED1.fabrikam.com) (Fig. 5) :\nNella 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) :\nNella definizione dei FQDN esterni, utilizzo le seguenti configurazioni (Fig. 7) :\nSIP Access : “sip.fabrikam.com”, su porta 443\nWeb Conferencing : “webconf .fabrikam.com”, su porta 443\nAudio/Video : “avconf.fabrikam.com”, su porta 443\nDichiaro l’indirizzo IP interno del server Edge (10.0.10.14) (Fig. 8 ) :\nDichiaro gli indirizzi IP esterni del server Edge, come da prospetto seguente (Fig 9) :\nSIP Access : 172.16.10.100\nWeb Conferencing : 172.16.10.101\nA/V Conferencing : 172.16.10.102\nCome “Next hop pool”, indico il Front-End Server (Figg. 10 e 11) :\nEcco il riassunto della nuova configurazione (Fig. 12) :\nModifico le proprietà del sito per attivare la federazione (se necessario) (Figg. 13 e 14) :\nOra pubblico la nuova topologia (Figg. 15 e 16) :\nCon 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 :\nExport-CSConfiguration -Filename c:\_Config.zip\nOra, 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) :\nSi lancia il setup di Lync dal DVD (Figg. 20 e 21) :\nSu 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) :\nOra eseguo lo Step 2 che installa i componenti Edge (Figg. 25 e 26) :\nSi lancia lo Step 3 che assegna i corretti certificati (Fig. 27) :\nPrima si richiede alla CA interna il certificato per l’interfaccia interna del ruolo Edge (Fig. 28) :\nAvendo una CA interna, spedisco direttamente la richiesta (Fig. 29) :\nMIA-ED1 è una macchina di workgroup, quindi non può rilevare la CA da Active Directory. Allora la specifichiamo noi (Fig. 30) :\nSe la password di Amministratore locale di MIA-ED1 è uguale alla password di Amministratore di dominio, non serve specificare credenziali alternative; altrimenti sì (Fig. 31) :\nAssegnare un nome amichevole al certificato interno (Fig. 32) :\nCompilare le informazioni da inserire nella richiesta (Figg. 33 e 34) :\nIl certificato viene rilasciato; lasciare impostato il flag di Fig. 35, per accedere alla procedura di assegnazione (Fig. 36) :\nVerificare che il certificato venga correttamente assegnato (Figg. 37 e 38) :\nOra si richiede alla CA interna il certificato per le interfacce esterne del ruolo Edge (Fig. 39) :\nLa 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) :\nEcco l’esito finale (Fig. 43) :\nNello Step 4 si fanno partire i servizi Edge (Fig. 44). In Fig. 45 un estratto della console dei Servizi :\nOra 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) :\nTre record di tipo A devono essere creati, che risolvono i nomi Sip, Webconf e AVconf ai giusti IP esterni (Fig. 47) :\nInoltre bisogna creare i seguenti record SRV (Figg. 48, 49, 50, 51) :\n_sipexternaltls che utilizzi protocollo TCP su porta 443 e il nome “sip.fabrikam.com”\n_sipfederationtls che utilizzi protocollo TCP su porta 5061 e il nome “sip.fabrikam.com”\n_sip che utilizzi protocollo TLS su porta 443 e il nome “sip.fabrikam.com”\nN.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.\nSi attiva ora la possibiltà di accesso agli utenti esterni dal Lync Server Control Panel (Figg. 52 e 53) :\nCome 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 :\nOra il tentativo di autoconfigurazione e connessione di un client esterno deve dare esito positivo.\nQuesto era l’ultimo articolo della serie…\n… e allora buon Lync a tutti!!! :-)\nPubblicato in Lync Server 2010 | 8 Commenti »