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

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 / Save :

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *