Blog

Sabato 04 settembre 2021 è una data che rimarrà impressa nella memoria di tutto il team di VoipVoice, perché ha potuto festeggiare un traguardo così importante, come i primi 15 anni di attività, in una delle location storiche di Firenze d’eccellenza: il Salone dei Cinquecento di Palazzo Vecchio.

Non solo, più di 200 sono stati gli ospiti di questo importante evento e ve li vogliamo presentare.

Ecco i volti che rappresentano la rete VoipVoice e che hanno reso unica e indimenticabile la convention “Fatti Non Foste a Viver Come Bruti – I Nostri Primi 15 Anni”.

Le specifiche del protocollo SIP prevedono 4 metodi per implementare le segnalazioni dei toni DTMF tra UAS (User Agent Server) e UAC (User Agenti Client). La gestione di questi ultimi, in ambito VoIP SIP, è disciplinata dalla nuova RFC 4733 del 2006 che ha reso obsoleta la precedente RFC 2833 del 2000.

In questo articolo cercherò di spiegarvi cosa sono i toni DTMF e come la loro implementazione si sia modificata nel corso del tempo. Vedremo insieme quali siano le possibili modalità di trasporto nell’ambito del protocollo VoIP SIP. Cercherò infine di fornirvi qualche utile consiglio per risolvere le problematiche più comuni legate al mancato o errato riconoscimento dei toni DTMF.

Cosa sono i toni DTMF ?

DMTF è acronimo di Dual Tone Multi Frequency. Si tratta di un sistema di codifica usato in telefonia per trasmettere numeri sotto forma di segnali in banda audio.

Lo scopo di questo sistema di codifica è molteplice. Nell’ambito della telefonia analogica lo scopo primario è quello di procedere ad una rapida composizione del numero di telefono, superando le limitazione del precedente metodo di composizione ad impulsi.

Le altre funzionalità chiave, legate a questo metodo, riguardano anche l’interazione con i risponditori vocali interattivi (IVR), l’invio di comandi per il telecontrollo, i pagamenti elettronici automatizzati e la generale interazione tra telefono e telefono e computer. Prima dell’avvento della selezione DTMF, la composizione del numero di telefono avveniva con la selezione ad impulsi (decadica).

Il telefono a disco effettuava una serie di micro interruzioni di linea, corrispondenti ad ogni singola cifra appartenente al numero telefonico da inviare. Alla fine degli anni ’50 i laboratori Bell introdussero la selezione DTMF che fu impiegata a partire dagli anni ’60. Nel corso dei decenni successivi il telefono a tastiera prenderà gradualmente il posto di quello a disco. La selezione ad impulsi (DC) verrà gradualmente abbandonata e sostituita con quella DTMF (MF). In Italia questa transizione è avvenuta tra la fine degli anni ’80 e l’inizio degli anni ’90.

La tastiera e i toni DTMF

La tastiera telefonica odierna è frutto di una serie di scelte operate nel passato quando le tastiere delle macchine calcolatrici, corrispondente a quella degli odierni PC, non era ancora ampiamente diffusa tra il grande pubblico. Questa scelta ha fatto in modo che oggi la tastiera telefonica differisca, per formato, dal tastierino numerico impiegato sui comuni personal computer.

La tastiera DTMF, nella sua implementazione completa, è costituita da una matrice 4×4 che comprende complessivamente le cifre da 0 a 9, i simboli * e # e le prime 4 lettere dell’alfabeto. queste ultime molto utilizzate nell’ambito di applicazioni militari.

Ogni riga rappresenta una frequenza bassa, mentre ogni colonna rappresenta una frequenza alta. Alla pressione di un singolo tasto viene riprodotto un suono che è il risultato della somma contemporanea di due precise frequenze. Per questa ragione si parla di “multifrequenza con doppio tono” (Dual Tone Multi Frequency).

In ambito VoIP SIP i codici evento DTMF sono descritti dalla RFC 4733, nella sezione 3.2. che elenca gli eventi DTMF:

• Eventi 0-9 –> Codici 0-9
• Evento * –>  Codice 10
• Evento # –> Codice 11
• Evento A-D –> Codici 12 – 15

I Toni DTMF oggi, nell’ambito del Protocollo VoIP SIP

Il protocollo SIP e le specifica RFC 4733 prevedono 3 standard per l’invio dei toni DTMF nell’ambito di una chiamata VoIP. Questi metodi sono rispettivamente chiamati: RFC2833, Inband, SIP INFO. I primi due standard prevedono l’invio dei toni nell’ambito del flusso RTP di una chiamata; il terzo metodo prevede l’invio dei toni direttamente all’interno del flusso SIP.

Per chiarire il concetto, nell’immagine sotto stante sono rappresentati i tre “flussi di dati” che in genere compongono una chiamata con il protocollo VoIP SIP.

Il principale strumento con il quale eseguire l’analisi del protocollo SIP per evidenziare eventuali problematiche nella trasmissione dei toni DTMF è costituito dall’analizzatore di Protocolli Wireshark.

1) La modalità DTMF RTP Out of Band (RFC2833)

La RFC2833, oggi sostituita dalle RFC4733, introduceva una modalità di invio toni come messaggi testuali, all’interno del flusso RTP. I codici corrispondenti ai toni DTMF vengono trasmessi all’interno del flusso RTP sotto forma di messaggi di tipo “telephone-event“. La possibilità di trasmettere i DTMF via RTP deve essere preventivamente prevista nell’offerta SDP associata in genere all’INVITE e alla successiva risposta di 200 OK.

E’ curioso notare come, nonostante La RFC2833 sia ormai obsoleta e sostituita dalla RFC 4733, la maggior parte dei device VoIP SIP continua, per tradizione, ad indicare con il termine di RFC2833 la trasmissione dei toni RTP al di fuori della banda audio nell’ambito del protocollo VoIP SIP.

All’interno degli attributi audio SDP relativi ai codec, sono presenti anche le specifiche di utilizzo dei toni DTMF:

• rtpmap:101 telephone-event/8000: questa stringa indica il fatto che i toni dtmf sono trasmessi all’interno del flusso RTP come eventi con payload 101
•  fmtp:101 0-15: indica che saranno disponibili i codici DMTF da 0 a 15 ossia i numeri da 0 a 9, i simboli * e #, oltre alle lettere “a,b,c”. l’eventuale indicazione 0-16 indica anche l’impiego della lettera “d”.

I Toni RFC 2833 nell’analisi Wireshark

I toni DMTF RTP Out fo band sono facilmente identificabili attraverso l’analisi del flusso SIP elaborata da Wireshark. Gli eventi DTMF sono evidenziati con la seguente dicitura: RTP (telephone-event) DTMF [numero] [cifra]. Ad esempio “RTP (telephone-event) DTMF Five 5” indica la trasmissione dell’evento corrispondente alla pressione del tasto “5”.

Cliccando sulla riga corrispondente all’evento, è anche possibile ispezionare il relativo pacchetto RTP

I Vantaggi e gli svantaggi dei Toni DTMF Out of Band RFC 2833

• L’utilizzo dei toni RTP Out of Band, costituisce il metodo preferibile e consigliato per l’invio dei toni DTMF durante una chiamata SIP.
• Si tratta di un metodo molto affidabile e indipendente dalla qualità del flusso audio e dal livello di compressione del codec audio impiegato.
• Il tono viaggia al di fuori della banda audio, come messaggio “testuale”.
• Il tono DTMF viaggia in modalità sincrona
  

2) La modalità DTMF RTP Inband (In Banda)

La modalità Inband costituisce ancora oggi il metodo più utilizzato per la trasmissione dei toni DTMF. I toni, in questo caso vengono trasmessi con gli stessi criteri della telefonia analogica, Essi vengono miscelati con il flusso della chiamata audio, all’interno della banda audio RTP.
in questo caso i toni viaggiano quindi in perfetta sincronia con il messaggio vocale ma la loro comprensibilità è fortemente legata alla qualità complessiva dell’audio trasmesso.

La qualità dell’audio, in particolare, è fortemente dipendente non solo dalla connettività impiegata ma anche dal codec utilizzato. E’ infatti indispensabile utilizzare un codec a bassa compressione come il G711. Il consiglio di VoipVoice è quello di impiegare la modalità Inband escusivamente con i codec G711A e G711U.

I Toni Inband nell’analisi Wireshark

I toni DTMF trasmessi con la codifica Inband sono identificabili (ascoltabili) attraverso la funzionalità “riproduci flussi” di wireshark. Normalmente è possibile identificare i toni visivamente all’interno del grafico in quanto corrispondono a dei picchi audio con una specifica forma d’onda. In caso di dubbi è anche possibile riprodurre il contenuto audio. Per identificare esattamente il tono DTMF digitato è però indispensabile provvedere ad esportare il campione audio per analizzarlo con un tool in grado di indentificare il tono DTMF.

I Vantaggi e gli svantaggi dei Toni Inband

• L’utilizzo dei toni RTP Inband, costituisce un metodo comune per l’invio dei toni DTMF durante una chiamata SIP.
• Si tratta di un metodo abbastanza affidabile ma fortemente dipendente dalla qualità audio della chiamata e dalla compressione del codec audio utilizzato.
• E’ utilizzabile solo con i codec a bassa compressione come il G711A e il G711U.
• Il tono viaggia all’interno della banda audio, miscelato alla conversazione.
• Il tono DTMF viaggia in modalità sincrona
• Si tratta di una metodologia fortemente legata ai metodi della vecchia telefonia analogica.
• In assenza di particolari vincoli, è sempre preferibile utilizzare la modalità RTP Out of Band indicata al punto 1.

3) La modalità DTMF SIP con metodo INFO (SIP INFO)

L’ultimo metodo per l’invio toni DTMF che prendiamo in considerazione, è quello che prevede l’utilizzo del flusso dati SIP. A differenza dei due metodi precedenti che impiegano il flusso dati RTP per inviare le segnalazioni, quest’ultimo impiega il metodo (richiesta) SIP di tipo “INFO”.

La “INFO” è una specifica richiesta prevista nell’ambito del protocollo SIP dalla RFC2976.

I toni, in questo caso sono ovviamente trasmessi al di fuori della banda audio RTP sotto forma di messaggi testuali. Come tali, essi non sono dipendenti dalla qualità audio o dal codec impiegato nella chiamata audio. Anche se questa modalità trova ancora qualche impiego, si tratta però di un metodo sconsigliato in quanto non sincronizzato con la trasmissione audio.

I Toni SIP INFO nell’analisi Wireshark

I toni trasmessi con il metodo SIP di tipo INFO sono facilmente identificabili all’interno della “sequenza del flusso” proposta dall’analizzatore Wireshark. Selezionando il metodo “INFO” è possibile evidenziare, nel “message Body” del metodo INFO, il codice trasmesso.

I Vantaggi e gli svantaggi dei SIP INFO

• L’utilizzo dei toni SIP INFO, costituisce un metodo sconsigliato per l’invio dei toni DTMF durante una chiamata SIP.
• Si tratta di un metodo poco affidabile per l’invio dei toni DTMF in quanto asincrono rispetto all’invio dell’audio.
• E’ utilizzabile con tutti i codec e non dipende dalla qualità audio della chiamata
• Il tono viaggia fuori dalla  banda audio, nel flusso dati SIP.
• In assenza di particolari vincoli, è sempre preferibile utilizzare la modalità RTP Out of Band indicata al punto 1.

Consigli Pratici per l’utilizzo dei DTMF con il VoIP SIP

Dopo aver spiegato cosa sono i toni DTMF e analizzato tutte le metodologie previste dal protocollo VoIP SIP per la loro trasmissione è d’obbligo fornire dei consigli pratici per tutti gli installatori ed appassionati di tecnologia VoIP SIP.

Risulta chiaro che l’esigenza pratica di continuare ad utilizzare i toni DTMF nell’ambito delle trasmissioni telefoniche di tipo digitali è legata a motivi di compatibilità con le pratiche della telefonia analogica. Il metodo oggi più consigliabile per trasmettere oggi i toni DTMF con il VoIP SIP è quello che prevede l’invio dei toni in modalità “out of band” ossia al di fuori della banda audio della chiamata telefonica. Con questo metodo i toni vengono trasmessi e trasportati come messaggi testuali per poi essere riconvertiti nella fase terminale di interfacciamento con le linee PSTN. Questo metodo è generalmente indicato con il termine di “RFC 2833”. Solo pochi altri produttori di device SIP lo identificano con il termine di “RFC 4733”.

Anche la modalità Inband, per l’invio dei Toni DTMF, è ancora largamente impiegata nell’ambito della telefonia VoIP SIP nonostante le limitazioni legate alla qualità audio e all’impiego quasi esclusivo del codec G711. L’utilizzo della modalità DTMF tramite SIP INFO è infine sconsigliata per problemi legati all’asincronia con il flusso audio RTP e ai problemi che ne potrebbero derivare.

A livello pratico è infine sempre sconsigliabile l’impiego simultaneo di uno u più di questi metodi. Nella maggior parte dei casi si produrrebbero errori di riconoscimento del messaggio trasmesso, duplicazione dei toni inviati (es. viene riconosciuto “22” invece di “2”) oppure completo fallimento del messaggio inviato.

In tutti i casi di anomalia, lo strumento principe per analizzare, diagnosticare e risolvere qualunque problema legato alla gestione dei toni DTMF, è costituito dall’analizzatore di protocollo Wireshark.

Se sei un installatore VoipVoice e hai frequentato i corsi di certificazione tecnica della nostra VoIP Academy, saprai già che il SIP è un protocollo di segnalazione e che l’SDP (Session Description Protocol) descrive invece i media di una sessione. Questa separazione consente al SIP di creare sessioni per qualsiasi tipologia di media: voce, video o messaggi in tempo reale. In questo articolo di approfondimento tecnico parleremo di Early Media e Late Media in ambito SIP, scopriremo la differenza con Early Offer e Late Offer e vedremo come procedere in caso di problemi.

Una normale chiamata SIP inizia con successo quando il chiamato la accetta con la risposta finale di 200 OK. A questo punto la negoziazione del codec avviene con successo e il protocollo SIP avvia (mediante SDP) una sessione multimediale con entrambi gli endpoint che dialogano correttamente e conoscono le reciproche capacità. Se questo comportamento rappresenta ciò che avviene normalmente, vi sono dei casi in cui è possibile che lo scambio audio venga anticipato. In altri casi è anche possibile che l’ordine di offerta dei codec e delle capacità tra chiamante e chiamato vengano invertite. Per chi conosce già le basi del protocollo SIP, questi argomenti meritano sicuramente un approfondimento.

Partiamo dall’inizio. In ambito SIP una chiamata e la conversazione audio effettiva si avviano dopo una risposta di 200 OK. Ma questo non ha nulla a che fare con il momento esatto in cui si avvia una sessione multimediale. Vi sono infatti delle circostanze nelle quali l’endpoint remoto può avviare una sessione multimediale prima che avvenga la chiamate vera e propria. E’ ad esempio il caso in cui l’estremità remota riproduce un messaggio vocale per avvisarci in merito al motivo di irraggiungibilità del chiamato oppure riproduce direttamente un messaggio di selezione IVR richiedendo la digitazione di tasti, senza rispondere direttamente alla chiamata.

Cos’è l’Early Media in ambito VoIP SIP ?

Vi sono quindi dei casi in cui il flusso audio transita prima ancora che la chiamata abbia inizio. In ambito VoIP SIP si parla di  “sessione multimediale anticipata”, in termini tecnici chiamato early media. Non si tratta infatti della voce dell’interlocutore con cui si desidera parlare ma di di toni di sistema, annunci preregistrati o qualsiasi altro suono che il chiamato desidera fare ascoltare al chiamante.

E’ un’implementazione in qualche modo simile alla telefonia tradizionale PSTN. Essa si verifica quando si cerca di chiamare un numero cellulare fuori dal raggio di copertura: ” gentile cliente, il numero che ha composto non è disponibile al momento, riprova più tardi.” In questi casi il fornitore di telefonia vi sta semplicemente fornendo una informazione di avviso senza che venga addebitato il costo della chiamata. In termini pratici non si tratta di una risposta alla chiamata ma di un semplice messaggio di avviso/segnalazione.

SIP 180 Ringing

Come riportato nella RFC3261 SIP, la risposta di 180 viene utilizzata per avvisare il chiamante che l’UA (User Agent) che riceve la richiesta di INVITE SIP sta squillando.

La risposta 180, nella maggior parte dei casi, non trasporta l’SDP nel corpo del messaggio (SIP body). Il dispositivo che riceve una risposta 180 (senza SDP) di solito avvia una sessione audio con il “tono di libero” (ringback tone). In questo caso il “tono di libero” non viaggia attraverso la rete ma è semplicemente emulato dal telefono IP o dal centralino telefonico del chiamante.

Vale la pena ricordare che questo comportamento si verifica quando vengono ricevute alcune risposte SIP nelle classi 4XX, 5XX, 6XX.  Il dispositivo, prima di interrompere la chiamata, dovrebbe generare un segnale audio per segnalare che la chiamata è fallita oppure che la linea è occupata.

SIP 183 Session Progress

La risposta 183 (Session Progress) viene utilizzata per trasmettere le informazioni. I campi di intestazione o il body message SDP, in questo caso, possono essere utilizzati per fornire maggiori dettagli sull’avanzamento della chiamata.

Risposta SIP 183 con Early Media nell’SDP

La risposta 183 contenente il body SDP viene solitamente utilizzata in 3 casi:

• Trasmettere il tono di libero attraverso la reta: il dispositivo che esegue la chiamata (UAC) riceverà il tono di libero direttamente dal chiamato (UAS) per indicare che il chiamato è stato avvisato. In questo caso, diversamente da quanto normalmente previsto dal protocollo SIP, il tono di libero viaggia effettivamente attraverso la rete.
• Per riprodurre un tono o un messaggio vocale di messaggio d’errore (es. utente non raggiungibile) e poi riagganciare.
• Per l’implementazione di un risponditore vocale interattivo (IVR): In questo caso toni dtmf di selezione sono attivi contemporaneamente al flusso multimediale.

Questi esempi dovrebbero aver reso più chiaro lo scopo e il funzionamento dell’early media nell’ambito di una risposta SIP con codice 183.

Il funzionamento dell’Early Media (sessione media anticipata) e del Late Media

Negli esempi appena visti sembrerebbe che il funzionamento di “early media” sia piuttosto semplice. Nella pratica, non sempre questo comportamento è lineare. l’UAC (il chiamante) non può decidere se avviare la riproduzione del tono di libero (in risposta al 180 ringing) oppure avviare la riproduzione del messaggio RTP in arrivo con il codice 183. Poiché la segnalazione SIP e l’audio RTP viaggiano su due binari differenti, l’UAC potrebbe riprodurre la risposta 183 con il body message SDP senza prima emulare il tono di libero.

Oltre a questo caso, esiste anche la possibilità che si possano implementare delle risposte SIP 180 contenenti un messaggio SDP ed in grado di avviare una early media, senza la necessità di una risposta 183 dedicata. In buona sostanza si pone il problema del possibile conflitto tra una risposta con codice 180 ed una con codice 183.

Affinché l’early media funzioni è quindi fondamentale verificare che i pacchetti media stiano effettivamente arrivando in un determinato momento.

Le raccomandazioni della RFC3960

Proprio per evitare le possibili problematiche appena evidenziate, la  RFC3960, raccomanda di attenersi ad alcuni comportamenti:

1. A meno che non si riceva una risposta 180 (ringing), non generare mai un tono di libero locale.
2. Se è stato ricevuto un 180 (ringing) ma non ci sono pacchetti multimediali in arrivo , generare il tono di libero locale.
3. Se è stato ricevuto un 180 (ringing) e sono presenti pacchetti multimediali in arrivo, riprodurli senza però generare il tono di libero locale.

Questi criteri non sono però definiti come standard da seguire per ogni dispositivo SIP; essi affermano semplicemente che:

Qualsiasi UA dovrebbe riprodurre i pacchetti multimediali in arrivo (e interrompere la generazione del tono di libero se era in esecuzione)

La RFC3960, prescrive inoltre che, quando la chiamata lascia lo stato di riproduzione multimediale, ricevendo una risposta, la risposta SDP nel 200 OK deve corrispondere alla risposta SDP nel 183/180 precedente. Ciò significa che nel passaggio dal 180/183 al 200 OK non è consentita alcuna modifica nella capacità multimediale (IP, porta e codec) quando la chiamata passa dalla prima sessione “early media”  alla sessione successiva di chiamata vera e proprie (late media).

Bene, questo è tutto, spero che abbia senso per te. Probabilmente, le tracce di Wireshark di una chiamata SIP con early media può aiutarti a capire in modo più chiaro.

Early Offer e Late Offer in ambito SIP

Mi è capitato spesso di vedere confondere i concetti di Early media e Late Media, di cui abbiamo appena parlato, con quelli di Early Offer e Late/Delayed Offer (Offerta Anticipata e Offerta tardiva/ritardata). I due concetti riguardano entrambi la gestione dell’audio ma sono completamente distinti.

