Ivan Salvade’

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

  • Ivan

    248418_467427256623661_1655875885_n.jpg
  • Abbonati

  •  

    settembre 2017
    L M M G V S D
    « gen    
     123
    45678910
    11121314151617
    18192021222324
    252627282930  
  • Tag Cloud

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

Scritto da Ivan Salvade' il 4 gennaio 2012

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

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

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

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

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

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

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

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

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

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

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

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

  • 5004 RTP
  • 5005 RTCP

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

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

I “Media Codecs”

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

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

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

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

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

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

Codecs Audio

Codificano e comprimono i dati audio in digitale.

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

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

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

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

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

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

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

Codecs Video

Codificano e comprimono i dati video in digitale.

Lync Server 2010 utilizza un unico codec video : RTVideo

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

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

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

  • Share/Bookmark

Pubblicato in Lync Server 2010 | 1 Commento »

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

Scritto da Ivan Salvade' il 28 dicembre 2011

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

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

“Signaling” e “Media”

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

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

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

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

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

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

H.323

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

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

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

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

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

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

Registrazione, signaling e controllo

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

Gestione Audio

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

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

Gestione Video

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

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

Data Conferencing

  • T.120  

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

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

Trasporto del traffico di Media

  • RTP
  • RTCP

Sicurezza delle trasmissioni

  • H.235         Garantisce criptazione del traffico tra terminali multimediali

Servizi avanzati o supplementari

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

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

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

SIP (Session Initiation Protocol)

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

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

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

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

Le funzionalità base di SIP sono le seguenti :

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

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

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

La sintassi generale di un SIP URI è la seguente :

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

Ecco la spiegazione sommaria dei vari termini della sintassi :

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

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

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

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

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

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

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

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

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

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

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

Scritto da Ivan Salvade' il 20 dicembre 2011

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

Altre conoscenze richieste possono essere :

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

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

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

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

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

TDM (Time Division Multiplexing)

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

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

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

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

Sono evidenti i vantaggi di questa tecnica :

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

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

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

VoIP (Voice over IP)

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

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

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

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

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

Ecco alcuni vantaggi del VoIP :

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

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

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

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

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

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

Sistemi PBX (Private Branch eXchange)

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

Il centralino PBX svolge tre funzioni fondamentali :

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

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

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

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

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

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

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

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

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

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

Sistemi IP-PBX

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

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

Un IP-PBX Tradizionale solitamente ha le seguenti caratteristiche :

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

Un IP-PBX Ibrido solitamente ha le seguenti caratteristiche :

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

Media Gateway (termine generico)

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

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

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

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

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

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

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

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

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

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

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

  • Share/Bookmark

Pubblicato in Lync Server 2010 | Nessun commento »

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