Blog
Il Protocollo SDP (Session Description Protocol) è definito dalla IETF mediante la RFC 4566. In genere questo protocollo viene inserito all’interno di un altro protocollo con lo scopo di definire i parametri per lo scambio dei flussi multimediali.
Una chiamata VoIP effettuata con il protocollo SIP utilizza, nel suo complesso altri protocolli oltre a quello SIP. In particolare, nel complesso di una chiamata VoIP SIP, dobbiamo sempre considerare almeno 4 protocolli che lavorano in sinergia tra di loro, per permettere l’esecuzione di una chiamata SIP:
- SIP (Session Initiation Protocol): avvia, modifica e conclude la chiamata.
- SDP (Session Description Protocol): definisce i parametri per lo scambio dei media (flussi audio o audio-video).
- RTP (Real time Transfer Protocol): si occupa dell’effettivo trasporto dell’audio o del video.
Il Protocollo SIP utilizza al proprio interno il protocollo SDP (Session Description Protocol) al fine di definire i parametri per lo scambio dei flussi multimediali tra due o più dispositivi (endpoint). Il protocollo SIP non si occupa quindi di trasportare fisicamente l’audio della chiamata. Esso delega al Protocollo SDP la definizione dei parametri di chiamata (IP, porta, codec audio utilizzati da ognuno dei due endpoint della chiamata).
Scopi del Protocollo SDP in ambito SIP
Nell’ambito del protocollo SIP, lo scopo del protocollo SDP in esso incapsulato, è quello di definire le informazioni per ciascuno dei due punti di comunicazione multimediale. Il protocollo SDP è presente nella sezione “body message” di alcuni messaggi SIP di richiesta e di risposta (Es. Invite, 183 e 200…). Le informazioni principali che vengono scambiate sono:
- L’indirizzo IP sul quale ciascuna parte si attende di ricevere il flusso multimediale
- La porta sulla quale ciascuna parte si attende di ricevere il flusso multimediale
- Il tipo di media che ciascuna parte si aspetta di ricevere. Tipicamente, in ambito SIP si tratta di audio
- La tipologia di protocollo con il quale ciascuna delle parti si aspetta di scambiare informazioni. In ambito SIP, lo scambio avviene tipicamente in SDP
- La tipologia di codec audio da impiegare per la compressione e la trasmissione.
La struttura del Protocollo SDP
Il protocollo SDP può essere suddiviso in tre parti. La prima parte annuncia i dettagli della sessione ed è denominata “Descrizione della sessione”; la seconda parte è denominata “Descrizione temporale” che annuncia i dettagli sui tempi relativi alla sessione; l’ultima parte è denominata “Descrizione dei media”, che comunica i dettagli sul media che verrà trasmesso in streaming in una determinata sessione annunciata. Di seguito è riportato un elenco delle sintassi comunemente utilizzate nel protocollo SDP
Descrizione della sessione
v= (versione del protocollo) o= (proprietario/creatore e identificativo di sessione). s= (nome dellasessione) i= (informazioni sulla sessione)* u= (URI di descrizione)* e=(indirizzo email – dettagli di contatto)* p= (numero di telefono – recapiti)* c= (informazioni sulla connessione - non richieste se incluse nella descrizione del supporto)* b= (informazioni sulla larghezza di banda della sessione)* z= (regolazioni fuso orario)* k= (chiave di crittografia)* a= (zero o più righe di attributo di sessione)*
Descrizione Temporale
t= (tempo in cui la sessione è attiva) r= (cicli di ripetizioni)*
Descrizione del Media
m= (nome del media/indirizzo di trasporto) i= (titolo del media)* c= (informazioni sulla connessione – non richieste se incluse nella descrizione della sessione)* b= (informazioni sulla larghezza di banda)* k= (chiave di crittografia)* a= (zero o più righe di attributi multimediali)*
* Campi opzionali
Significato e Descrizione dei singoli Campi impiegati nel Protocollo SDP
Descrizione della Sessione
- v=<versione> : specifica la versione del protocollo di descrizione della sessione. Come specificato nella RFC 4566, per il momento esiste una sola versione, ovvero la Versione 0. Non esistono versioni minori.
- o=<username><sess-id><sess-version><nettype><addrtype><unicast-address> Dettagli sull’originatore e identificazione della sessione.
<username> – Il login dell’utente. Il NON DEVE contenere spazi
<sess-id> – Una stringa numerica utilizzata come identificatore univoco per la sessione
<sess-version> – Una stringa numerica usata come numero di versione per questa descrizione della sessione
<nettype> – Stringa di testo, che specifica il tipo di rete, ad es. IN per internet
<addrtype> – Stringa di testo che specifica il tipo di indirizzo dell’originator EgIP4 o IP6
<unicast-address> – L’indirizzo della macchina da cui ha origine la sessione, che può essere sia l’FQDN che l’indirizzo IP. - s=<nome della sessione> – È possibile specificare un solo nome sessione per la descrizione della sessione. Non deve essere vuoto; pertanto, se non viene assegnato alcun nome alla sessione, è necessario utilizzare un singolo spazio vuoto come nome della sessione.
- i=<descrizione della sessione> – Nella descrizione della sessione è possibile specificare un solo campo “i” a livello di sessione. Il campo “i” può essere utilizzato nella sessione o nella descrizione dei media. È principalmente destinato all’etichettatura dei flussi multimediali quando viene utilizzato nella sezione di descrizione dei media. Può essere una descrizione leggibile dall’uomo.
- u=<uri> – L’URI (Uniform Resource Identifier) specificato nel campo “u”, è un puntatore a informazioni aggiuntive sulla sessione.
- e=<indirizzo email>
- p=<numero-telefono> – Specifica le informazioni di contatto per la persona responsabile della conferenza.
- c=<nettype> <addrtype> <connection-address> – Le informazioni sulla connessione possono essere incluse nella descrizione della sessione o nella descrizione del supporto. Una descrizione di sessione DEVE contenere almeno un campo “c=” in ogni descrizione media o un singolo campo “c=” a livello di sessione
<nettype> Una stringa di testo che descrive il tipo di rete, ad es. IN per internet.
<addrype> Una stringa di testo che descrive il tipo di indirizzo utilizzato in connection-address; Es. IP4 o IP6.
<connection-address> Viene specificato un indirizzo IP multicast incluso TTL, ad es. 235.2.36.42/127 - b=<bwtype>:<bandwidth> – Il campo Bandwidth può essere utilizzato sia nella descrizione della sessione, specificando la larghezza di banda totale dell’intera sessione, sia può essere utilizzato anche nella descrizione media, per sessione media.
<bwtype> Il tipo di larghezza di banda può essere CT; limite superiore totale della larghezza di banda da utilizzare per la conferenza, o AS; specifica dell’applicazione, quindi sarà il concetto dell’applicazione di larghezza di banda massima.
<bandwidth> viene interpretato come kilobit al secondo per impostazione predefinita. - z=<adjustment time> <offset> <ora di regolazione> <offset> – Per programmare una sessione ripetuta che specifica un passaggio dall’ora legale all’ora solare o viceversa, è necessario specificare la differenza dall’ora di origine.
- k=<metodo>:<chiave di crittografia> – Se il canale è sicuro e affidabile, è possibile utilizzare SDP per trasmettere le chiavi di crittografia. È possibile specificare una chiave per l’intera sessione o per ogni descrizione del supporto.
<method> Indica il meccanismo che viene utilizzato per ottenere la chiave di crittografia da fonti esterne o dalla codifica della chiave data. Esistono diversi metodi, come prompt e URI.
<encryption key> La chiave di crittografia o, se l’URI viene utilizzato come metodo, l’URI da cui è possibile recuperare la chiave.> - a=<attributo>:<valore> – Gli attributi possono essere definiti a “livello di sessione” o “livello multimediale” o entrambi. Gli attributi a livello di sessione vengono utilizzati per pubblicizzare informazioni aggiuntive che si applicano alla conferenza nel suo insieme. Gli attributi a livello di media sono specifici per i media, cioè informazioni pubblicitarie sul flusso di media.
Descrizione del Tempo
- t=<start-time>:<value> – Specifica gli orari di inizio e fine di una sessione. Se una sessione è attiva a intervalli irregolari, è possibile utilizzare più voci di tempo.
- r=<intervallo di ripetizione> <durata attiva> <offset da ora di inizio> – Se una sessione deve essere ripetuta a intervalli fissi, viene utilizzato il campo “r”. Di default tutti i valori dovrebbero essere specificati in secondi, ma per rendere la descrizione più compatta, il tempo può essere dato anche in unità diverse, come giorni, ore o minuti; es. r=6g 2h 14m.
Descrizione del Media
- m=<media> <port>/<number of ports> <proto> <fmt> – Questo campo viene utilizzato nella sezione della descrizione del supporto per pubblicizzare le proprietà del flusso multimediale, come la porta che utilizzerà per la trasmissione, il protocollo utilizzato per lo streaming e il formato o codec.
<media> Utilizzato per specificare il tipo di media, generalmente può essere audio, video, testo ecc.
<porta> La porta a cui verrà inviato il flusso multimediale. È inoltre possibile specificare più porte se viene utilizzata più di 1 porta.
<proto> Il protocollo di trasporto utilizzato per lo streaming, ad esempio RTP (protocollo in tempo reale).
<fmt> Il formato del supporto inviato, ad esempio in quale codec è codificato il supporto; ad es. PCMU, GSM ecc.
Per comprendere il Protocollo SIP è fondamentale partire dalle basi. Quando parliamo di Session Initiation Protocol (SIP) facciamo riferimento al protocollo di segnalazione utilizzato per controllare le sessioni di comunicazione di una chiamata VoIP.
Il Protocollo SIP è fondato sui messaggi SIP di richiesta e di risposta che sono descritti alla pagina 26 della RFC3261.
Il protocollo SIP è un protocollo basato su testo e utilizza il set di caratteri UTF-8. Un messaggio SIP può essere sia un messaggio di richiesta da un client verso un server che una risposta da un server verso il client stesso.
I messaggi SIP, sia di richiesta che di risposta, utilizzano uno schema comune di base anche se la sintassi può differire per i caratteri e per alcune specifiche. Tralasciando la codifica dei caratteri, la sintassi dei protocollo SIP è molto simile a quella dell’HTML/1.1, anche se il SIP non costituisce un’estensione del protocollo HTML.
Sia le richieste che le risposte SIP presentano una struttura di base comune, composta da:
- Start-Line: la linea iniziale di un messaggio SIP può essere una Request-Line o una Status-Line, a seconda che si tratti di un messaggio di richiesta o di risposta.
- Message-Header: è l’intestazione del messaggio che può essere composta da una o più campi/linee.
- Linea-Vuota: è sempre prevista, anche se il message-body non è presente oppure è vuoto.
- Message Body: è il corpo del messaggio. Può essere vuoto, contenere informazioni oppure contenere il protocollo SDP.
Sia la Start-Line che ogni linea di message-header, nonché la linea vuota, devono terminare con una sequenza CRLF (carriage-return line-feed sequence).
Nei prossimi paragrafi descriverò la classificazione dei messaggi di richiesta e di risposta SIP. Per agevolare gli eventuali approfondimenti, per ogni messaggio analizzato verranno indicati gli specifici link alle RFC di riferimento. Le specifiche del protocollo SIP coinvolgono numerosi documenti RFC di riferimento creati nel corso del tempo e la loro gerarchia non è sempre facile da ricostruire.
LE RICHIESTE SIP (Metodi)
I messaggi di richiesta SIP sono caratterizzati dal fatto di avere come linea iniziale una “Request-Line”.
La Request-Line contiene il nome del metodo, la Request-URI e la versione del protocollo. Ad esempio:
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:123456@trunk.voipvoice.it:5060 SIP/2.0
Method: INVITE
Request-URI: sip:123456@trunk.voipvoice.it:5060I metodi di richiesta SIP sono definiti dalle RFC SIP. I metodi fondamentali sono definiti direttamente all’interno della RFC3261 mentre altri medodi sono disciplinati come “estensioni” all’interno di altri specifici documenti RFC.
I 6 Metodi SIP fondamentali (RFC3261)
Questi 6 metodi di base sono previsti direttamente all’interno della RFC3261.
REGISTER
La registrazione comporta l’invio di una richiesta di registrazione verso un tipo speciale di User Agent Server (UAS) chiamato Registrar Server.
Un registrar funge da front-end al servizio di localizzazione per un dominio, leggendo e scrivendo mappature in base ai contenuti delle richieste di REGISTRAZIONE. Questo servizio di localizzazione viene quindi generalmente consultato da un server proxy responsabile dell’instradamento delle richieste per quel dominio.
INVITE e RE-INVITE
Quando uno User Agent Client (UAC) desidera avviare una sessione audio o audio/video, formula una richiesta INVITE. La richiesta di INVITE, domanda ad un server (UAS) di stabilire una sessione. Tale richiesta può essere inoltrata tramite deleghe , giungendo eventualmente ad uno o più UAS che potenzialmente possono accettare l’invito. Questi UAS dovranno spesso chiedere all’utente se accettare l’invito. Trascorso un certo lasso di tempo, gli UAS possono accettare l’invito (nel senso che accettano che la sessione possa essere stabilitala) attraverso un messaggio di risposta di tipo 2xx.
Se l’invito non viene accettato, viene inviata una risposta 3xx, 4xx, 5xx o 6xx, a seconda del motivo del rifiuto. Prima di inviare una risposta definitiva, l’UAS può anche inviare risposte provvisorie (1xx) per avvisare l’ UAC dell’andamento del contatto con l’utente chiamato.
Il Re-Invite corrisponde semplicemente ad una richiesta di modifica di un invite precedentemente trasmesso. Il Re-Invite non rappresenta quindi in metodo indipendente ma è un semplice invite di modifica. Questa modifica può comportare la modifica di indirizzi o porte oppure l’aggiunta di un flusso multimediale, l’eliminazione di un flusso multimediale e così via. Ciò si ottiene inviando una nuova richiesta INVITE all’interno della stessa finestra di dialogo che ha stabilito la sessione. Una richiesta INVITE inviata all’interno di una finestra di dialogo esistente è nota come re-INVITE.
Un esempio tipico di re-invite si presenta durante la trasmissione di un FAX in T38. In questo caso viene modificato l’attributo media da “audio” a “image” e contemporaneamente viene modificata la porte e l’indirizzo IP di trasmissione del flusso RTP.
ACK
Il protocollo SIP implementa un handshake a tre vie.
- Il chiamante invia un INVITE
- Il chiamato invia un 200 OK per accettare la chiamata
- Il chiamante invia un ACK per indicare che l’handshake è stato eseguita e che verrà quindi configurata una chiamata.
Se il primo messaggio INVITE include una descrizione della chiamata SDP (con le informazioni multimediali per avviare la sessione di chiamata audio) , il 200 OK conterrà anch’esso l’SDP del chiamato.
BYE
CANCEL
La richiesta CANCEL, come suggerisce il nome, viene utilizzata per cancellare una precedente richiesta inviata da un client. In particolare lo UAC, chiede all’UAS di cessare l’elaborazione della richiesta e di generare una risposta di errore a tale richiesta. CANCEL non ha effetto su una richiesta alla quale un UAS ha già dato una risposta definitiva.
Per questo motivo, è molto utile annullare le richieste alle quali un server può impiegare molto tempo per rispondere. Il metodo CANCEL rappresenta la soluzione migliore per le richieste di INVITE, che possono richiedere molto tempo per generare una risposta. In tale utilizzo, un UAS che riceve una richiesta CANCEL per un INVITE, ma non ha ancora inviato una risposta finale, “smetterà di squillare” e quindi risponderà all’INVITE con una risposta di errore specifica (487).
OPTIONS
Il metodo SIP OPTIONS consente a un UA di interrogare un altro UA o un server proxy in merito alle sue capacità. Ciò consente ad un client di scoprire informazioni sui metodi supportati, i tipi di contenuto, le estensioni, i codec e così via senza “squillare” l’altra parte.
Ad esempio, prima che un client inserisca un campo di intestazione Require in un INVITE che elenca un’opzione che non è certo che l’UAS di destinazione supporti, il client può interrogare l’UAS di destinazione con OPTIONS per vedere se questa opzione viene restituita in un campo di intestazione Supported.
Tutti gli UA devono supportare il metodo OPTIONS.
I Metodi SIP previsti come estensioni da altre specifiche RFC
Di seguito elenco i metodi SIP che non sono direttamente previsti all’interno della RFC3261 ma che sono stati introdotti come estensioni all’interno di successive RFC. Per ognuno di questi metodi è indicata la specirti
INFO (RFC2927)
L’intento del metodo INFO è di consentire il trasporto di informazioni di controllo relative alla sessione generate durante la sessione stessa. Un esempio di tali informazioni di controllo della sessione sono i messaggi di segnalazione ISUP e ISDN utilizzati per controllare i servizi di chiamata telefonica.
Il metodo INFO è anche stato utilizzato per la trasmissione dei toni DTMF anche se tale sistema è ormai sconsigliato dalle RFC stesse.
MESSAGE (RFC3428)
La messaggistica istantanea (IM) si riferisce al trasferimento di messaggi tra utenti in tempo quasi-reale. Questi messaggi sono generalmente, ma non necessariamente, brevi. I messaggi istantanei vengono spesso utilizzati in modalità conversazionale, ovvero il trasferimento dei messaggi avanti e indietro è sufficientemente veloce da consentire ai partecipanti di mantenere una conversazione interattiva.
Il metodo MESSAGE è un’estensione del Session Initiation Protocol (SIP) che consente il trasferimento di messaggi istantanei. Poiché la richiesta MESSAGE è un’estensione di SIP, eredita tutte le funzionalità di routing e sicurezza delle richieste di quel protocollo. Le richieste MESSAGE trasportano il contenuto sotto forma di parti del corpo MIME. Le richieste MESSAGE non avviano esse stesse un dialogo SIP. In condizioni di utilizzo normale, ogni messaggio istantaneo è autonomo, proprio come i messaggi cercapersone. Le richieste di MESSAGGE possono essere inviate nel contesto di un dialogo avviato da qualche altra richiesta SIP.
NOTIFY (RFC2848)
Durante il periodo di sottoscrizione, il Gateway può, di volta in volta, inviare una richiesta di NOTIFY spontanea al soggetto indicato nell’header “Contact”. Normalmente ciò avverrà a seguito di qualsiasi modifica dello stato della sessione di servizio per la quale il richiedente si è iscritto. NOTIFY in genere funziona in abbinamento alla richiesta di SUBSCRIVE (vedi sotto).
Lo UAS ricevente deve riconoscere questo restituendo una risposta finale (normalmente un “200 OK”). In questa versione delle estensioni PINT, il gateway non è tenuto a supportare le risposte di reindirizzamento (codici 3xx) e potrebbe quindi trattarli come un errore.
Pertanto, se la classe del codice di risposta è superiore a 2xx, ciò può essere considerato dal gateway come un errore della sessione di monitoraggio e, in tale situazione, tenterà immediatamente di chiudere la sessione (vedere di seguito).
PRACK (RFC3262)
Il metodo PRACK è definito nella RFC 3262: “Affidabilità delle risposte provvisorie nel protocollo SIP (Session Initiation Protocol)”
La richiesta PRACK svolge lo stesso ruolo dell’ACK , ma per le risposte provvisorie. C’è però una differenza importante. PRACK è un normale messaggio SIP, come BYE. In quanto tale, la sua affidabilità è garantita hop-by-hop attraverso ogni proxy stateful. Proprio come il BYE , ma a differenza di ACK, il PRACK ha la sua risposta. In caso contrario, il messaggio PRACK non potrebbe attraversare i server proxy conformi a RFC 2543.
L’implementazione del PRACK presenta ancora oggi numerosi problemi di compatibilità
PUBLISH (RFC3903)
REFER (RFC3515)
Il metodo SIP REFER è principalmente impiegato per i trasferimenti di chiamata ma può essere impiegato per molte altre applicazioni. Il soggetto che invisa il refer deve essere informato circa l’esito della richiesta di riferimento.
SUBSCRIBE (RFC2848)
Quando una richiesta SUBSCRIBE viene inviata a un server PINT, indica che un utente desidera ricevere informazioni sullo stato di una sessione di servizio. La richiesta identifica la sessione di interesse includendo la descrizione della sessione originale insieme alla richiesta, utilizzando l’ ID di sessione globale SDP che fa parte del campo origine per identificare in modo univoco la sessione di servizio.
La richiesta SUBSCRIBE (come qualsiasi altra richiesta SIP su una sessione in corso) viene inviata allo stesso server in cui è stato inviato l’ INVITE originale , o ad un server che è stato specificato nel campo Contact all’interno di una risposta successiva (questo potrebbe essere il PINT gateway per la sessione).
UNSUBSCRIVE (RFC2848)
Questo metodo consente di terminare una sessione di monitoraggio. Ciò si ottiene inviando una richiesta UNSUBSCRIBE al server corrispondente. Tale richiesta indica che il mittente intende chiudere immediatamente la sessione di monitoraggio e, al ricevimento della risposta finale dal server ricevente, la sessione si considera conclusa.
UPDATE (RFC3311)
UPDATE consente a un client di aggiornare i parametri di una sessione (come l’insieme di flussi multimediali e i relativi codec) ma non ha alcun impatto sullo stato di una finestra di dialogo. In questo senso, è come un re-INVITE , ma a differenza di re-INVITE, può essere inviato prima che l’ INVITE iniziale sia stato completato. Ciò lo rende molto utile per l’aggiornamento dei parametri di sessione all’interno delle prime finestre di dialogo.
LE RISPOSTE SIP (Codici)
I messaggi di risposta SIP sono caratterizzati dal fatto di avere come linea iniziale una “Status-Line”.
Una Status-Line contiene la Versione del protocollo seguita da uno Status-Code numerico e dalla frase testuale associata (Reason-Phrase). Ad esempio:
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Status-Code: 200Lo Status-Code è un codice risultato intero a 3 cifre che indica il risultato di un tentativo di comprendere e soddisfare una richiesta. La frase di motivazione (reason-phrase) ha lo scopo di fornire una breve descrizione testuale del Codice di stato. Lo Status-Code è destinato all’uso da parte di sistemi automatici, mentre la frase di motivazione è destinata all’utente umano. Per un client non è quindi necessario visualizzare la frase di motivazione.
La prima cifra dello Status-Code definisce la classe di risposta. Le ultime due cifre non hanno alcun ruolo di categorizzazione. Per questo motivo, qualsiasi risposta con un codice di stato compreso tra 100 e 199 è indicata come “risposta 1xx”, qualsiasi risposta con un codice di stato tra 200 e 299 come “risposta 2xx” e così via. Il protocollo SIP/2.0 consente sei valori per la prima cifra:
1xx: Risposte Provvisorie e Informative — conferma della richiesta ricevuta, richiesta in elaborazione.
2xx: Risposte Definitive, di Successo: l’azione è stata ricevuta con successo, è stata compresa, e accettata.
3xx: Risposte di Reindirizzamento — è necessario intraprendere ulteriori azioni per completare la richiesta;
4xx: Errori o segnalazioni del Client — la richiesta contiene una sintassi errata o non può essere soddisfatte su questo server;
5xx: Errori o segnalazioni del Server — il server non è riuscito a soddisfare un apparentemente richiesta valida;
6xx: Errori globali: la richiesta non può essere soddisfatta in nessun caso server.
Elenco dei Codici di Risposta SIP conosciuti (per classi)
1xx Risposte Provvisorie e Informative
- 100 Trying – La ricerca estesa è in corso, quindi un forking proxy deve inviare una 100 risposte.
- 180 Ringing – L’User Agent di destinazione ha ricevuto il messaggio d’INVITO e sta avvisando l’utente della chiamata.
- 181 Call Is Being Forwarded – Opzionale, inviato dal Server per indicare che una chiamata è in corso di inoltro.
- 182 Queued – La destinazione non era temporaneamente disponibile, il server ha messo in coda la chiamata fino a quando la destinazione non è disponibile.
- 183 Session Progress – Questa risposta può essere utilizzata per inviare informazioni aggiuntive per una chiamata che è ancora in fase di set up.
- 199 Early Dialog Terminated – Invio da parte del server User Agent per indicare che un dialogo precedente è stato interrotto.
2xx Risposte Definitive, di Successo
- 200 OK – Mostra che la richiesta ha avuto successo.
- 202 accepted – Indica che la richiesta è stata accettata. Principalmente usato per referenze
- 204 No Notification – Indica che la richiesta è stata accolta ma che non verrà ricevuta alcuna risposta.
3xx: Risposte di Reindirizzamento
- 300 Multiple Choices – L’indirizzo risolto a una delle diverse opzioni tra cui l’utente o il cliente può scegliere.
- 301 Moved Permanently – L’URI della Richiesta originale non è più valido, il nuovo indirizzo viene indicato nell’intestazione del Contatto.
- 302 Moved Temporarily – Il cliente deve provare l’indirizzo nel campo Contatto.
- 305 Use Proxy – Il campo Contatto indica un proxy che deve essere utilizzato per accedere alla destinazione richiesta.
- 380 Alternative Service – La chiamata non è riuscita, ma le alternative sono dettagliate nel corpo del messaggio.
4xx: Errori o segnalazioni del Client
- 400 Bad Request – La richiesta non è stata interpretata a causa della sintassi malformata.401 Unauthorized – La richiesta richiede l’autenticazione dell’utente. Questa risposta è emessa da UAS e registrars.
- 402 Payment Required – (Riservato per uso futuro).
- 403 Forbidden – Il server ha compreso la richiesta, ma si rifiuta di svolgerla.
- 404 Not Found – Il server ha informazioni definitive che l’utente non esiste presso il (User not found).
- 405 Method Not Allowed – Il metodo specificato nella Request-Line è compreso, ma non è consentito.
- 406 Not Acceptable – La risorsa è in grado di generare solo risposte con contenuto inaccettabile.
- 407 Proxy Authentication Required – La richiesta richiede l’autenticazione dell’utente.
- 408 Request Timeout – Non è stato possibile trovare l’utente in tempo.
- 409 Conflict – Utente già registrato (decaduto).
- 410 Gone – L’utente esisteva una volta, ma non è più disponibile.
- 411 Length Required – Il server non accetterà la richiesta senza una lunghezza di contenuto valida (decaduto).
- 412 Conditional Request Failed – Il prerequisito dato non è stato trovato.
- 413 Request Entity Too Large – Richiesta corpo troppo grande.
- 414 Request URI Too Long – Il server rifiuta il servizio della richiesta, il Req-URI è più lungo di quanto il server possa interpretare.
- 415 Unsupported Media Type – Il corpo della richiesta è in un formato non supportato.
- 416 Unsupported URI Scheme – Il Request-URI è sconosciuto al server.
- 417 Unknown Resource-Priority – C’era un tag di opzione Resource-Priority, ma nessuna intestazione Resource-Priority.
- 420 Bad Extension – Cattiva estensione del protocollo SIP utilizzato, non compreso dal server.
- 421 Extension Required – Il server necessita di una specifica estensione non elencata nell’intestazione Supportata.
- 422 Session Interval Too Small – La richiesta contiene un campo di intestazione Session-Expires con una durata inferiore al minimo.
- 423 Interval Too Brief – Il tempo di scadenza della risorsa è troppo breve.
- 424 Bad Location Information – Il contenuto della richiesta è stato malformato o comunque insoddisfacente.
- 428 Use Identity Header – Il criterio del server richiede un’intestazione di Identità e non è stato fornito.
- 429 Provide Referrer Identity – Il server non ha ricevuto un token Referred-By valido sulla richiesta.
- 430 Flow Failed – Un flusso specifico verso un agente utente non è riuscito, anche se altri flussi possono avere successo.
- 433 Anonymity Disallowed – La richiesta è stata respinta perché anonima.
- 436 Bad Identity Info – La richiesta ha un’intestazione Identity-Info e lo schema URI contenuto non può essere deselezionato.
- 437 Unsupported Certificate – Il server non è stato in grado di convalidare un certificato per il dominio che ha firmato la richiesta.
- 438 Invalid Identity Header – Il server ha ottenuto un certificato valido utilizzato per firmare una richiesta, non è stato in grado di verificare la firma.
- 439 First Hop Lacks Outbound Support – Il primo proxy in uscita non supporta la funzione “outbound”.
- 440 Max-Breadth Exceeded – Se un proxy SIP ha determinato un contesto di risposta non aveva un Max-Breadth in entrata sufficiente per effettuare un fork parallelo desiderato, e il proxy non è in grado di compensare biforcando in serie o inviando un redirect, quel proxy DEVE restituire una risposta 440. Un cliente che riceve una risposta 440 può dedurre che la sua richiesta non ha raggiunto tutte le destinazioni possibili.
- 469 Bad Info Package – Se un SIP UA riceve una richiesta INFO associata a un Info Package che l’UA non ha indicato la volontà di ricevere, l’UA DEVE inviare una risposta 469, che contiene un campo di intestazione Recv-Info con i Pacchetti Info per i quali l’UA è disposta a ricevere richieste INFO.
- 470 Consent Needed – La fonte della richiesta non aveva il permesso del destinatario per effettuare tale richiesta.
- 480 Temporarily Unavailable – Chiamata attualmente non disponibile.
- 481 Call/Transaction Does Not Exist – Il server ha ricevuto una richiesta che non corrisponde a nessun dialogo o transazione.
- 482 Loop Detected – Il server ha rilevato un loop.
- 483 Too Many Hops – L’intestazione Max-Forwards ha raggiunto il valore ‘0’.
- 484 Address Incomplete – Richiesta-URI incompleta.
- 485 Ambiguous – Request-URI è incompleto.
- 486 Busy Here – La linea è occupata.
- 487 Request Terminated – La richiesta è terminata per bye o cancella.
- 488 Not Acceptable Here – Alcuni aspetti della descrizione della sessione del Request-URI non sono accettabili.
- 489 Bad Event – Il server non ha compreso un pacchetto di eventi specificato in un campo di intestazione dell’evento.
- 491 Request Pending – Il server ha qualche richiesta in sospeso dalla stessa finestra di dialogo.
- 493 Undecipherable – La richiesta non decifrabile contiene un corpo MIME criptato, che il destinatario non può decifrare.
- 494 Security Agreement Required – Il server ha ricevuto una richiesta che richiede un meccanismo di sicurezza negoziato.
5xx: Errori o segnalazioni del Server
- 500 Server Internal Error – Il server non ha potuto soddisfare la richiesta a causa di alcune condizioni impreviste.
- 501 Not Implemented – Il metodo di richiesta SIP non è implementato qui.
- 502 Bad Gateway – Il server, ha ricevuto una risposta non valida da un server a valle mentre cercava di soddisfare una richiesta.
- 503 Service Unavailable – Il server è in manutenzione o è temporaneamente sovraccaricato e non può elaborare la richiesta.
- 504 Server Time-out – Il server ha tentato di accedere ad un altro server mentre cercava di elaborare una richiesta, nessuna risposta tempestiva.
- 505 Version Not Supported – La versione del protocollo SIP nella richiesta non è supportata dal server.
- 513 Message Too Large – La lunghezza del messaggio della richiesta è più lunga di quanto il server possa elaborare.
- 555 Push Notification Service Not Supported – Il server non supporta il servizio di notifica push specificato nel parametro pn-provider SIP URI.
- 580 Precondition Failure – Il server non è in grado o non vuole rispettare alcuni vincoli specificati nell’offerta.
6xx: Errori globali
- 600 Busy Everywhere – Tutte le destinazioni possibili sono occupate.
- 603 Decline – La destinazione non può/non vuole partecipare alla chiamata, non ci sono destinazioni alternative.
- 604 Does Not Exist Anywhere – Il server ha l’informazione ufficiale che l’utente richiesto non esiste da nessuna parte.
- 606 Not Acceptable – L’agente dell’utente è stato contattato con successo, ma alcuni aspetti della descrizione della sessione non erano accettabili.
- 607 Unwanted – La parte chiamata non voleva che la sua chiamata venisse effettuata dalla parte chiamante. I futuri tentativi da parte del chiamante saranno probabilmente respinti in modo analogo.
Cos’è un Jitter Buffer?
Il jitter misura la variazione del tempo impiegato dai pacchetti di dati audio per raggiungere la loro destinazione. I pacchetti di dati inviati dalla stessa fonte non vengono sempre trasmessi alla stessa velocità, quindi non sempre raggiungono il destinatario a intervalli regolari. Quello che accade, in termini pratici, è che i pacchetti dati audio giungeranno a destinazione con un’ordine diverso rispetto all’ordine cronologico con il quale sono partiti. Ciò può causare un audio discontinuo o distorto con un effetto etichettato generalmente come “metallico” o “robotico”.
Un jitter buffer è un’area dati condivisa in cui i dati audio vengono temporaneamente raccolti e archiviati durante una chiamata VoIP (Voice over Internet Protocol) prima di essere inviati al destinatario. Esso aiuta a migliorare la qualità delle chiamate vocali riducendo l’effetto distorsivo del jitter.
Esistono due tipi principali di jitter buffer: statico e dinamico. Come suggerisce il nome, un jitter buffer statico è un buffer di dimensione fissa, mentre uno dinamico si adatta alle condizioni attuali della rete.
Come funziona un buffer di Jitter?
Quando vengono effettuate le chiamate VoIP, i dati audio vengono trasferiti in piccoli segmenti, chiamati pacchetti. A causa delle mutevoli condizioni della rete, questi pacchetti potrebbero essere trasmessi a velocità diverse, anche se provengono dalla stessa fonte. La differenza tra l’orario di arrivo previsto di ciascun pacchetto è il “jitter”.
Per la maggior parte delle attività di rete, la variazione dei tempi di arrivo dei pacchetti non comporta molti problemi. Ma se l’attività consiste in una comunicazione in tempo reale (come livestreaming o videochiamate), il jitter comporta che il destinatario della chiamata si ritrovi con l’audio discontinuo o degradato.
Un jitter buffer aiuta a livellare il jitter per migliorare la qualità audio per il destinatario. Esso ritarda volutamente la consegna dei pacchetti e memorizza i pacchetti di dati in entrata prima di inviarli al destinatario. Il ritardo è normalmente impercettibile, una frazione di secondo. Il Jitter buffer aggiungere quindi un piccolo ritardo nella conversazione ma aiuta a rendere più fluido l’audio e a offrire un’esperienza migliore. Il valore di Jitter buffer è generalmente impostabile con valori fino a 150ms.
Un Jitter Buffer di tipo fisso manterrà il ritardo costante per tutto il tempo, quindi se le condizioni della rete peggiorano oppure oscillano, il destinatario potrebbe comunque riscontrare problemi audio. Un jitter buffer dinamico o adattivo monitora le condizioni sperimentate durante il trasferimento dei pacchetti vocali più recenti e riduce o aumenta la dimensione del buffer aseconda delle necessità.
Perché un jitter Buffer è importante per le comunicazioni in tempo reale
Un jitter buffer aiuta a migliorare la qualità audio e video anche quando i destinatari non possono apportare altri miglioramenti alle condizioni della propria rete, ad esempio aggiornando o cambiando la propria connettività Internet o utilizzando una connettività cablata piuttosto che una Wi-Fi o 4G/gG. Offre tre vantaggi principali:
- Migliora la qualità audio: i destinatari della comunicazione possono migliorare la qualità dell’audio e del video che ricevono attivando il jitter buffer nel prodotto.
- Rende le chiamate via Internet più affidabili: i destinatari riescono comunque a ricevere comunicazioni in tempo reale anche quando il segnale Wi-Fi è presenta jitter dovuto alla congestione di rete.
- Permette di prevenire anche le sporadiche anomalie della rete dovute a congestione della rete esterna.
- In abbinamento ad una buona gestione del QoS permette di prevedere una soluzione alle condizioni operative più sfavorevoli.
Quando utilizzare un jitter buffer
Un jitter buffer può migliorare l’esperienza degli utenti nell’utilizzo di un prodotto di telefonia o di un PBX VoIP. E’ bene però chiarire che esso non risolverà mai eventuali problemi causati dall’errata scelta del router o dalla connessione Internet. In particolare occorre precisare che le congestioni interne alla rete LAN, in un contesto professionale, devono sempre essere superate attraverso l’impiego di un oppurtuno algoritmo di gestione del QoS a i livello di routing e switching.
Congestione interna della rete
La congestione interna della rete si verifica quando più utenti e dispositivi utilizzano la stessa connessione di rete. Nella maggior parte dei casi la rete riesce a supportare bene più attività concorrenti ma se gli utenti svolgono attività che richiedono ampiezza di banda molto elevate, come effettuare videochiamate o caricare file di grandissime dimensioni, allo stesso tempo, la velocità diminuirà e si verrà a creare jitter.
Ciò considerato, se il sistema VoIP è rivolto a un’utenza aziendale professionale, disporre di una gestione accurata del QoS e disporre di un jitter buffer, sarà utilizzimo per conservare la qualità audio della chiamata.
Segnale Wi-Fi scarso
Si è in condizioni di segnale Wi-Fi scarso quando non si dispone di una copertura sufficientemente ampia all’interno dell’ufficio. In alternativa, gli utenti possono avere problemi con un segnale debole anche quando fanno affidamento sul Wi-Fi pubblico, ad esempio se utilizzano il tuo prodotto mentre sono in movimento.
L’impiego di una jitter può essere molto utile in questi casi ma non bisogna attendersi miracoli. Se l’infrastruttura Wi-Fi non è ottimizzata per la gestione del VoIP è sempre preferibile sostituirla con una pensata e ottimizzata per le moderne UC.
Attività ad elevata larghezza di banda
Se le attività aziendali prevedono un impiego elevatpo della banda internet in condizioni quali lo scambio di file di grandi dimensioni verso il cloud o lo strem di contenuti audio/video con qualità elevate, l’impiego del jitter buffer costituisce un’aggiunta preziosa.
Dove configurare il Jitter Buffer
Generalmente la funzionalità di Jitter buffer può essere disponibile a più livelli e può essere disponibile sia all’interno dei dispositivi telefonici VoIP SIP che degli stessi PBX. La prima raccomandazione è quella di evitare la sovrapposizione di più livelli di buffering. E’ generalmente consigliato l’attivazione della funzionalità direttamente sui telefoni IP piuttosto che sul PBX. E’ altresi consigliabile l’impiego di un sistema dinamico di gestione del buffer che consenta di introdurre latenza al fine di compensare il jitter, solo in caso di effettiva necessità.
FQDN e Centralini VoIP on Premise
Una delle esigenze legate all’implementazione di un moderno sistema di comunicazione unificata in cloud, consiste nella doppia risoluzione dell’FQDN relativo al PBX sulle due interfacce di rete con il quale lo stesso si interfaccia con la WAN (Internet) e la LAN.
Vi è infatti la necessità di provvedere a risolvere il nome a dominio\ (FQDN) del PBX in modalità diversa a seconda che il PBX sia interrogato dai dispositivi locali, presenti all’interno della rete (LAN), piuttosto che dagli interni remotizzati e dai client SIP/WEBRTC che accedono al PBX attraverso internet.
I dispositivi interni alla rete LAN dovranno infatti indirizzare il dialoghi SIP verso un IP locale, quale ad esempio 192.168.x.x, per dialogare con il centralino. I client remoti, diversamente da quelli locali, dovranno invece indirizzare le richieste verso un indirizzo IP pubblico quale 182.180.x.x
Supponendo che l’FQDN attribuito al PBX sia centralino.azienda.it dovrà realizzarsi la seguente situazione affinché il PBX possa essere correttamente fruibile a livello DNS:
- Per richieste Interne alla LAN: i client che puntano a centralino.azienda.it dovranno essere indirizzati all’IP 192.168.x.x
- Per richieste Esterne alla LAN: i client che puntano a centralino.azienda.it dovranno essere indirizzati all’IP 182.180.x.x
Come è possibile ottenere facilmente questo risultato nelle piccole realtà aziendali in cui non è presente un server DNS interno?
La Funzionalità di LAN DNS sui Router
I router Draytek Vigor 28xx e 29xx presenti all’interno del servizio Easy Solutions Router di VoipVoice, consentono di fruire di un servizio di reindirizzamento delle richieste che puntano ad uno specifico nome dominio.
L’applicazione presente all’interno del menu [Applicazioni] > [LAN DNS] consentono al router di tracciare specifiche richieste di nomi di dominio e indirizzarle verso un profilo configurato localmente invece di inoltrare la query a un server DNS esterno.
Questa funzionalità consente di assolvere a pieno all’esigenza di un PBX installato localmente che abbia la necessità di essere raggiunto sia da telefoni IP locali che remotizzati.
Le impostazioni LAN DNS configurate influenzeranno tutte le ricerche DNS, purché la query DNS passi attraverso il router come gateway.
Il servizio può anche essere impostato per modificare il DNS solo per i client nella stessa subnet.
Sui modelli Draytek Vigor 2865 e 2927, il nome di dominio specificato può utilizzare anche un carattere jolly . Per fare un esempio www.azienda.* potrebbe essere utilizzato per influenzare le ricerche DNS per tutti i diversi domini nazionali (domini di primo livello) senza bisogno di un DNS LAN separato per ciascun profilo.
Come procedere alla Configurazione Split DNS
- Vai su [Applicazioni] > [LAN DNS /DNS Forwarding] e seleziona il primo index disponibile (es. 1).
procedere inserendo:
Profile: Nome del profilo, solo per riferimento
Type: Selezionare “LAN DNS”
Domain Name: Il nome di dominio che verrà filtrato. E’ anche possibile utilizzare la wilcard *. Per il nostro esempio inseriremo: centralino.azienda.it
IP Address List: Ogni voce creerà un record A (Record di indirizzo) per il nome di dominio. Nel nostro caso inseriremo l’indirizzo IP locale del PBX. Es. 192.168.1.140 - Per aggiungere un record A nella IP address listi, fare clic sul pulsante Add . Inserire l’indirizzo IP del PBX.
- Assicurati che il profilo sia impostato su “Enable”
A questo punto potrete testare sul browser la corretta funzionalità del filtro, digitando l’fqdn indicato e verificando che la richiesta venga indirizzata all’IP locale selezionato.
È sempre più conosciuta la differenza tra FTTC e FTTH, negli ultimi anni, in riferimento a quest’ultima abbiamo assisto a vere e proprie evoluzioni.
Già ad oggi, si parla e discute della prossima frontiera il 10 Gbps, ma in attesa di questo facciamo un piccolo focus sui nuovi profili FTTH con download massimo fino a 2,5Gbps.
Lo dice il nome stesso, si tratta di nuove connettività FTTH (Fiber to the Home) che sfruttano la tecnologia in Fibra Ottica per raggiungere una velocità massima nominale di 2,5 Gbps in Download
Per quanto concerne le specifiche di upload e la banda minima garantita, sono disponibili due differenti profili:
- La nuova “NEXT FTTH” 2,5 Gb con upload fino a 1 Gbps e BMG pari a 100/50 Mbps su vettore TIM
- La nuova “GIGA FIBER Senna” con upload fino a 500 Mbps e BMG pari a 40/20 Mbps su vettore Open Fiber
L’INFRASTRUTTURA – FTTH
Esistono differenti standard di rete per le tecnologie in FTTH: GPON, EPON e XGS-PON.
Cosa li differenzia l’un l’altro?
GPON (Gigabit Passive Optical Netwok) è lo standard maggiormente utilizzato in Italia e sfrutta un tipo di rete PON.
Una rete PON (Passive Optical Netwok) è un’infrastruttura punto-multipunto composta da un OLT (Optical Line Terminal) che diffonde la banda tramite split ottico, non alimentato (rendendo così passiva la rete), fino alla terminazione in sede, meglio conosciuto come ONT.
Si tratta di una banda condivisa perché la banda erogata dall’OLT per ogni Fibra Ottica è di 2,5 Gbps massimi in Download e 1,25 Gbps massimi in Upload, suddivisa per ogni utenza. Il numero massimo di utenze massimo raggiungibili sull’albero di rete è generalmente di 64.
Nell’ultimo periodo però le istituzioni hanno posto come limite massimo, quello di 16 utenze per tutte le infrastrutture realizzate mediante pubblico contributo.
EPON (Ethernet Passive Optical Netwok) è un’infrastruttura, presente in Italia ma maggiormente diffusa in Asia. Sfrutta anch’essa una rete PON, la differenza sostanziale è la velocità di erogata per singola fibra ottica, ovvero 10 Gbps in Download e 1 Gbps in Upload.
XGS-PON è l’evoluzione, in fase di sviluppo, delle attuali infrastrutture GPON. Permette di raggiungere velocità fino a 10 Gbps simmetrici e di erogare servizi con diversi profili di prestazione.
A COSA PORRE ATTENZIONE? A CHE CONTESTO SI ADATTA?
Le connettività a 2,5Gbps si adattano sia a contesti Business che Home.
Vorrei invitarvi a porre attenzione su alcuni aspetti importati. Siamo generalmente abituati a confrontarci con velocità a 1 Gbps, o inferiori. Ad oggi, sul mercato sono presenti router che riescono a gestire i 2,5 Gbps, sulle interfacce WAN. E’ però necessario riflettere sul come distribuire la banda dati all’interno della rete aziendale o dell’abitazione.
La maggior parte delle porte LAN dei router, degli switch e delle schede di rete dei PC, utilizzano interfacce ethernet con velocità pari a 1 Gbps. Anche con il più recente WiFi 6, la velocità massima raggiungibile con un dispositivo client è di circa 1,2 Gbps.
Qual è quindi il reale vantaggio di avere a disposizione una connettività FTTH a 2,5 Gbps?
La banda media disponibile per ogni singolo host è nel complesso superiore.
Anche se la banda di picco non è complessivamente fruibile per ogni singola postazione, i vantaggi per un’utenza business sono comunque molto evidenti.
A livello di scenario complessivo, bisogna inoltre ricordare che le reti FTTH GPON godono di un’affidabilità maggiore delle FTTC, in virtù della loro diramazione ottica completamente passiva, che prevede apparati attivi solo ai capi estremi della rete.
Come si configura un account sip VoipVoice con un telefono Yealink avendo cura di utilizzare tutti gli accorgimenti possibili per superare le barriere di NAT e i relativi problemi?
Abbiamo già avuto modo in passato di parlare dei requisiti di NAT per evitare i problemi di funzionamento nell’ambito del VoIP SIP. Abbiamo analizzato nel dettaglio lo specifico comportamento a livello di compatibilità del VoIP SIP con le varie tipologie di NAT. Abbiamo inoltre presentato gli strumenti e le tecniche utilizzabili per superare le eventuali problematiche relativi alle telefonate VoIP. Potete leggere il relativo approfondimento e tutte le considerazioni tecniche cliccando qui.
Oggi proviamo a soffermarci sugli aspetti pratici e operativi legati alla configurazione di un telefono IP con un account SIP di telefonia fornito da VoipVoice. Per illustrare come procedere abbiamo preso come riferimento un telefono IP prodotto da Yealink e ricompreso all’interno dell’offerta Easy Solutions Phone di VoipVoicve. Si tratta nello specifico del modello T46U di Yealink ma tutte le configurazioni proposte sono riproducibili sull’intera gamma dei telefoni prodotti da quato marchio.
L’obiettivo è quello di configurare opportunamente i tre strumenti principali che ci possono consentire su superare gli ostacoli di NAT e di garantire un’ottima stabilità operativa anche in assenza di specifiche regole di NAT statico per il corretto funzionamento del protocollo SIP e del flusso bidirezionale della chiamata audio RTP.
Vediamo quindi come quali sono gli elementi da configurare
1. Configurazione SIP di Base per il Telefono Yealink
La partre più semplice della configurazione consiste nell’inserimento delle credenziali di autenticazione e del register server nell’interfaccia del telefono. Nell’esempio seguente riportiamo i dati relativi ad un account voipvoice su dominio user.voipvoice.it
Procediamo come nell’immagine seguente accedendo al menu Account -> Register -> Account1 (selezionamo uno degli account disponibili):
Inseriamo i dati come da immagine avendo cura di differenziare lo username dal register name nel caso in cui nell’email di attivazione vengano riportate credenziali distinte.
Nel campo relativo al server di registrazione (Server Host) andrà indicato il dominio indicato nella mail di attivazione. Nel nostro caso user.voipvoice.it.
Come tipologia di trasporto SIP indicheremo UDP, mentre come tempo di scadenza della registrazione SIP (Server Expires) indicheremo il valore di 120 secondi.
In questa fase, nonostante l’immissione delle credenziali, potrebbe essere che il telefono non riesca comunque ad effettuare la registrazione. In alcune situazioni specifiche di NAT è possibile che la registrazione non avvenga fintanto che non saranno completate le operazioni previste al punto 3 di questa guida.
2. Configurazione dei codec Audio
La configurazione relativa ai codec audio si effetua dal menu Account -> Codec -> Account1 (selezionamo lo stesso account utilizzato per la configurazione precedente). Suggeriamo di abilitare solamente i codec G711A e G7129. Per chi si trovasse ad installare il telefono in una situazione in cui la banda disponibile è limitata, si suggerisce di abilitare solo il codec G729 che occupa solo 33Kbps contro i circa 88Kbps del codec G711A.
3. Configurazione dei meccanismi di superamento delle barriere di NAT
Configurazione del server Stun
La prima operazione relativa al NAT consiste nella configurazione del server STUN e della sua abilitazione. Il server stun consente al telefono di utilizzare all’interno dei messaggi SIP l’indirizzo IP pubblico al posto di quello privato e la corretta porta SIP pubblica.
Accedere al menu Network -> NAT e configurare i campi come segue:
Alla voce STUN configurare i campi “Active” su Enabled e il campo “STUN Server” con stun.voipvoice.it. La “STUN Port” da indicare sarà la 3478. Lasciare invariati gli altri parametri di questa pagina.
Attivazione del Server Stun per l’Account
Successivamente alla configurazione del server STUN sarà necessario abilitarlo per lo specifico account che stiamo configurando. Sarà quindi necessario tornare al menu Account -> Register -> Account1 per configurare l’ultima opzione presente in fondo alla pagina, per attivare la funzione di STUN per questo account.
Alla voce “NAT” a fondo pagina, selezionare STUN.
Attivazione del “Keep Alive” e della Funzionalità “Rport”
Si tratta di due funzionalità molto importanti già presentate e discusse nell’articolo precedentemente pubblicato a questo link. Il Keep Alive serve, nello specifico, serve a garantire il corretto funzionamento del telefono IP anche in presenza di NAT dinamico, facendo in modo che il router conservi forzatamente in memoria la mappatura delle porte. L’abilitazione del parametro “Rport” consiste invece in una specifica richiesta alla centrale SIP VoipVoice di rilevazione dell’indirizzo IP e della porta di provenienza direttamente dall’header del pacchetto ricevuto. La combinazione di queste due funzionalità garantisce la perfetta operatività del telefono IP nella maggior parte delle situazioni.
Per procedere alla configurazione è necessario accedere al menu Account -> Advanced -> Account1
Alla voce “Keep Alive” impostare il valore Default
Alla voce “Keep Alive Intervals (seconds)” inserire il valore di 15
Alla voce “Rport” selezionare la modalità Enable Direct Process per abilitare la funzionalità avanzata di Rport presente nei telefoni Yealink.
Alla voce “DTMF Type” selezionare infine il valore RFC2833 per impostare la modalità DTMF in modalità RTP Out of Band (testuale).
A questo punto la configurazione può considerarsi completa e il telefono dovrebbe mostrare il Register Status “Registered” come nell’immagine qui sotto.
4. Ottimizzazioni Opzionali
Cambio opzionale della porta SIP di Ascolto del telefono Yealink
La configurazione che abbiamo presentato in questa guida consente di aggirare le barriere di NAT in situazioni comuni. La presenza di algoritmi SIP, di meccanismi di doppio NAT e di router inadatti al VoIP potrebbe però intercettare e alterare i messaggi SIP. In questo caso un’opzione consigliabile sarebbe quella di modificare la porta di ascolto sip del telefono Yealink.
L’operazione di cambio porta si esegue dal menu Settings -> SIP. E’ possibile ad es. indicare come porta SIP la porta 15060
I saluti, gli abbracci, le strette di mano, il palco, le presentazioni e i tanti sorrisi!
Alla Convention VoipVoice 2023 “Nati per Comunicare” hanno partecipato partner provenienti da tutta Italia! Ad accoglierli, la magnifica cornice del Teatro della Pergola di Firenze: proprio lì dove sono stati fatti i primi esperimenti del telefono siamo voluti tornare per raccontare il futuro delle telecomunicazioni digitali!
SIPS identifica significa letteralmente “Session Initiation Ptotocol Secure”. TLS e SRTP sono le terminologie utilizzate per definire la tecnologia VoIP SIP che fa uso della crittografia per garantire i più elevati standard di sicurezza. Ma come funziona il mondo del SIP Sicuro ?
La telefonia Voice over IP con standard SIP impiega, come sappiamo diversi protocolli al fine di stabilita una comunicazione telefonica. In particolare ricordiamo che, mentre il protocollo SIP (Session Initiation Ptococol) si occupa di avviare modificare e concludere la chiamata , il protocollo RTP (Real Time Transport Protocol) viene utilizzato come veicolo per trasferire l’audio e il video tra i due interlocutori.
Se dunque il protocollo SIP agisce di fatto come “regista” della comunicazione stabilendo i parametri per avviare la conversazione audio vera e propria, Il protocollo RTP si occupa di trasportare l’audio tra due specifici interlocutori sulla base degli indirizzi IP, delle porte di comunicazione, dei codec e dei parametri specificati all’interno della sezione SDP (Session Description Protocol) contenuta nella sezione “body” del messaggio SIP.
IL SIP Sicuro con TLS
Le criticità a livello di sicurezza e privacy del messaggio SIP sono date dal fatto che i messaggi SIP e i flussi RTP possono essere intercettati e letti/ascoltati da chiunque abbia accesso alla rete Ethernet locale a possieda una conoscenza di base del funzionamento del protocollo SIP. Gli stessi strumenti che vengono utilizzati nel campo della diagnostica tecnica VoIP, come ad es. Wireshark, consentono di tracciare, isolare e leggere sia il messaggio SIP che la conversazione audio.
Per le ragioni appena esposte, le criticità più importanti a livello di riservatezza del protocollo SIP, riguardano gli ambiti locali (LAN) più che la sezione Internet pubblica.
Per superare i difetti di sicurezza di SIP e RTP ed effettuare chiamate sicure tramite Internet, sono state sviluppate versioni crittografate di entrambi i protocolli.
Con l’acronimo SIPS si indica il SIP Secure. Si tratta di un protocollo SIP esteso con con TLS (Transport Layer Security). Attraverso TLS, è possibile stabilire una connessione sicura tra IP PBX e telefono VoIP utilizzando un approccio di tipo handshake.
Il protocollo SIPS è stato definito nel 2004 dall’IETF (Internet Engineering Task Force) come RFC 3711.
SRTP
il protocollo SRTP (Secure RTP) trasporta la voce in pacchetti IP crittografati e li trasporta attraverso Internet dal chiamante (sistema telefonico IP) aal chiamato (telefono IP o softphone), solo dopo che SIPS ha avviato una connessione sicura. Per consentire al destinatario di decrittografare i pacchetti, viene inviata una chiave tramite SIPS, quando la connessione viene avviata nel passaggio precedente.
la funzione principale del protocollo SRTP è quella di evitare l’intercettazione audio delle chiamate telefoniche tra gli interlocutori. Ciò consente di garantire la pricacy e di fare in modo che le chiamata non possano essere riprodotte e ascoltate anche in caso di intercettazione del flusso dati.
L’algoritmo di cifratura di base utilizzato di default per SRTP è l’AES (Advanced Encryption Standard) ma lo standard RTP è piuttosto flessibile e consente di accogliere persino eventuali nuovi algortmi di cifratura attraferso la definizione di una nuova RFC integrativa di specifica.
La combinazione SIPS/SRTP
Utilizzando SIPS/SRTP, viene utilizzata una connessione peer to peer sicura non solo per proteggere l’audio ma anche la connessione che viene stabilita in precedenza. Ciò significa che non solo l’audio è crittografato, ma anche i dettagli della connessione (il numero del mittente e del destinatario ecc).
Per utilizzare la versione crittografata dell’intero complesso della trasmissione SIP/RTP, tutti dispositivi coinvolti devono supportare sia SIPS (TLS) che SRTP. Se un peer non supporta questi protocolli, non è possibile stabilire una connessione sicura. E’ consigliabile utilizzare SIPS e SRTP negli scenari in cui sono possibili attacchi e manipolazione del protocollo da parte del mondo esterno . Ciò è valido ad esempio per i centralini in cloud con interni locali quando non sia disponibile un layer di sicurezza aggiuntiva, quale ad esempio una VPN.
Un ultimo vantaggio indiretto offerto dall’uso della crittografica riguarda l’utilizzo del protocollo SIP in quegli ambiti nei quali siano presenti protocolli di ispezione SIP ALG oppure algoritmi di analisi dei pacchetti che possono alterare o filtrare la comunicazione SIP, creando spesso problemi di funzionamento. In questi casi SIPS garantisce l’integrità del messaggio SIP evitando problemi quali la caduta della conversazione per questioni di SIP timer oppure la monodirezionalità o l’assenza di audio dovute alla modifica discrezionale degli indirizzi IP presenti nel messaggi SIP, da parte si SIP ALG o SIP Helper.
Negli ultimi anni si è assistito alla dismissione delle linee analogiche in ISDN per passare alla tecnologia VoIP. Il VoIP, acronimo di Voice over Internet Protocol, permette di effettuare chiamate tramite una connessione Internet, configurando un user e una password su pc o su telefoni VoIP.
Il VoIP segna un passaggio generazionale importante grazie al quale è possibile chiamare un dispositivo non più solo tramite la tradizionale rete telefonica analogica ma trasmettendo il segnale attraverso la rete internet. Questo cambiamento rappresenta un cambio generazionale dove gradualmente l’analogico viene sostituito con nuovi strumenti e soluzioni digitali.
I primi prototipi della tecnologia VoIP sono incominciati già negli anni ’70, tuttavia, le prime versioni di questa nuova tecnologia erano rudimentali e di bassa qualità.
Con lo sviluppo tecnologico e soprattutto con il miglioramento della copertura infrastrutturale, nel giro di pochi anni, il VoIP è diventato uno dei principali strumenti delle UNIFIED COMMUNICATIONS, ossia l’intera infrastruttura di comunicazione.
Da diversi anni ormai tutti i principali gestori nazionali ed internazionali stanno cambiando le modalità di trasmissione delle chiamate. Noi non ce ne accorgiamo, ma in realtà la nostra voce quando facciamo le chiamate già viaggia attraverso la rete internet.
Il VoIP rappresenta, quindi, un ricambio generazionale abbastanza recente che tuttavia coinvolge non solo gli strumenti ma che comporta un cambio di mentalità e l’introduzione di nuovi modelli organizzativi perché, attraverso la tecnologia VoIP, la gestione dei processi avviene in maniera più flessibile ed efficace.
Vediamo adesso nello specifico il perché.
La tecnologia VoIP per poter funzionare correttamente necessita di una connessione internet performante, sicura e stabile. Il VoIP è lo strumento che ha consolidato il concetto di integrazione tecnologica digitale ridefinendo il modo in cui utilizziamo gli strumenti digitali.
Le Unified Communications ci impongono di pensare alla tecnologia non più come singoli prodotti o servizi ma come un’unica piattaforma integrata. L’integrazione e la collaborazione di più strumenti è la chiave di svolta per creare all’interno delle organizzazioni un’infrastruttura tecnologica in grado di garantire continuità dei servizi, agilità, flessibilità e snellimento dei processi.
Chi utilizza il VoIP è consapevole che il processo di innovazione passa proprio dalla cooperazione di più strumenti digitali che insieme creano un sistema in grado di sostenere i nuovi ritmi del mercato e di conseguenza del lavoro.
La tecnologia VoIP permette di comunicare in maniera più efficace, integrata e immediata rispetto alla telefonia tradizionale. Adottare questa soluzione e i sistemi di Unified Communications annessi consente alle aziende di:
- INNOVARE I PROCESSI AZIENDALI > rendendoli più aperti, efficienti, flessibili e versatili. Grazie alle funzioni dei centralini VoIP sarà possibile semplificare e gestire in modo più agevole tutta la comunicazione in entrata e in uscita con l’obiettivo di ottimizzare le attività e i processi aziendali.
- MIGLIORARE LA QUALITÁ DELLA COMUNICAZIONE > il VoIP rientra all’interno della famiglia delle soluzioni integrate e sistemi omni canale che permettono di gestire tutte le comunicazioni su un’unica infrastruttura
- AUMENTARE LA SODDISFAZIONE DEI COLLABORATORI > un numero VoIP è uno strumento di lavoro che permette di gestire le attività in mobilità e con maggiore agilità. Da qualsiasi dispositivo che sia tablet, cellulare o pc è possibile rispondere alle chiamate agevolando la rintracciabilità del numero anche fuori dall’orario lavorativo e dall’ufficio
- ABBATTERE I COSTI > tramite il VoIP è possibile abbattere i costi fissi della telefonia tradizionale soprattutto per le chiamate internazionali
- RISPARMIARE TEMPO > la gestione delle attività è più veloce. Il VoIP è uno strumento in grado di ottimizzare la produttività grazie auna gestione professionale della comunicazione.
- CONTINUITÁ DEL SERVIZIO > con il servizio di backup le chiamate possono essere deviate su qualsiasi altro numero di telefono senza perdere la chiamata
- RIDUCE GLI ERRORI > grazie ai vantaggi di una gestione agevole delle chiamate e agli altri benefici sopra elencati, il VoIP aiuta a ridurre la percentuale di errore ottenendo prestazioni lavorative migliori e altamente professionali
L’attuale situazione del mercato impone alle imprese di pensare e di investire nei processi di innovazione. Sono cambiamenti che coinvolgono non solo gli strumenti tecnologici ma una ridefinizione dell’intera organizzazione che porta in maniera immediata a dei vantaggi competitivi essenziali per poter competere in un mercato in continuo mutamento e sempre di più concorrenziale.
VoipVoice, da 17 anni, propone servizi di telefonia VoIP flessibili e compatibili con le esigenze e le necessità dei propri clienti come: numeri a consumo, FLAT, VoIP Continuity, Fax-to-Mail, Numeri Verdi e Servizi Opzionali.
Se sei interessato a conoscere nel dettaglio ciascun servizio e se vuoi testare GRATUITAMENTE un nuovo numero VoIP scrivi a commerciale@voipvoice.it o chiama il numero 055 0935400.
L’inoltro di una chiamata VoIP, da parte di un dispositivo SIP, consiste generalmente nel modificare il destinatario della chiamata stessa attraverso il dispositivo ricevente. L’inolto di una chiamata VoIP ad un dispositivo esterno al PBX può risultare utile in varie circostanze.. Esistono tre modalità sostanziali con le quali eseguire un inoltro esterno di chiamata attraverso un moderno PBX IP: attraverso la rete dati con un client SIP remoto, attraverso la rete vocale mobile e un nuovo canale VoIP SIP, attraverso un messaggio SIP di risposta SIP “302 moved temporarily”.
L’inoltro all’esterno di una chiamata voce VoIP SIP può essere effettuato, attraverso un PBX, verso un softphone remoto, a patto che lo smartphone si trovi in condizioni di buona copertura dati. Qualora questa condizione non sussista, non rimane che ricorrere ad un inoltro attraverso la rete vocale mobile.
In questo articolo cercherò di descrivere brevemente le modalità con le quali è possibile effettuare, nell’ambito dei centralini IP, un inoltro di chiamata vocale. Ci soffermeremo in particolare su una modalità poco conosciuta nell’ambito dei servizi VoIP business ma molto pratica e funzionale. Parleremo della risposta SIP 302.
Analizziamo di seguito le 3 modalità di inoltro chiamata utilizzabili:
1) Inoltro verso uno Smartphone con chiamata SIP interna
La maggior parte dei moderni centralini VoIP SIP, consente agevolmente di inoltrare permanentemente una chiamata SIP ad un interno remoto attraverso la rete dati e senza sostenere alcun costo aggiuntivo per la deviazione.
Si tratta sicuramente della situazione ideale attraverso la quale il destinatario è in gradi di visualizzare direttamente il numero telefonico del chiamante originale.
Per poter raggiungere l’interno remoto con il protocollo SIP, senza alcun costo, è necessario che lo Smartphone o il dispositivo remoto sia coperto da rete 4G o 5G con buon segnale. In caso contrario la qualità della chiamata potrebbe risentirne in maniera significativa.
Se questa opzione è pienamente utilizzabile nelle aree metropolitane italiane, non è invece sempre scontato che lo sia nei contesti cittadini di minore rilevanza e nelle aree rurali.
2) Inoltro verso uno Smartphone con nuova chiamata SIP esterna
Una seconda possibilità per effettuare l’inoltro di una chiamata VoIP SIP, consiste nell’inoltrare la chiamata attraverso il provider VoIP verso la rete mobile direttamente attraverso il PBX. In questo secondo caso il PBX prende in carico la chiamata indirizzata all’interno e la inoltra al numero mobile dello Smartphone remoto eseguendo una seconda chiamata SIP in uscita.
Nel complesso l’inoltro di chiamata con questa modalità occupa simultaneamente due chiamate SIP: una in ingresso verso il centralino e una in uscita verso la destinazione programmata sull’interno telefonico.
In una situazione di questo tipo, il destinatario finale della chiamata non sarà in grado di visualizzare il numero del chiamante originale sul display dello smartphone. Il numero visualizzato sarà infatti quello del trunk SIP utilizzato per inoltrare la chiamata.
3) Inoltro verso uno Smartphone con messaggio SIP 302 moved
Esiste infine una terza possibilità per eseguire l’inoltro di una chiamata VoIP SIP attraverso un messaggio SIP di tipo “302 moved”. Questa modalità prevede che il Telefono IP o il PBX ricevano la chiamata e rispondano all’INVITE in ingresso con una risposta “302 MOVED TEMPORARILY” con la quale indicano alla centrale SIP di reindirizzare direttamente la chiamata ad un numero esterno.
Differentemente dall’inoltro di chiamata effettuato attraverso una nuova chiamata SIP, in questo caso il destinatario è in gradi di visualizzare direttamente il numero telefonico del chiamante originale.
Si tratta di un’opzione sicuramente interessante che però richiede il supporto diretto sia da parte del dispositivo SIP (Telefono IP o Centralino IP) che, soprattutto, della centrale SIP dell’operatore. Nell’ambito dei servizi forniti da VoipVoice, tale operazione è attualmente supportata sperimentalmente unicamente sul dominio trunk.voipvoice.it. Vediamo insieme come funziona il servizio, osservando il diagramma della chiamata:
Numerazione VoIP: 071xxxxxxx
Chiamante esterno: 338xxxxxxx
Numero di inoltro: 393xxxxxxx
Il Telefono IP registrato con numerazione 071xxxxxxxxxx su centrale con dominio “trunk” VoipVoice, riceve la chiamata (INVITE in Ingresso) dal numero 338xxxxxx e risponde con l’opzione “302 Moved Temporarily” inoltrando la chiamata a 393xxxxxxx. Analizzando il contenuto della sezione header della risposta 302 osserviamo le due seguenti intestazioni che caratterizzano il messaggio di risposta:
Contact: <sip:393xxxxxxxx@trunk.voipvoice.it;user=phone> Diversion: <sip:071xxxxxxx@178.x.x.x:5060;transport=udp;rinstance=cdab9d7404a0b503>
E’ importante notare che la chiamata viene inoltrata inserendo nell’header CONTACT il numero al quale inoltrare la chiamata, mentre nell’header DIVERSION viene indicato il numero originale del trunk SIP.
La risposta “302 Moved Temporarily” nell’ambito della RFC3261
La RFC3261 prevede espressamente alcune modalità di reindirizzamento diretto dell’INVITE. Se l’UAS decide di reindirizzare la chiamata, viene inviata una risposta di tipo 3xx. E’ possibile effettuare un reindirizzamento con risposta 301(spostato in modo permanente) oppure di tipo 302 (spostato temporaneamente)
“la risposta DEVE contenere una intestazione CONTACT contenente uno o più URI di nuovi indirizzi a cui inoltrare la chiamata. La risposta viene passata alla transazione del server che ha trasmesso INVITE, che si occuperà di eseguire direttamente una nuova chiamata al numero indicato”
E’ importante precisare che servizi come quello in oggetto non sono normalmente supportati dalle centrali VoIP di classe 5 e richiedono un’abilitazione specifica. Per informazioni circa il supporto dell’opzione 302 nell’ambito dei servizi VoipVoice è necessario contattare direttamente il reparto commerciale VoipVoice per informazioni. Ricordiamo infine che il sevizio, al momento della scrittura del presente articolo, è disponibile in forma sperimentale unicamente con i trunk SIP VoipVoice su dominio trunk.voipvoice.it