E’ noto che in ambito SIP le intestazioni di INVITE descrivono il tipo di sessione che si desidera stabilire, mentre l’SDP descrive i media che si desidera inviare e ricevere. Ad esempio, un telefono IP invia generalmente nell’SDP le voci che indicano i codec supportati : G.711A, G711U, G.729. Il destinatario dell’INVITE analizzerà l’SDP, deciderà quale codec utilizzare ed invierà il proprio SDP nella risposta 200 Ok.

Il chiamato (UAS) può quindi normalmente vedere l’SDP del chiamante (UAC) prima di mostrare il proprio. In altre parole, il chiamante lascia normalmente la scelta del codec al chiamato.

Questo comportamento è chiamato Early Offer (Offerta Anticipata) . In questo caso l’SDP del chiamante è indicato direttamente nell’INVITE.

Tuttavia, secondo l’RFC6337 è anche possibile decidere di non lasciare la scelta del codec unicamente al chiamato. E’ infatti possibile modificare il tipo di offerta in Late Offer (Offerta Tardiva, anche detta “Delayed Offer” ossia Offerta Ritardata).  Con l’offerta tardiva, non è presente alcun SDP nella richiesta INVITE. La responsabilità della scelta del codec cade quindi sul chiamante.

Nell’offerta tardiva, la parte chiamata riceve un INVITE senza SDP. Il comportamento è esattamente il medesimo di una normale sessione SIP: il chiamato invia un 180 (ringing) ma non è a conoscenza di quale codec potrà essere coinvolto nella sessione. Quando risponderà alla chiamata, invierà un 200 Ok con SDP e il chiamante risponde con un ACK. In questo caso, l’ACK conterrà l’SDP che avrebbe dovuto essere inviato con l’INVITE iniziale. Con questa modifica al posizionamento dell’SDP, il chiamante può decidere quale codec verrà utilizzare per la sessione audio.

Un ulteriore metodo, consigliato agli installatori, per obbligare il chiamato ad utilizzare il codec scelto dal chiamante, consiste nel dichiarare un unico codec nell’SDP dell’INVITE.

Riassumendo avremo quindi:

Offerta anticipata = SDP nell’INVITE

Offerta tardiva = SDP nell’ACK

Conclusioni e note per la diagnosi delle anomalie.

I toni di libero, occupato, squillo sono gestiti tramite codici numerici di risposta. Contrariamente alla telefonia tradizionale, il tono non è quindi trasmesso attraverso la rete. Per mantenere la compatibilità e le abitudini acquisite con la telefonia analogica, il protocollo SIP prevede una emulazione locale dei messaggi e dei toni audio. Esistono però delle eccezioni, come la risposta “183 (SDP)” che producono la riproduzione di toni o messaggi audio prima che la chiamata vocale venga avviata tra le due parti. Questi toni/messaggi viaggiano tra i due endpoint con un criterio simile alla telefonia analogica.

Nel caso in cui si presentino anomalie con la riproduzione dei toni, è sempre indispensabile eseguire delle verifiche approfondite. Queste ultime si effettuano catturando un file .pcap della chiamata per poi analizzarlo con il tool Wireshark. Le specifiche RFC del protocollo SIP non prescrivono un obbligo specifico o un ordinamento per l’invio delle risposte 180/183. In alcuni casi è possibile, ad esempio, che i sistemi PBX non siamo in grado di interpretare correttamente alcune situazioni anomale (as es. l’invio di due risposte SIP consecutive: 183 seguito da 183 con SDP).

Per identificare la causa del problema è necessario verificare il tracciato della chiamata SIP. In base al codice rilevato, sarà possibile stabilire se l’incongruenza è causata o meno dal PBX. In caso di messaggi “troncati” a livello di sintassi SIP non è infrequente che la causa dell’anomalia sia dovuta ad un errore di NAT oppure alla presenza di un SIP ALG (o SIP Helper) sull’apparato Router Firewall.

Perché parlare di Routing e NAT con esplicito riferimento al VoIP SIP? Il motivo è molto semplice: uno dei requisiti fondamentali affinché le telecomunicazioni VoIP funzionino correttamente è quello di predisporre e configurare una corretta infrastruttura di rete LAN, opportunamente collegata alla rete Internet. Non è infatti possibile installare correttamente un sistema Voice over IP ignorando gli aspetti legati al routing e al NAT.

Durante tutti i Corsi di formazione e Certificazione della VoIP Academy VoipVoice, il concetto di NAT per il VoIP viene trattato e discusso in maniera approfondita su più livelli. Le criticità relative al NAT in ambito VoIP devono sempre essere pianificate, previste e risolte prima ancora di procedere all’installazione dei telefoni e dei centralini VoIP. Anche la scelta degli apparati di routing da impiegare è fondamentale. Procedere per tentativi, senza far ricorso alle basi teoriche del protocollo SIP e dei meccanismi alla base del NAT, è una pessima idea.

Per rendere ogni installazione VoIP perfetta ed esente da problemi, è necessario che l’installatore conosca i principi di funzionamento del protocollo SIP e le modalità di possibile interazione tra il protocollo SIP e i meccanismi di NAT presenti nell’attraversamento dalle reti private verso quelle pubbliche.

Il NAT VoIP

Il NAT (Network Address Translation) è la tecnologia più comunemente utilizzata da firewall e router per consentire ai dispositivi presenti all’interno di una rete locale LAN, con indirizzi IP “privati”, di condividere un unico indirizzo IP pubblico. Un indirizzo IP privato è un indirizzo che può essere utilizzato solo all’interno della LAN, ma non è direttamente raggiungibile da Internet o al di fuori della rete LAN.

Affinché un dispositivo con un indirizzo IP privato possa comunicare con altri dispositivi su Internet, è necessario che vi sia una traduzione tra indirizzi IP privati ​​e pubblici nel punto in cui la LAN si connette a Internet, cioè all’interno del firewall / router che si connette la LAN a Internet. Tale traduzione è comunemente chiamata NAT (Network Address Translation) e viene effettuata da un apparato router/firewall NAT. Molto spesso il NAT è anche denominato “IP Masquerading”.

Quando si parla genericamente di NAT, in realtà si opera una semplificazione. Sarebbe infatti più corretto parlare sempre di NAPT ossia di traduzione degli Indirizzi IP e delle rispettive porte di comunicazione (Network Address and Ports Translation). Questa considerazione è ancor più indispensabile quando si parla di NAT VoIP.

Come funziona il NAT ?

Il meccanismo di funzionamento del NAT è abbastanza semplice. Quando un dispositivo all’interno della LAN avvia una connessione con un dispositivo su Internet, il dispositivo invierà prima tutto il traffico al router NAT. Il router NAT sostituisce quindi l’indirizzo di origine, che è l’indirizzo privato del dispositivo, con il proprio indirizzo pubblico prima di trasferire il traffico alla sua destinazione su Internet. Quando riceve una risposta, il router NAT cerca nelle sue tabelle di traduzione (NAT mapping Table) per trovare l’indirizzo di origine iniziale del pacchetto. Una volta identificato il dispositivo sulla LAN ha originariamente avviato la connessione, il router inoltra la risposta a quel dispositivo. Si tratta, in sostanza di un processo continuo di traduzione di Indirizzi e porte tra l’ambito della rete “privata” e quella “pubblica”.

Ma cosa accade quando la connessione avviene da Internet verso la rete locale? In questo caso infatti non sarà chiaro con quale dispositivo sulla LAN si intenderà stabilire la connessione. Sarà necessaria una regola che indichi al router NAT come comportarsi con il traffico in entrata. Nel caso in cui la regola non sia presente, il router scarterà semplicemente il traffico e non stabilirà alcuna connessione. Il router NAT potrà instradare tutto il traffico in entrata ad un solo dispositivo oppure, come più comunemente avviene, utilizzare la tecnica del “Port Forwarding” per consentire al router NAT di passare le richieste di connessione in entrata a diversi dispositivi sulla LAN a seconda della tipologia di protocollo e di porta utilizzata.

Perché il NAT rappresenta una criticità nell’ambito del VoIP ?

Il protocollo SIP è particolarmente sensibile alla traduzione di indirizzi IP e porte. Il protocollo SIP è concepito come protocollo di segnalazione per avviare, modificare e concludere una chiamata. Esso non si occupa quindi direttamente della trasmissione dell’audio, che avviene attraverso il protocollo RTP, ma si preoccupa di istruire i dispositivi in merito agli indirizzi IP e alle porte sulle quali deve avvenire la trasmissione audio RTP.

Il meccanismo di funzionamento del NAT è identico anche quando si naviga su un sito Web utilizzando un PC connesso a Internet tramite un dispositivo NAT. Tuttavia, il protocollo HTTP utilizzato per la navigazione web è molto meno sensibile alle sostituzioni di indirizzi effettuate dal dispositivo NAT. Esso richiede richiede solo che il server web sia in grado di inviare risposte direttamente al browser tramite le stesse porte che sono state utilizzate per avviare il dialogo.

Sfortunatamente, SIP è notevolmente più complicato di HTTP perché implica la negoziazione a due vie tra il dispositivo client e il server. Un elemento essenziale di questa negoziazione è stabilire l’instradamento dei flussi multimediali audio. I flussi audio utilizzano il protocollo RTP e sono generalmente stabiliti direttamente tra endpoint utilizzando porte diverse da quelle utilizzate per i messaggi SIP. Le porte RTP entrano in uno stato di “ascolto” in base al quale possono accettare una nuova connessione da un dispositivo remoto. L’indirizzo IP e il numero di porta RTP  sulle quali avviare l’audio, vengono scambiati tra i dispositivi attraverso un messaggio di Richiesta (INVITE) e il relativo messaggio di risposta (200 OK) . Questa fase si chiama “Setup della chiamata”. Gli endpoint devono connettersi tra loro sulle porte pubblicizzate per stabilire una connessione audio bidirezionale.

Il Protocollo SIP deve essere in grado di attraversare il NAT

Il protocollo SIP trasmette quindi i parametri necessari per avviare la comunicazione all’interno dello stesso messaggio SIP. Tali parametri includono l’IP e i numeri di porta utilizzati per la segnalazione e la trasmissione dei flussi multimediali. Un dispositivo SIP dietro NAT non sa molto di come esso verrà visto sulla rete Internet, conosce solo il proprio indirizzo IP locale e le porte sulle quali viene eseguita l’applicazione SIP. Una volta avviata la comunicazione con Internet, il dispositivo NAT traduce la combinazione “IP privato : porta” del dispositivo SIP connesso sull’interfaccia NAT privata in una mappatura temporanea di un “IP pubblico : porta” sull’interfaccia connessa a Internet.

Il NAT può provocare degli errori nella comunicazione VoIP SIP

Sono moltissime le circostanze in cui ci può essere un conflitto tra il protocollo SIP e il comportamento, a livello di NAT, di un router/firewall. Ecco gli errori più comuni:

• Durante la richiesta di registrazione sul server di un provider VoIP SIP (come ad es. VoipVoice), il telefono IP oppure il PBX comunica al Server SIP l’indirizzo e la porta sulla quale può essere raggiunto per instradare le chiamate in entrata. Molto spesso, quando la configurazione dell’apparato non è corrretta, l’indirizzo IP fornito al server di registrazione è l’indirizzo LAN privato del telefono IP e non l’indirizzo pubblico del router NAT. In questi casi, in assenza di meccanismi di correzione, il provider di servizi potrebbe non essere in grado di inviare messaggi SIP al telefono IP.
• quando un telefono SIP effettua una chiamata, invia una richiesta SIP INVITE. All’interno di tale richiesta, nella sezione SDP, invia anche l’indirizzo IP e la porta sulla quale si aspetta di ricevere il flusso audio. La connessione utilizzata per i messaggi SIP che iniziano e terminano le chiamate (flusso SIP) non è la stessa connessione utilizzata per inviare il flusso audio (flusso RTP). Il flusso audio viene sempre stabilito su una nuova connessione utilizzando un numero di porta completamente diverso da quello SIP. I router NAT normalmente consentono le connessioni in uscita, ma bloccano quelle in entrata. Ciò significa che il telefono potrebbe comunicare al dispositivo remoto di avviare una connessione streaming multimediale , ma il dispositivo remoto potrebbe non essere in grado di aprire la connessione perché  bloccato dal dispositivo NAT.

I Sintomi di una chiamata VoIP con problemi di NAT

Ecco un elenco dei problemi più comuni che potresti incontrare in caso di configurazioni errate a livello di Telefono, Centralino o Router:

• Assenza di audio: la chiamata si avvia, il telefono squilla ma, alla risposta c’è silenzio in entrambe le direzioni.
• Audio monodirezionale: la chiamata si avvia, il telefono squilla ma, alla risposta puoi solo sentire la controparte ma non puoi essere ascoltato, o viceversa.
• Impossibilità di ricevere chiamate: Un altro sintomo è che tu possa chiamare altre persone, ma esse non possono chiamarti. Una variazione di questo comportamento è che altre persone possano chiamarti nei primi minuti dopo che il tuo telefono è stato registrato, ma non dopo 10 o 20 minuti.

Quali sono le soluzioni possibili per l’attraversamento NAT VoIP ?

Quando un telefono IP o un Centralino sono installati dietro NAT, i problemi possono essere creati dal dispositivo NAT stesso (router/firewall), dall’incapacità del telefono di comprendere correttamente il proprio posizionamento di rete o da una combinazione delle due eventualità. Poiché è un problema frequente e prevedibile, la maggior parte dei telefoni IP dispone di funzionalità integrate progettate per aiutarli ad analizzare il proprio ambiente di rete e per aiutare a superare i problemi dell’attraversamento NAT VoIP. Vi sono moltissimo metodi disponibili per il superamento delle barriere di NAT. Ogni professionista installatore dovrebbe conoscere nel dettaglio tutti questi metodi e sapere quale utilizzare in ogni precisa circostanza. La norma di riferimento per il NAT Traversal in ambito SIP è la RFC6314.

1 – STUN (Simple Traversal of UDP through NAT)

Lo STUN è un approccio standard per l’attraversamento di NAT. I dettagli tecnici sono pubblicati come RFC 3489. Richiede che il telefono IP possa accedere ad un server STUN da qualche parte su Internet. VoipVoice fornisce ad esempio il proprio server Stun all’indirizzo stun.voipvoice.it, sulla porta standard 3478. E’ disciplinato dalle RFC3489, RFC5389, RFC 8489

Come Funziona un Server STUN e quali informazioni fornisce?

Per poter utilizzare lo STUN è necessario comunicare al telefono IP l’indirizzo (o URL) di un server STUN su Internet. E’ sempre consigliabile utilizzare il server STUN consigliato dal proprio provider anche se non è obbligatorio. Il server STUN non prevede infatti un dialogo di autenticazione, quindi in genere qualsiasi telefono può utilizzare qualsiasi server STUN. Tutti i telefoni IP VoIP SIP recenti prevedono l’utilizzo di un server Stun.

Il telefono IP (o il Centralino IP) prima di effettuare qualsiasi tentativo di registrazione o chiamata, invia una serie di richieste al server STUN specificato. Il server STUN esegue alcuni semplici test per determinare cose come: Il telefono IP è dietro un dispositivo NAT? Qual è l’indirizzo IP esterno del dispositivo NAT? In che misura il dispositivo NAT applica le regole per il blocco delle connessioni UDP in entrata? Fa differenza per le connessioni in entrata se è già stata stabilita una connessione in uscita a quell’indirizzo remoto?

In sostanza le informazioni fornite da un server stun saranno due:

1. Indirizzo IP pubblico utilizzato sul lato WAN dell’apparato Router/Firewall
2. Tipologia di NAT e di PAT (Port Address Translation) utilizzata dal Router.

Una volta effettuate questi test il server STUN restituisce i risultati al telefono IP. Il telefono IP è quindi in grado di utilizzare queste informazioni per modificare i messaggi SIP che invia quando si registra oppure prima di effettuare la chiamata. All’interno del messaggio SIP verranno utilizzati gli indirizzi IP pubblici in luogo di quelli privati e le rispettive porte corrispondenti, in funzione della tipologia di NAT utilizzato.

Quali sono i limiti di utilizzo di un Server Stun ?

L’utilizzo del server STUN è principalmente indicato per il collegamento di Telefoni IP ad un provider VoIP o ad un Centralino VoIP  in Cloud. Dovendo interrogare un server esterno, lo STUN introduce necessariamente un ritardo, più o meno avvertibile, nella composizione delle chiamate. Per questa ragione l’utilizzo dello STUN server è sconsigliabile in abbinamento ai Centralini IP per i quali esistono sistemi più efficaci: in primo luogo la configurazione di opportune regole di Port Forwarding e inserimento diretto dell’indirizzo IP statico pubblico utilizzato.

2 – Port Forwarding (Port Mapping)

Il concetto di Port Forwanding si riferisce ad un Router-Firewall. Il Port Forwarding, anche detto “Port Mapping”, si ottiene creando un’associazione (chiamata mappa) tra un indirizzo IP pubblico (WAN) con la rispettiva porta e un indirizzo IP privato (LAN) con la rispettiva porta.  Il compito del Port Forwarding è quello di indirizzare il traffico dal mondo esterno al server appropriato all’interno di una rete TCP / IP locale. La norma RFC di riferimento è la RFC6886 .

NAT Statico e NAT Dinamico

A livello generale è infatti possibile distinguere due tecniche per la traduzione degli indirizzi di rete: il NAT Statico e il NAT Dinamico.

• Nel caso di NAT Dinamico, la tabella di NAT viene popolata automaticamente in funzione delle connessioni avviate da un Client della rete interna verso la rete esterna. Questa modalità di NAT è anche detta Ip Masquerading o IP Overloading. I Record della tabella di NAT in questo caso sono temporanei e il router li aggiorna dinamicamente in funzione delle connessioni attive.
• Nel casi di NAT Statico, la corrispondenza tra indirizzo IP e relative porte, private e pubbliche, viene definito con regole permanenti. Rispetto al NAT dinamico, il NAT statico presenta il vantaggio di poter rendere raggiungibili non solo i client che iniziano le sessioni di comunicazione, ma anche i server interni a una rete privata. In questo secondo caso, i record della tabella di NAT sono scritti in maniera permanente.

Il Port Mapping in ambito VoIP SIP

Quando si lavora con dispositivi VoIP SIP dietro ad un NAT, soprattutto nel caso di Centralini VoIP SIP, è fortemente consigliato operare con un NAT statico. Le porte che in genere dovrebbero essere inoltrate sono le seguenti:

1. La porta di ascolto SIP principale: normalmente corrisponde con la porta 5060. Il protocollo può essere UDP oppure TCP
2. Il Range di porte destinato allo scambio audio RTP e al flusso di controllo RTCP: per ogni comunicazione SIP è richiesta una porta per lo scambio audio/video multimediale (RTP – porta pari) e una porta per lo scambio delle informazioni di controllo (RTCP – porta dispari). In questo caso viene comunemente inoltrato un intervallo di porte piuttosto ampio (ad. es. 20000 -30000). Il protocollo utilizzato è sempre UDP.

Nel caso di Centralini VoIP Ip sarà sempre necessario configurare o conoscere la porta di ascolto SIP utilizzata e il relativo range di porte RTP/RTCP. Al fine di garantire la piena compatibilità con il protocollo SIP sarà sempre raccomandabile non utilizzare alcuna traduzione delle porte. In sostanza la porta “privata” di ascolto e quella “pubblica” dovranno sempre corrispondere. Questo particolare comportamento a livello di NAT è definito Static Port Mapping ed è quello raccomandato con qualunque PBX VoIP.

3 – Impostazione manuale dell’indirizzo IP pubblico

Alcuni dispositivi VoIP – Telefoni IP e Server SIP come Asterisk o 3CX – dispongono di parametri parametri configurabili che includono un’opzione per specificare l’indirizzo IP dell’interfaccia esterna sul dispositivo NAT. Quindi, ad esempio, se il vostro PBX basato su Asterisk è dietro NAT e presenta problemi ad effettuare le chiamate SIP con provider VoIP esterni, è molto probabile che si possa risolvere il problema impostando l’IP pubblico esterno (nel file SIP.CONF – parametro “externip”) e abilitando il Port Forwarding.

La connessione Internet con IP pubblico statico è un elemento indispensabile per l’installazione professionale di qualunque Centralino IP. In questi casi l’indirizzo IP Pubblico statico e il comportamento del router dovrebbero sempre essere conosciuti a priori. Sarebbe quindi totalmente inutile ed inefficiente procedere utilizzando un server stun o funzionalità quali il KeepAlive. L’utilizzo a priori dell’indirizzo IP pubblico unito ad un Port Forwarding operato con Static Port Mapping garantiscono sempre il migliore risultato in assoluto e la certezza di una piena funzionalità.

4 – Keep Alive

La funzionalità di Keep-Alive è particolarmente efficace con i telefoni IP SIP utilizzati con configurazioni di NAT Dinamico. E’ presente in tutti i moderni telefoni VoIP SIP. E’ disciplinato dalla RFC6223 del 2011.

Quando un telefono IP effettua la registrazione su un VoIP Provider, esso comunica il proprio IP pubblico e la propria porta di ascolto, magari recuperate attraverso un server Stun. Il provider VoIP memorizzerà l’IP e la porta del telefono e supporrà che rimangano gli stessi a meno che non venga effettuata una registrazione con una configurazione diversa.

In questo contesto stiamo però operando in configurazione di NAT dinamico. I Router provvedono a creare dinamicamente la mappa di NAT. Così facendo essi provvedono a creare nuovi record di NAT ma anche ad eliminare periodicamente i record relativi a connessioni inattive.

Il criterio di funzionamento del NAT keepalive è molto semplice: il telefono IP, utilizzando il kee-alive invia pacchetti molti piccoli (in genere dei pacchetti vuoi) dal telefono IP verso il provider. Questi pacchetti, inviati ad intervalli di tempo regolari, di 10 o 15 secondi,  hanno il solo scopo di mantenere attive le connessioni. In questo modo i record presenti nella tabella di NAT del Router (NAT mappping table) vengono mantenuti attivi. Il valore di keep alive suggerito in abbinamento agli account SIP Voipvoice è di 15 secondi.

Alcuni Consigli per L’utilizzo della funzionalità di Keep Alive:

1. Il NAT Keep-Alive è molto utile in combinazione con la funzionalità di STUN e con quella di Rport. L’utilizzo combinati di Stun + Keep Alive + Rport consente ai telefoni IP di superare la maggior part delle barriere di NAT (dinamiche). Questa combinazione è molto utile per i telefoni IP ma è sconsigliata per i PBX. Per questi ultimi è invece preferibile un ambiente più stabile e senza la variabilità di porte legata al NAT dinamico. Per i Centralino VoIP la configurazione Ideale è legata all’utilizzo di NAT statico con mappatura statice delle porte (static port mapping); l’IP pubblico deve essere pre-configurato nel PBX stesso. Poichè il NAT statico espone potenzialmente le porte ad un attacco è sempre suggerito l’utilizzo di filtri ACL sulle regole di NAT.
2. Quando in una rete locale sono presenti più telefoni IP che si registrano su un PBX in cloud, senza l’ausilio di SBC, è vivamente consigliabile differenziare le porte SIP e RTP utilizzate da ogni telefono. Ciò evita la sovrapposizione delle porte sul lato pubblico e consente, nei casi più difficili, di utilizzare anche regole di NAT statico per i telefoni.

5 – SIP “Received” e “Rport”

La RFC3581 del 2003 ha introdotto un’estensione al protocollo SIP molto utile per superare le difficoltà legate alla gestione del NAT simmetrico. In particolare mi riferisco alle estensioni “Received” e “rport”  presenti nell’header SIP “VIA”. Il funzionamento di queste due estensioni è piuttosto complesso e viene trattato nel dettaglio durante i corsi di Certificazione VoipVoice. Nel caso in cui non si conoscano le basi del protocollo SIP, è sufficiente considerare questi meccanismi come un ulteriore supporto al superamento delle barriere di NAT.

Cercando di semplificare l’argomento, durante una chiamata SIP, il chiamato invia le risposte al chiamante determinando le informazioni nell’header “Via” , che viene creata dal chiamante, durante la composizione delle richieste iniziali (ad esempio: INVITE). Negli ambienti reali, quando la maggior parte degli endpoint si trova dietro un NAT, di solito essi, (in assenza di meccanismi come quelli visti al punto 1 e 3) si presentano con i loro indirizzi privati, che non sono raggiungibili dai server esterni.

La prima cosa da fare quando un dispositivo SIP (Telefono IP o PBX)  si presenta al provider con un IP e una porta privata è quella di correggere immediatamente la configurazione, utilizzando uno dei metodi appena visti (punti 1-4).

Ciononostante è possibile che un PBX legacy si presenti ai nostri server SIP VoipVoice utilizzando nell’intestazione VIA gli identificativi (IP e porta) della rete locale e richiedendo una chiamata a un server pubblico esterno alla rete. Quell’URI non è assolutamente raggiungibile dal server. Pertanto, le risposte non torneranno mai correttamente al chiamante.

Via: SIP / 2.0 / UDP 192.168.XX: 5060 ; branch = c7hr56789er9943652834456

Un soluzione a questo problema passa per l’utilizzo delle estensioni “Received” e “rport” dell’header “VIA”

Il parametro “received”

“received” è un parametro standard nell’intestazione Via, che contiene l’effettivo indirizzo sorgente da cui è stato ricevuto il pacchetto. Il parametro “ricevuto” viene generato se l’IP nell’intestazione Via è diverso dall’indirizzo di origine del pacchetto UDP.

Il parametro “rport” (response-port)

“Rport” è in realtà un analogo al parametro “ricevuto”, tranne che “rport” contiene una porta, non un indirizzo IP, definito in rfc3581. Quando un controllo dell’account utente genera una richiesta, può contenere un parametro “rport” vuoto nell’intestazione Via.  Quando un UAS riceve una richiesta, esamina l’intestazione Via più in alto per verificare l’esistenza del parametro “rport” senza valore, se ce n’è uno, DEVE impostare il valore del parametro sulla porta di origine della richiesta.

La presenza del parametro “rport” sovrascrive anche la regola per la generazione del parametro “ricevuto”: UAS deve inserire un parametro “ricevuto” contenente l’indirizzo IP di origine da cui proviene la richiesta, anche se identico al valore specificato nell’intestazione Via.

Quelli che stiamo esponendo sono concetti piuttosto complicati se non si hanno presenti le basi del protocollo SIP. Proviamo però a fare un esempio più concreto. Supponiamo che il PBX legacy sia più evoluto e supporti l’estensione RFC3561. Esso aggiungerà un parametro “rport” vuoto (senza una porta specifica) nella sua header “via” prima di inviare il proprio INVITE.

INVITE
Via: SIP / 2.0 / UDP 192.168.XX: 5060 ; branch = c7hr56789er9943652834456; rport;

In questo caso supponiamo che l’IP pubblico di origine sia 87.0.0.1 e la porta di origine sia 12345. Il server SIP VoipVoice, che supporta anche rfc3581, aggiungerà i parametri “rport” e “riceived” alla risposta 200 OK. Se la porta non sarà stata modificata, verrà aggiunto il solo parametro “received”

Via: SIP / 2.0 / UDP 192.168.XX: 5060 ; branch = c7hr56789er9943652834456; rport = 12345; received = 87.0.0.1

Il server in questo caso non rimanda le risposte all’indirizzo IP e alla porta presenti nell’intestazione Via (192.168.XX: 5060), ma a quelle presenti nei parametri “rport” e “received”, ossia all’indirizzo esterno e alla porta esterna ( 87.0.0.1 : 12345 ). Il dispositivo router, che gestisce l’associazione NAT, ritrasmetterebbe correttamente le risposte al PBX legacy utilizzato.

Se la spiegazione è stata troppo complessa è sufficiente pensare che l’estensione RFC3581 e i parametri “received” e “rport” consentono di mandare la risposta SIP semplicemente “indietro da dove è venuta la richiesta!”.

Attenzione a non abusare delle estensioni!

Le estensioni “received” e “rport” sono state introdotte per compensare le lacune del protocollo SIP nel 2003. Nel frattempo il protocollo SIP stesso e le funzionalità dei moderni Centralini SIP si sono evolute. Per questa ragione, qualora si rilevi l’utilizzo di un IP e una porta privata, al posto del corretto indirizzo IP e porta pubblica, è indispensabile andare a correggere la configurazione del telefono o del PBX affinché l’INVITE e l’header “via” siano correttamente trasmesse. In caso contrario si potranno verificare i comuni problemi di chiamata riconducibili a problemi di NAT.

Nell’ultimo anno stiamo assistendo all’innovazione organizzativa e tecnologica del sistema produttivo e ai cambiamenti del mercato del lavoro. In questo contesto aggiornarsi con costanza è un must to do per essere sempre più competitivi sul mercato, consentendo di farsi trovare pronti alle nuove sfide che si presentano.

Le aziende che hanno il desiderio di crescere non possono fare a meno di avere nel proprio team dei professionisti competenti, che riescono a soddisfare al meglio le esigenze dei propri clienti. A sua volta, il dipendente formato a livello professionale avrà una maggiore motivazione a svolgere con cura il proprio lavoro, che si tradurrà nell’ottimizzazione dei processi lavorativi.

VoipVoice da sempre sostiene il concetto di  lifelong learning, e cerca di fornire ai suoi Partner degli strumenti che possano aiutarli a diventare dei professionisti preparati e aggiornati.

È da questo concetto che è nato il nuovo progetto della VoIP Academy E-Learning, una formazione continua, che ci accompagnerà per tutto il 2021. Ogni mese aggiungeremo dei Webinar formativi gratuiti con tematiche legate alla tecnologia VoIP, alle connettività e ai nostri servizi.

Ecco il calendario dei primi appuntamenti:

26 marzo – Le soluzioni a valore per le telecomunicazioni digitali

Durante questo Webinar Annamaria Pugliano, Area Manager Sud Italia e Isole VoipVoice, affronterà il tema dello stato di digitalizzazione in Italia, presentando la nuova Easy Solutions e le soluzioni a valore per le telecomunicazioni digitali per le aziende e Pubbliche Amministrazioni italiane.

Clicca qui per iscriverti

02 aprile –Le problematiche di Routing e NAT nell’ambito VoIP

Matteo Sala, VoIP Academy Director VoipVoice, presenterà la guida pratica ai concetti fondamentali del routing in ambito VoIP, nonché alla sua corretta installazione e configurazione. Fornirà alcuni consigli su come risolvere in modo efficace le problematiche ricorrenti.

Clicca qui per iscriverti

09 aprile – Strumenti di troubleshooting e supporto snom

Questo sarà il primo appuntamento di un Webinar a due voci. Massimo Lucini, Channel Italy Director snom, e Federico Rossi, Team Lead Technical Support snom, spiegheranno come effettuare un Factory Reset dei telefoni Descktop snom (Serie D7xx) quando non abbiamo la password di amministratore e come fare troubleshooting analizzando una SIP Trace o un Sys Log preso direttamente dal telefono. Come ultimo argomento, ci mostreranno come utilizzare la piattaforma di helpdesk.snom per richiedere il supporto gratuito.

Clicca qui per iscriverti

15 aprile – Easy Solutions Router: guida tecnica alla scelta, dimensionamento, bilanciamento e backup

Durante questo Webinar, partiremo da un confronto sulle funzionalità degli apparati Draytek, fornendo una guida pratica al corretto utilizzo dei router e alla corretta scelta di essi in base alle esigenze di connettività e di backup, nell’ambito delle Easy Solutions.

Clicca qui per iscriverti

21 aprile – EPOS | Sennheiser: la cuffia ideale per ogni tipo di esigenza

Con Simone Albanini, Key Account Manager Epos | Sennheiser Italia, andremo ad approfondire i prodotti della famiglia di cuffie IMPACT, ADAPT ed EXPAND, analizzando la corretta scelta del device in base alle esigenze  del cliente.

Clicca qui per iscriverti

30 aprile – Business Continuity: la continuità operativa efficace e proattiva

Ogni imprenditore sa cosa può comportare trovarsi improvvisamente disconnessi. Può comportare un rallentamento del lavoro e quindi una perdita di fatturato. In questi casi diventa indispensabile avere una connettività di backup, che possa garantire la continuità operativa. Per questo, come VoipVoice, promuoviamo la Business Continuity come un servizio essenziale per ciascuna azienda, proponendo in abbinamento a FTTC e FTTC dei backup su rete 4G LTE. Durante il webinar andremo ad affrontare la tecnologia e il modus operandi dei diversi tagli di Business Continuity VoipVoice.

Clicca qui per iscriverti

06 maggio – La corretta gestione dei Codec Audio per il VoIP SIP

In questo webinar verrà affrontata la questione su come scegliere efficacemente il Codec Audio da utilizzare in ambito VoIP SIP, in relazione alla banda dati disponibile e al contesto di utilizzo.

Clicca qui per iscriverti

13 maggio – Gestione avanzata del QoS con VoipVoice Easy Solutions Router

Durante il Webinar di Matteo Sala, VoIP Academy Director VoipVoice, andremo a vedere come gestire, attraverso una guida tecnica applicata per i router Draytek con sistema operativo DrayOS, la priorità della voce rispetto ai dati con le soluzioni  High e Top Level dell’offerta VoipVoice Easy Solutions Router.

Clicca qui per iscriverti

Improve Yoursel con VoipVoice!!

Che cosa sono i codec audio per il VoIP ?

Un codec VoIP è una tecnologia che determina la qualità audio, la larghezza di banda e la compressione delle chiamate telefoniche VoIP (Voice over Internet Protocol). I codec VoIP utilizzano algoritmi proprietari oppure open source.

La parola codec deriva dalla fusione delle iniziali di due parole: codifica e decondifica (co-dec).

I codec VoIP condividono tutti uno scopo: comprimono e decomprimo i dati  audio per spostarli il più rapidamente possibile e con la migliore qualità possibile. Tutti le applicazioni VoIP hanno come fine quello di garantire una chiamata chiara e nitida, facendo in modo che le chiamate telefoniche occupino una larghezza di banda non eccessiva.

Gli apparati VoIP hanno come scopo quello di convertire i segnali analogici in segnali digitali (dati), comprimendo i dati attraverso un algoritmo di codifica, per poi trasmettere in tempo reale questi stessi dati attraverso la rete internet. Una volta che i dati avranno raggiunto il dispositivo telefonico destinatario, essi saranno decodificati e ritrasformati in un segnale analogico da indirizzare all’altoparlante del telefono. Questo processo in tempo reale è bidirezionale per poter permettere agli interlocutori di parlare e ascoltare contemporaneamente.

Il codec è quindi un elemento fondamentale nel determinare la qualità di una moderna comunicazione VoIP. Esso però non è l’unico fattore determinante. Le altre condizioni che determinano la qualità di una chiamata sono:

• la qualità della connessione dati Internet: è espressa dai valori di BMG (banda minima garantita) in Upload e Download, dalla latenza media (ms), dal Jitter.
• la congestione della rete locale
• la disponibilità di un meccanismo in grado di determinare una priorità per i dati voce rispetto agli atri dati generici (QoS).

Di tutti questi fattori avrò modo di parlare approfonditamente in seguito. In questo articolo invece cercherò di porre l’attenzione sui codec audio VoIP utilizzati congiuntamente al protocollo SIP. Cercherò di soffermarmi sui meccanismi più comunemente utilizzati per codificare, comprimere e trasmettere l’audio attraverso una rete dati. Valuterò la qualità delle soluzioni tecnologiche attualmente disponibili, così pure i possibili e prevedibili scenari futuri. Cercherò infine di fornirvi qualche utile suggerimento pratico per ottimizzare la qualità audio delle vostre chiamate VoIP.

I fondamenti della qualità audio

Come si determina la qualità e la fedeltà dell’audio digitale? A prescindere dalla compressione, la qualità di registrazione digitale di una traccia audio è definita da alcuni parametri:

• Frequenza di campionamento (sample rate): si riferisce ai campioni audio presi per secondo. Ogni singolo campione ti dirà il valore di ampiezza totale della forma d’onda del segnale in un periodo specifico. Maggiore è la frequenza di campionamento, migliore è la qualità audio. La frequenza di campionamento è il numero di volte in cui viene misurato l’audio (campionato) al secondo. Così, uno standard Red Book per i CD ha una frequenza di campionamento di 44.1 kHz o 44.100 campioni al secondo.
• La Profondità di Bit: essa si riferisce al numero di bit che devono descrivere ogni singolo campione audio. Si tratta, in sostanza, di tradurre il suono analogico in campioni digitali costituiti da 0 e 1. Lavorare a 16 bit significa lavorare con campioni audio che possono avere ognuno 65.536 possibilità di descrivere il suono. Se invece lavoriamo con una profondità di bit inferiore, ad es. 8 bit, avremo un dettaglio del suono decisamente inferiore e pari a 256 possibilità.
• Audio non compresso (lineare) o audio compresso:  la compressione audio ha l’obiettivo di ridurre la quantità di dati necessaria per la trasmissione di un suono. Il codec utilizza un particolare algoritmo, che si basa sulla percezione del suono da parte di una persona, alfine di ridurre i dati necessari per trasmettere un determinato flusso audio.
• Bitrate Audio: è la quantità di dati utilizzati per trasmettere l’audio. Il bitrate audio indica quante informazioni al secondo vengono trasferite. A parità di codec (compressione), un bitrate più alto indica una migliore qualità del suono.
• Larghezza di banda Internet: è la velocità massima con cui il collegamento in uso (Adsl, FTTC, FTTH…) sarà in grado di inviare e ricevere dati.

Come si valutano l’efficienza e l’efficacia di un codec audio per il VoIP ?

Il parametro con il quale si valuta l’efficienza di un codec audio per il VoIP è denominato MOS (Mean Opinion Score). Il MOS è un parametro completamente empirico in quanto si basa sull’esperienza diretta dell’orecchio umano. Non c’è quindi alcun complesso meccanismo alla base delle valutazioni di qualità espresse attraverso il MOS. A un gruppo esperto e selezionato di persone è stato richiesto di esprimere un giudizio qualitativo in merito agli stessi contenuti audio compressi con codec differenti.

Il MOS è espresso in una scala di valori da 1 a 5:

5 – Eccellente
4 – Buono
3 – Discreto
2 – Scarso
1 – Pessimo

In effetti nel valutare la qualità dei codec audio nel 2021, un parametro come il MOS, utilizzato da decenni, potrebbe essere addirittura considerato anacronistico. Con l’avvento dei nuovi codec ad alta definizione, la scala di valutazione dei codec audio richiederebbe una riclassificazione per evidenziare il netto divario tra i codec più moderni e quelli più datati. Uno dei maggiori limiti del MOS è inoltre quello di essere un parametro di valutazione strettamente qualitativa: si valuta la bontà audio di un codec VoIP senza però considerare l’efficacia del codec in termini di compressione dei dati. Un altro fattore che il MOS non considera assolutamente è la capacità del codec di adattarsi dinamicamente al contesto nel quale avviene la trasmissione. E’ proprio su questo aspetto che si attendono i principali miglioramenti, in termini di trasmissione audio, nelle chiamate VoIP.

La valutazione uditiva dei principali codec audio per il VoIP SIP

Di seguito la valutazione uditiva del principali codec impiegati dai VoIP provider.

Nel valutare la qualità dei codec occorre considerare che il codec G711A è quello comunemente utilizzato sulle linee ISDN e costituisce il parametro medio di riferimento. Utilizzando il codec G711, in condizioni ottimali, la qualità della chiamata è esattamente pari a quella di una comune linea ISDN.

• G711A – MOS pari a 4,2
• G711U- MOS pari a 4,2
• G729- MOS pari a 4
• GSM- MOS pari a 3,5
• G722 – MOS pari a 5 (HD codec)
• OPUS – MOS pari a 5+ (HD codec con bitrate variabile)

Quanta banda dati occupano realmente i codec audio VoIP SIP ?

• Il GSM: ha un’occupazione nominale di banda di 13Kbps e un indice MOS di qualità pari a 3,5. La qualità della conversazione è più che discreta ma comunque inferiore al G729 e soprattutto al G711. E’ comunque un codec intellegibile e la qualità audio, come suggerisce il nome, è quella sperimentabile sulle comuni linee mobili cellulari 2G. Il Codec GSM è utilizzato solo da pochi operatori.
• il  G.729: è un codec con una ridotta occupazione di banda ma fornisce una buona qualità audio. Costituisce il codec più comunemente usato per le chiamate VoIP.
• il G.711: nella versione A (europea) e U (americana) è stato introdotto dall’ITU nel 1972 per l’uso con la telefonia digitale ISDN. Con un rapporto di compressione pari a 1:2 e un’occupazione nominale di banda pari a 64Kbps per ogni direzione, è ancora il miglior codec da utilizzare quando vi è banda disponibile. E’ sensibilmente migliore del codec G729 a livello di qualità audio e la voce appare più brillante del codec G729. Nell’ambito delle comunicazioni VoIP SIP e della trasmissione dati a pacchetto, il codec G711 viene comunemente denominato PCMA (G711A) e PCMU (G711U).
• il G.722: è un codec con bitrate elevato (48/56/64Kbps) definito dallo standard  ITU ed è molto migliore del tradizionale codec impiegato sulle linee ISDN. Può essere utilizzato in ambito locale per effettuare chiamate tra gli interni di un comune PBX per comunicazioni vocali di alta qualità. E’ un codec presente sulla maggior parte dei telefoni IP di media e alta qualità in commercio. L’utilizzo di questo codec prevede che il telefono disponga di microfono e di altoparlante in grado di catturare e riprodurre fedelmente una banda audio estesa.
• OPUS: è un codec audio totalmente aperto, esente da royalty e altamente versatile. Opus non ha eguali per la trasmissione di musica e voce interattiva su Internet, ma è pensato anche per applicazioni di archiviazione, streaming e telefonia. È standardizzato dall’Internet Engineering Task Force (IETF) come RFC 6716 che incorporava la tecnologia del codec SILK di Skype e del codec CELT di Xiph.Org.

La rivoluzione del Codec Audio Opus nell’ambito VoIP

L’impiego massivo del codec Opus nell’ambito della telefonia VoIP è quanto di meglio si possa attendere dal punto di vista del miglioramento della qualità e dell’efficienza per le trasmissioni audio realtime. Si tratta del primo codec audio per la telefonia VoIP in grado di adattarsi dinamicamente al contesto di utilizzo. Il codec è inoltre in grado di rispondere attivamente alla perdita di pacchetti dati. Ecco le principali specifiche:

• Bitrate da 6 kb/s a 510 kb/s
• Frequenze di campionamento da 8 kHz (banda ridotta) a 48 kHz (banda piena)
• Dimensioni del frame da 2,5 ms a 60 ms
• Supporto sia per bitrate costante (CBR) che per bitrate variabile (VBR)
• Larghezza di banda audio da ridotta a banda estesa
• Supporto per parlato e musica, mono e stereo
• Può implementare fino ad per un massimo di 255 canali (frame multistream)
• Bitrate, larghezza di banda audio e dimensioni del frame regolabili dinamicamente
• Buona resistenza alla perdita e occultamento della perdita di pacchetti (PLC)
• Implementazione in virgola mobile e virgola fissa

Il Codec Opus è attualmente utilizzabile su alcuni dei trunk SIP offerti da VoipVoice. La vera rivoluzione in termini di qualità audio delle telecomunicazioni VoIP SIP nazionali si avrà quando e se si deciderà di impiegare il codec Opus (o un codec equivalente) quale standard di scambio audio tra gli operatori. Attualmente lo scambio audio tra operatori nazionali/internazionali avviene ancora sulla base del codec G711. Ciò, di fatto, costituisce l’effettivo limite al miglioramento della qualità audio globale nel mondo della telefonia fissa.

Quanta banda occorre per effettuare una conversazione utilizzando una linea dati dedicata al VoiP

Se ipotizziamo di dedicare una linea dati esclusivamente al VoIP, dobbiamo considerare sempre un solo valore: la Banda Minima Garantita (BMG) di una linea dati.

La BMG costituisce il vero collo di bottiglia di una comune linea XDSL, FTTC o FTTH. In particolare, essendo la comunicazione VoIP bidirezionale, dovremo considerare sempre – come limite – il valore di upload garantito dalla connettività.

Al valore di banda nominale tipico del codec audio, dovremo sempre sommare i dati di instradamento tipici di una trasmissione a pacchetti.

Tralasciando la metodologia di calcolo, poco rilevante al fine di un calcolo empirico, andranno considerati i seguenti valori medi:

• G711A/U: Banda Effettiva 87,2Kbps in upload e 87,2Kbps in download
• G729: Banda Effettiva 31,2Kbps in upload e 31,2Kbps in download
• GSM: Banda Effettiva 22.5Kbps in upload e 22.5Kbps in download

Un esempio: nel caso di una connettività con BMG in upload pari a 512Kpbs, esclusivamente dedicata al VoiP (il valore in download è in questo caso irrilevante) potremo effettuare, con un calcolo piuttosto preciso:

• 16 conversazioni con codec G729
• 5 conversazioni in G711

Quanta banda occorre per effettuare una conversazione in VoIP su linea dati condivisa?

In caso di linea condivisa occorre innanzitutto specificare che è d’obbligo l’utilizzo di un Router con supporto per il QoS. Il QoS (Quality of Service) è una funzionalità del router che permette di dare priorità al traffico voce rispetto al traffico dati. Nelle migliori implementazioni QoS, il meccanismo consente ai pacchetti voce di bypassare completamente le code di routing attraverso un acceleratore hardware, riducendo la latenza di elaborazione ed eliminando fenomeni interni di jitter dovuti alla gestione interna delle code di pacchetti.

Senza l’utilizzo di meccanismi di QoS, il degrado dell’audio (mancanza di intellegibilità, audio a scatti, audio metallico o disturbato, fenomeni di eco) sarà il risultato più probabile nel momento in cui venga semplicemente invita una mail con un allegato di pochi Mbyte o venga eseguito il download di un file di dimensioni elevate.

In tutti i casi di installazione Business in cui si preveda l’utilizzo professionale di una linea condivisa per Voce/Dati è assolutamente necessario prevedere l’utilizzo di un sistema di QoS.

Quale codec audio è preferibile utilizzare oggi?

Riporto di seguito sinteticamente alcune considerazioni e consigli pratici.

• In assenza di motivazioni specifiche ed in presenza di disponibilità di una buona connettività in fibra, si consiglia sempre di utilizzare il codec G711. La preferenza andrebbe sempre espressa sia sul dispositivo terminale (telefono IP o Softphone) che sul singolo trunk a livello di PBX. La negoziazione del codec audio tra il PBX ed un provider VoIP è un meccanismo abbastanza rigido per il quale, a parità di condizioni, il codec utilizzato sarà sempre lo stesso. E’ quindi sostanzialmente inutile prevedere l’utilizzo di svariati codec sullo stesso trunk VoIP SIP. E’ invece consigliabile stabilire a priori il codec da utilizzare in base alle caratteristiche specifiche della connettività e al numero di chiamate simultanee che si intende effettuare.
• In linea di massima è sempre preferibile evitare il processo di transcodifica audio. La conversione fra diversi codec comporta, ad ogni passaggio, un degrado della qualità audio complessiva. Ciò è valido sia sul fronte interno al PBX (dal dispositivo telefonico al VoIP Provider) sia sul fronte esterno al PBX (dal provider alla rete di scambio nazionale). Considerando che il codec più utilizzato nell’interscambio nazionale/internazionale è il G711, resta la raccomandazione di utilizzare il codec G711 ove non sussistano limitazioni di banda dati. Nel momento in cui lo standard di interscambio dovesse cambiare in meglio (ad es. da G711 ad Opus) questa considerazione andrà rivista.
• Solo in caso di carenza di banda dati o circostanze specifiche si consiglia l’impiego del codec G729 invece del G711.
• Il codec G722 è principalmente utilizzato per gli scambi audio locali (chiamate tra interni locali e remoti del pbx) ma non è utilizzato sui trunk SIP Voipvoice.
• Il codec Opus è disponibile su alcuni dei trunk SIP VoipVoice. Per qualunque informazione relativa all’attivazione di servizi con supporto Opus è possibile rivolgersi allo staff commerciale.
• Se si desidera utilizzare il codec Opus per effettuare chiamate HD fra gli interni telefonici aziendali (locali o remotizzati), è consigliabile impostare il codec come prioritario sull’interno telefonico. In questa fattispecie sarà però importante ricordarsi che il codec HD sarà realmente percepibile solo nelle chiamate tra interni. Per le chiamate sulla rete pubblica, la qualità della conversazione, pur impiegando un codec HD, sarà comunque limitata dal codec utilizzato in fase di interscambio tra operatori.

Articolo a cura di Matteo Sala, VoIP Academy Director VoipVoice

Pochi giorni fa abbiamo pubblicato all’interno dell’Area Riservata VoipVoice dedicata ai nostri Partner una nuova sezione, la sezione FAQ.

A prima vista può sembra una semplicissima sezione in cui raggruppiamo definizioni, modalità operative e caratteristiche sui servizi ed è effettivamente lo è ma non solo.

Tutti i Partner VoipVoice sanno quanti Servizi sono presenti nel nostro Listino, Connettività, Numeri a consumo e FLAT, Servizi Opzionali, FaxToMail, Reti Wired e Wireless, Hardware legati a differenti esigenze. Differenti esigenze significa creare dei Servizi scalabili e flessibili e ovviamente rendere l’Offerta congrua ed integra nel suo complesso.

Sicuramente vi sarete chiesti se posso attivare in automatico una deviazione di chiamata, quanto tempo ci impiega un numero a migrare, quale Router è adatto su un determinato collegamento in FTTC o FTTH, se posso analizzare un circuito che perde pacchetti,  se posso estrapolare un interno di un GNR, perché una chiamata cade dopo 30 secondi, come creare le regole del Firewall, cosa è una VoipSim??

Ora sto spoilerando troppe FAQ ma solo per farvi capire che è stato un lavoro di raccolta ed organizzazione di tutte le conoscenze Tecniche, Amministrative, Commerciali relative ai nostri servizi.

Sono presenti le Schede Tecniche su Router, GNR, FaxToMail, Domini VoipVoice e Link di supporto alla configurazione di Hardware & Software create e sistemate dal nostro Reparto Marketing.

Vi invito a visitare la nuova sezione tramite questo Link (salvate tra i preferiti l’Area Riservata VoipVoice!), ad utilizzare questo strumento e a cercare in maniera molto facile e celere le risposte alle vostre domande.

La conoscenza è una delle armi più forti che un uomo, un tecnico, un commerciale, un Partner può avere!

Buon lavoro a tutti!

Il mese di febbraio di VoipVoice è partito di gran sprone con la Web Edition dei VoipDays, il tour virtuale che ci ha permesso di poter andare a salutare – seppur virtualmente – tutti i nostri Partner toccando ogni Regione d’Italia! Abbiamo racchiuso il nostro percorso in quattro appuntamenti: Sud Italia e Isole, Centro Italia, Nord Est Italia e Nord Ovest Italia. Il nostro obiettivo è promuovere il cambiamento verso il digitale, diffondere le telecomunicazioni digitali in tutta Italia, far capire alle aziende che la digitalizzazione dei propri assetti organizzativi è necessaria per essere competitivi sul mercato e avere una crescita economica maggiore.

Durante queste giornate abbiamo presentato 3 grandi novità: Easy Solutions, il nuovo servizio che permette di inserire in un’unica fattura gli apparati router, telefoni e cuffie, a supporto delle telecomunicazioni digitali; il nuovo Business Partnership Program, il processo di evoluzione e crescita che ciascun Partner intraprende al momento in cui inizia a collaborare con VoipVoice; ed infine, i due nuovi tagli della Business Continuity, la connettività di backup che permette di rimanere connessi qualora la principale non fosse attiva

Non solo servizi ma anche formazione e motivazione! Abbiamo avuto l’onore di avere un grandissimo ospite, un campione del Rugby Italiano, conosciuto a livello internazionale: Mauro Bergamasco! Durante gli appuntamenti dei VoipDays ci ha parlato di come nasce un Team e dei segreti per poter formare una squadra di successo. Proprio la squadra e il lavorare in team è stato il leitmotiv del tour: Go On perchè tutti insieme vogliamo ripartire e spingere ancora di più la digitalizzazione in Italia!

Abbiamo chiesto ai nostri Area Manager cosa hanno significato per loro queste 4 giornate. Ecco le loro impressioni:

Annamaria Pugliano – Area Manager Sud Italia e Isole

Secondo anno di VoipDay in Web Edition, come detto durante l’evento non nascondo il rammarico nel non poter incontrare i Partner dal vivo, dopo un anno inteso di mail, telefonate e preventivi. La possibilità di condividere dal vivo i risultati raggiunti assieme. Allo stesso tempo però, la presenza dei Partner durante l’Evento, il non esserci mai fermati e l’aver lavorato assieme per poter raggiungere i risultati ottenuti nel Sud Italia ed Isole mi rende ugualmente molto soddisfatta. Abbiamo presentato importanti novità ma soprattutto un nuov0 e concreto percorso di crescita per i nostri Partner in cui abbiamo deciso di investire ancora di più nella Business Partnership Program. Ringrazio ancora tutti coloro che hanno partecipato e aspetto la prossima volta dove ci vedremo dal vivo!

Francesco Fontanarosa – Area Manager Centro Italia

Per me poter parlare direttamente ai partner in un evento come quello dei VoipDay è sempre un’esperienza importante. Vedere i nostri partner partecipi e vogliosi di sapere le novità VoipVoice è la riprova di un rapporto di collaborazione stretto e vincente, di questo ne vado fiero!

Matteo Martellacci – Area Manager Nord Est Italia

Il nuovo anno di VoipVoice è partito con gli appuntamenti online dei VoipDays, il tour virtuale in VoIP che ci ha portato, anche se a distanza, a incontrare tutti i partner sul territorio italiano. Personalmente sono molto contento delle mie regioni del Nord-Est Italia, che sono state molto produttive e presenti nonostante la situazione. Sono riusciti a sfruttare il settore che è fortemente in crescita e che permette di migliorare anche la condizione di vita dei clienti, offrendo servizi sempre più innovativi, che permettono di lavorare da remoto. Nonostante sia in contatto tutti i giorni con i partner, quando ci sono questi eventi provo sempre emozioni contrastanti: da una parte la felicità di poter condividere quelli che sono stati i risultati del 2020 e le novità che ci permettono di iniziare col botto il 2021, dall’altra una certa emozione per la responsabilità della gestione di un’area molto importante per noi e la responsabilità di fornire tutte le indicazioni relative alle novità dei listini e delle procedure.

Edoardo Ventrelli – Area Manager Nord Ovest Italia

Sono stato felice che abbiano partecipato molte persone all’evento e che sia stato un momento di confronto su quelle che sono le cose su cui poter migliorare, su cui basarsi per far leva sul cliente; sicuramente l’intervento di Mauro Bergamasco ha ribadito quello che è il concetto di squadra, di gruppo, cosa che per quanto possibile cerco sempre di trasmettere ai partner. Ovviamente non è mancato il momento conviviale con il Terzo tempo che ci ha permesso di brindare insieme e di far intervenire i presenti in video!

Un ringraziamento a tutti coloro che hanno partecipato a questi quattro appuntamenti della VoipDays Web Edition.

Qualora voleste risentire le novità presentate, o voleste riascoltare l’intervento di Mauro Bergamasco, potete scriverci a marketing@voipvoice.it, per richiederci le credenziali delle registrazioni.

Ai prossimi appuntamenti che, incrociando le dita, speriamo siano live!

Articolo scritto a cinque mani, a cura di Serena Masoni, Marketing Manager VoipVoice.

Siamo abituati a vendere o comprare Prodotti.

Invece dovremmo comprare Servizi.

Ed ecco l’idea: un Nuovo Servizio che sia un Prodotto.

VoipVoice lancia EASY SOLUTIONS!

Al posto di vendere Router, Cuffie e Telefoni IP li daremo come se fossero un servizio.

In bolletta!

La nostra azienda è da sempre un’azienda di Servizi.
Nata nel 2006 siamo nati come Provider VoIP.
Trattavamo solo Numeri Voip.
Abbiamo poi aggiunto servizio dopo servizio:

• Il VoipFax per inviare e ricevere tramite mail
• L’Adsl
• La Segreteria Telefonica
• La Fiber to the Cabinet
• La Fiber to the Home
• La Fibra Dedicata, realizzata su progetto
• La VoipAir, la Connettività Radio
• La VoipSim, la Connettività LTE
• La Business Continuity, il Backup su LTE

Lo scorso anno abbiamo presentato il VoipCloud, lo Spazio Cloud dedicato alle TLC.

Cominciamo questo 2021 con il botto.
Abbiamo aggiunto una scelta di Prodotti Professionali adatti al VoIP e alla Fibra.

Sono apparati spesso molto costosi.

Quando si cambia un centralino o realizzi un nuovo impianto si tratta di un investimento spesso da migliaia di euro.

VoipVoice invece permette di mettere questi prodotti in bolletta con un piccolo canone.  

Tre le soluzioni, tre Soluzioni Semplici.

Entry, Medium, Top.

Quattro Router, Sei Cuffie, Sei Telefoni.

Il Cliente avrà i seguenti Vantaggi:

1 – Avere sempre a disposizione il Top della gamma.

2 – Sostituire gli apparati se non funzionano, anche se non sono più in garanzia.

3 – L’Assistenza per Configurazione e Modifiche

Un Servizio importante per noi, per portare a casa dei nostri clienti la miglior Soluzione Tecnologica per il VoIP e la Fibra.

In un mondo che cambia in continuazione perché comprare un Prodotto?

Scegli un Servizio che ti garantisca le medesime funzioni di quel Prodotto.

A cura di Simone Terreni, Managing Director VoipVoice

Il rugby è uno sport che prevede il contatto fisico e il confronto fra i giocatori, ma ha anche un forte rispetto per l’avversario e i propri compagni di squadra. Avanzare, sostenere, passare la palla e continuare sono i principi cardine di questo sport, principi che possono essere riportati anche nella realtà lavorativa.  Questi sono gli stessi valori che la squadra di VoipVoice applica nel proprio lavoro e che vuole trasmettere alla propria rete di Partner.

Per parlare proprio del concetto di squadra, per capire quali sono le fasi dello sviluppo di un team e come poter formare una squadra di successo, abbiamo intervistato un campione del rugby: Mauro Bergamasco, classe 1979, allenatore di rugby a 15 ed  ex rugbista a 15 italiano nel ruolo di terza linea ala. Nella sua carriera ha vinto due scudetti con Benetton Treviso e due campionati francesi con lo Stade français ed è stato 106 volte internazionale per l’Italia, con la quale ha preso parte a cinque edizioni della Coppa del Mondo di rugby. UN RECORD!

Oggi Mauro si occupa non solo di allenare le nuove promesse del Rugby ma è anche un formatore, coach per aziende.

Ecco la sua intervista:

Il gioco è il lavoro dei bambini. A che età hai iniziato a giocare a rugby e come ti sei avvicinato a questo sport?
Il gioco è un opportunità per tutti, ad ogni età! Io ho iniziato a 4 anni, mio padre dopo la sua carriera era responsabile tecnico di un piccolo club in provincia di Padova, il Selvazzano Rugby. Quando tornava dal lavoro mi metteva in borsa e mi portava all’allenamento.

Qual era il tuo ruolo in campo? Avresti voluto far altro?
Il mio ruolo principale era quello del flanker, terza linea nel gruppo degli avanti. È un ruolo autonomo, libero nell’interpretazione del gioco e legato alla strategia di squadra. A supporto e a traino dei compagni di

squadra. Ho provato anche altri ruoli, e mi ci sono divertito, probabilmente il ruolo di terza linea. È quello che mi completava di più.

Quando pensiamo al rugby ci viene comunemente in mente uno sport duro, faticoso, basato sul gioco di squadra. Solo il lavoro di gruppo e il reciproco sostegno possono far raggiungere alla squadra la meta- Quali sono i principi cardine di questo gioco? Come possiamo applicarli nella quotidianità lavorativa?
Il rugby si fonda su 3 principi fondamentali: avanzare, mettere sotto pressione l’avversario e continuare ad avanzare. Credo che come in tutti i contesti, quello che ci fa fare la differenza sia la flessibilità di prendere concetti come questi e plasmarli nella nostra realtà. Non è cosa semplice, ma è la più bella!

Parliamo di competenze trasversali, quali sono gli insegnamenti che il rugby ti ha donato e che vuoi trasferire?
Da soli non si va da nessuna parte. Si può ed è importante scegliere i compagni di viaggio. La strada è comunque lunga e i pedaggi sono sempre dietro l’angolo.

Il Terzo Tempo nel Rugby è considerato un “rito sacro”. Cosa significa per te?
È un momento di condivisione e revisione delle relazioni. In campo è una storia, fuori i colori sono diversi! Il terzo tempo è leggenda, è tradizione e stile di vita!

Meta! Sudore, impegno, gioia e qualche graffio. Qual era la tua meta, il tuo obiettivo? Senti di averlo raggiunto?
Il mio obiettivo è sempre quello di essere pronto ad essere il migliore per ogni occasione. Ho sempre dato il massimo per me e per gli altri e questo è un obiettivo che solo ognuno di noi sa giudicare per se stesso. Io l’ho sempre fatto.

Nessuno si salva da solo – chi fa da sé fa per tre: quali di questi due detti senti essere più tuo, più appartenente alla tua filosofia di vita e perché?
HAHAHAHAH… Sono frasi che hanno fatto parte di me in momenti differenti della mia vita.

Allenare è un po’ come guidare un team: come si può riuscire a trasmettere la giusta motivazione?
La prima regola è essere integri. Essere se stessi e portare le proprie risorse a disposizione è il primo principio per rendersi parte di un progetto e proporre agli altri di farne parte con le stesse modalità e con gli stessi principi. Poi possiamo discutere di contenuti.

Mauro Bergamasco sarà nostro ospite durante tutta l’edizione online dei VoipDays per darci la giusta carica affinché, uniti, si possa dare una spinta al digitale in Italia!

A cura di Martina Giacomelli, Communication & Digital PR Manager