Archivio

Archive for the ‘VoIP:Info’ Category

G.729 finalmente libero!

Chi lavora nel fantastico mondo del voip open source spesso spende il suo tempo nel capire come i programmatori abbiano implementato una certa funzionalità. Si spende tempo nei forum, nelle mailing list e nell’esame del codice sorgente per apprendere cose che, a volte, non sono scritte da nessuna parte. Giustamente gli sviluppatori campano di consulenze sul loro lavoro e quindi sono un po’ stringati nello spiegare le cose. Ecco che questa diviene l’unica vera spesa, l’unico vero investimento in tempo e quindi denaro.

C’è però un’altra voce che subdolamente per anni ha attanagliato il povero voippista: il codec G.729! E già perché, diversamente da molti altri codec, questo “algoritmo” di compressione e decompressione della voce aveva un brevetto (per dire la verità una pletora di brevetti) tenuto ben stretto dai sui inventori (Orange SA, Nippon Telegraph and Telephone Corporation and Université de Sherbrooke) che facevano pagare una tassa sull’utilizzo del medesimo. Se tenete conto che non esiste apparato voip che monta questo codec, potete farvi un’idea dei fantastigliardi che la cosa ha fruttato in quasi venti anni di monopolio mondiale!

Sugli apparati la cosa pesava poco perché il tutto veniva pagato al momento dell’acquisto del telefono o dell’ATA o dell’attrezzo pinco pallo. Sui centralini ip o.s. (Asterisk,Freeswitch,Yate, etc.) il tutto era a carico dei poveri voippisti!

Molti ricorrevano ad implementazioni del codec più o meno buone diffuse clandestinamente in rete, altri acquistavano moduli G.729 dagli sviluppatori del PBX in oggetto o utilizzavano schede hardware per la transcodifica. Una stenta ragazzi, una stenta!

Via via negli anni le varie patents (brevetti) scadevano ma la cosa diventava uno stillicidio perché se anche uno dei vari brevetti che componevano il codec ancora era attivo, fermava tutto!

Dall’inizio di quest’anno siamo finalmente liberi…anche se io l’ho saputo solo adesso!  Il consorzio dove gli “inventori” di questo codec si sono radunati ha finalmente dichiarato:

As of January 1, 2017 the patent terms of most Licensed Patents under the G.729 Consortium have expired.
With regard to the unexpired Licensed Copyrights and Licensed Patents of the G.729 Consortium Patent License Agreement, the Licensors of the G.729 Consortium, namely Orange SA, Nippon Telegraph and Telephone Corporation and Université de Sherbrooke (“Licensors”) have agreed to license the same under the existing terms on a royalty-free basis starting January 1, 2017.
For current Licensees of the G.729 Consortium Patent License Agreement, no reports and no payments will be due for Licensed Products Sold or otherwise distributed as of January 1, 2017.
For other companies selling G.729 compliant products and that are not current Licensees of the G.729 Consortium, there is no need to execute a G.729 Consortium Patent License Agreement since Licensors have agreed to license the unexpired Licensed Copyrights and Licensed Patents of the G.729 Consortium Patent License Agreement under the existing terms on a royalty-free basis starting January 1, 2017.

In sintesi: la licenza principale è scaduta e abbiamo deciso di far scadere anticipatamente anche le altre, quindi potete fare ciò che meglio credete di questo codec. Cosa ha spinto questa mossa? La vergogna , dico io, e qualche nuovo codec gratuito (come OPUS) che può fare le scarpe al G.729. Eppure il G.729 è molto usato anche nelle interconnessioni tra operatori (anche la specifica tecnica italiana 769.1 lo prevede insieme al G711a) quindi si tratta di una grossa spinta verso un voip veramente libero.

Stiamo a vedere cosa ne pensa il mercato….sicuramente continueranno a farci pagare qualcosa ma ora siamo liberi di metterci giu e implementare l’algoritmo del G.729 senza che qualcuno venga a pretendere denaro!

Annunci
Categorie:VoIP:Info

Dove eravamo rimasti…

Nell’anno appena terminato, non ho scritto neanche un post, se non aggiornare qualcosa qua e là. Questo perché sia a livello lavorativo che in privato ho avuto molte cose da fare. La mente però non si ferma e a breve rivelerò nuove iniziative che orbitano intorno al mondo del VoIP.

La soddisfazione più grande è stata quel centinaio di lettori che, senza uno straccio di pubblicità, senza nessun tam tam di rete e senza sapere bene cosa stavano facendo ( 😉 ) si sono avventurati nell’acquisto del mio libro su Freeswitch: GRAZIE, GRAZIE, GRAZIE. Potrà sembrare un piccolo successo ma per me siamo andati oltre la più rosea delle previsioni.

Altro argomento caldo in cui mi sono avventurato in questo lungo 2016 sono le interconnessioni VoIP tra operatori. Eh sì, perché anche le grandi compagnie telefoniche sono capitolate sotto gli sferzanti attacchi della voce su internet. E quindi ho scoperto un mondo a chiaro-scuri molto intrigante.

Non sono mancate le mie solite sperimentazioni, avvicinando colossi come Kamailio e strani oggetti detti SBC, di cui dovremo parlare sicuramente.

Interessanti anche le esperienze di formazione che ho avuto con alcune aziende…insomma state in campana…ci saranno novità!!!

Centralino 3CX e GNR VoIP Clouditalia

3CX è un IP-PBX sviluppato per girare su MS Windows. Ultimamente è diventato tristemente famoso nella comunità VoIP per le sue pubblicità che minimizzano le soluzioni voip open source linux based. Sono esilaranti i commenti dei lettori!

Rimane comunque un sistema ben ingegnerizzato, anche se il sistema operativo su cui gira non è proprio famoso per la sua stabilità. Tutti i gusti son gusti, diciamo così.

Mi è capitato di dover aiutare un cliente che aveva difficoltà nel configurare una selezione passante VoIP di Clouditalia. Come al solito mi sono industriato alla ben e meglio e ne ho installato una demo sul mio PC, risolvendo il problema.

Per prima cosa bisogna configurare bene il trunk col provider. C’è sempre la solita questione del from/to da impostare per avere la selezione passante in ingresso/uscita:

1 – Provider/Generale : inserisco l’account numero-password a cui è collegato il GNR

3cx_ProGeneral

2- Setto i parametri avanzati, tra cui i codec

3cx_ProAdvanced

3 – Setto i parametri in outbound: esaminate bene la tabella SIP Fields

3cx_ProOutParams

4 – Lo stesso si fa per l’inbound

3cx_ProInParams

5 – Elenco gli aggiuntivi in DDI

3cx_ProDID

Per la parte SIP Trunk siamo a posto. Ora si deve lavorare sugli interni, per creare l’associazione geograficointerno.

6 – Nelle Extensions si crea l’interno

3cx_ManagerEXT

7 – Si associa il geografico

3cx_ManagerDID

8 – Si settano alcuni parametri in Others

3cx_ManagerOther

E il gioco è fatto. Come al solito non sarà l’unico modo, anche perché ho sempre poco tempo per studiare gli apparati. Però quello che scrivo è sempre testato!

Categorie:VoIP:Info

Fastidiose chiamate VoIP notturne: chi è?

Molti clienti si lamentano del fatto che spesso ricevono chiamate, anche di notte, sui loro apparati VoIP, con numero chiamante assurdo. A volte sono anonime, a volte il numero è esageratamente lungo, a volte è troppo corto (es. 100), a volte si riceve solo un indirizzo IP. Chi risponde o non sente niente, o il fischio di fax o messaggi incomprensibili.

Più o meno la domanda che mi giunge è sempre la stessa: “Ma chi è? Chi osa disturbare il mio sonno? Voi gestori delle centrali VoIP dovete assolutamente dirmelo!

Per rispondere alla domanda dobbiamo fare un passo indietro e parlare del protocollo SIP, il più usato ormai negli apparati VoIP. Il SIP è un protocollo peer-to-peer, punto-punto. Teoricamente non ho bisogno di nessuna centrale per fare telefonate in SIP. Due telefoni SIP possono parlare tra loro semplicemente indicando ad uno dei due l’indirizzo IP e la porta d’ascolto dell’altro. Questa peculiarità del protocollo è sfruttata da manigoldi diffusi per tutto il globo per infastidire i poveri utenti. Come ricevete email pubblicitarie che non avevate chiesto, così ricevete telefonate che non avevate chiesto. In questo caso si parla di SPITTING (Spam over Internet Telephony).

Ma lo scopo qual’è: sono scherzi per svegliarmi, tipo i ragazzini che suonano i campanelli? No. Chi vi manda quelle telefonate non ha nessun interesse a svegliarvi. Anzi: all’altro capo del telefono c’è una macchina, con pochissimo senso dell’umorismo. A che pro?

  • Invio di FAX pubblicitari
  • Invio di messaggi pubblicitari (quasi sempre in inglese)
  • Verifica dell’esistenza di un apparato VoIP presso il vostro IP

L’ultimo è il più pericoloso e spesso si avvale di un software chiamato SIPVicious, in grado di generare chiamate a raffica e interagire con altri software. Tipicamente, se il vostro telefono IP risponde, da lì a poco parte un attacco fraudolente per rubarvi la password del vostro account VoIP e farvi arrivare bollette salatissime. Chi ha fatto SIPVicious voleva solo offrire un tool di test ai tanti sviluppatori di software VoIP. Invece è diventato lo strumento più usato dai pirati di tutto il mondo.

La seconda domanda che arriva è:”Ma come hanno fatto a scoprire il mio IP?” Se hai una macchina che lavora per te 24 ore su 24, puoi permetterti di spazzolare tutte le classi IPv4 esistenti sul pianeta! Se poi usi un provider che fa VoIP (quasi tutti ormai) sarai ancora più colpito. Quindi non vi preoccupate: nulla di personale.

Ed ecco la terza ed ultima domanda:”Come posso difendermi?” Semplicemente popolando opportunamente le vostre regole di firewall. Se fate VoIP con un certo provider, sinceratevi di aprire la porta SIP del vostro telefono (tipicamente la 5060 UDP) solo all’indirizzo IP della loro piattaforma. Dovete comunicare anche con i centralini VOIP delle altre sedi della vostra azienda? Aprite anche quelli. Insomma, non lasciate i vostri apparati VoIP aperti al mondo, anche se sono nattati. Basta proteggere il VoIP? No! Proteggete anche l’interfaccia web, l’accesso telnet. Tutto!

Eh ma come sei paranoico!” Dirà qualcuno. Statene certi, è il prossimo che bucano!

Categorie:Voip:Clients, VoIP:Info

WebRTC: anche il telefono se ne va nella nuovola

L’ultimo baluardo dell’ufficio vecchia maniera era rimasto il telefono. Google e soci avevano messo in cloud tutto il necessario ad una normale postazione lavorativa. La posta su GMail, i documenti su Drive, foglio di calcolo ed editor inclusi, gli appuntamenti sul Calendar, le presentazioni video su YouTube.

Eppure il telefono eravamo comunque costretti a portarcelo dietro. Dal classico cellulare fino al softphone sul PC, per i più smaliziati. Insomma o ti portavi dietro il telefono o per lo meno il tuo PC con il tuo software di fiducia e le cuffiette. In passato ci sono stati tentativi per superare questo vincolo. Ricordo GizmoCall, FlashPhone e altri. Tutti ottimi tentativi che risentivano delle specifiche hardware o di rete, in cui la pagina web girava.

Poi i ragazzi della grande G si inventano un progetto spettacolare. Contattano i maggiori produttori di web browsers e li coinvolgono nello standardizzare una nuova tecnologia: il WebRTC, dove la sigla sta per Real-Time Communications. La soluzione all’annoso problema della comunicazione portatile viene trovata nel classico uovo di colombo.

Le solite menti visionarie si sono dette: cosa succede se integriamo nei browsers delle funzionalità per gestire audio (scheda sonora, cuffie,etc) e video (webcam), oltre che ad un protocollo per lo streaming sicuro? Ecco che così il browser diventa lo strumento per comunicare, dopo essere già diventato lo strumento per scrivere programmare e inviare mails. Ci sono delle demo (http://googlechrome.github.io/webrtc/) che mostrano la potenza di questo nuovo strumento, realizzate dai suoi inventori e fan entusiasti.

Un altro gruppo di programmatori, gli amici di FreeSWITCH, di cui tanto ho parlato in queste pagine, hanno subito cavalcato l’onda e creato un modulo per il loro  software VoIP che si interfaccia agevolmente col WebRTC. Sto parlando di mod_verto. Non sono proprio di primo pelo nelle telecomunicazioni ma la semplicità riesce ancora a stupirmi. Con poche righe di codice, riutilizzando dei pezzi di Javascript già presenti in rete da anni, si riesce a creare qualcosa di unico.

La DEMO permette di unirsi alla conference degli sviluppatori in certi giorni della settimana. Generalmente udrete musica. Il bello è che quella demo potete scaricarla e farla diventare il vostro web phone personale! Certo ci vuole un po’ di studio per modificarla a proprio piacimento, utilizzando tutti i metodi del WebRTC. Ma il risultato è più che soddisfacente.

L’ultima barriera è dunque superata. Se siete in vacanza alle Maldive e quel cliente importantissimo ha bisogno di essere chiamato, andate ad un internet point, trovate sul Drive le offerte che gli avevate mandato, accedete al vostro webphone e chiamatelo col numero dell’ufficio. Tranquilli…non vedrà le vostre infradito.

GNR Virtuale Clouditalia e Call Manager Express

03/12/2013 16 commenti

Sul lavoro ne capita di tutti i colori. Quando si tratta di mettere le mani su roba CISCO poi, che intende il VoIP in maniera molto proprietaria, son dolori. E sì perché il marchio leader del networking ha pensato, ormai da anni, la sua bella soluzione voip e non ammette interferenze dall’esterno…o quasi.

Quando mi sono ritrovato a configurare un account VoIP Clouditalia con selezione passante su un gateway montante IOS 15.1  e Call Manager Express ho cambiato colore del viso! Ma alla fine, anche senza certificazione, in qualche modo ne sono uscito.

La release in questione offre una serie di comandi, non ben documentati, che suppliscono alle carenze della famiglia 12, con la quale l’unica strada era ricorrere a script TCL legati ai dial-peers. Questi comandi permettono di manipolare i pacchetti SIP e raggiungere lo scopo che ci prefiggiamo. Qual’è lo scopo? Estrarre l’effettivo chiamato ingresso, perché Clouditalia manda sempre lo stesso numero sulla SIP Request URI, ma mette l’effettivo chiamato nella TO URI. Una scelta che ci rende la vita difficile in ambito CISCO, ma già recepita da molti centralini nativi voip e non.

Il primo blocco di comandi definisce le regole di manipolazione della segnalazione SIP:

voice class sip-profiles 1
request INVITE peer-header sip To copy “sip:(.*)@” u01
request CANCEL peer-header sip To copy “sip:(.*)@” u01
request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:\u01@\1”
request CANCEL sip-header SIP-Req-URI modify “.*@(.*)” “CANCEL sip:\u01@\1”

In pratica si copia la TO URI e si sostituisce alla SIP Request URI, unico sistema per poi matchare i dial-peers che seguono.

Quindi si imposta due regole di “ingaggio” per beccare il chiamato:

voice class uri TRUNK sip
user-id 01234567..

voice class sip-copylist 1
sip-header TO

Il grosso è fatto ma già arrivare fino a qui mi ha fatto penare!

Concludiamo con un paio di dial-peers che attuano quanto definito.  Il primo cattura il pacchetto:

dial-peer voice 99 voip
description incoming SIP Trunk
session protocol sipv2
session target sip-server
incoming uri to TRUNK
voice-class codec 1
voice-class sip copy-list 1

Il secondo lo modifica e lo ributta nel dial-plan:

dial-peer voice 300 voip
description to/from ccme
destination-pattern 01234567..
session protocol sipv2
session target ipv4:<IP Locale CCME>
voice-class codec 1
voice-class sip profiles 1
dtmf-relay rtp-nte
no vad

Naturalmente l’account principale deve essere registrato:

sip-ua
credentials username 0123456700 password 7 <password account voip> realm voiptrunk.eutelia.it
keepalive target dns:voip.eutelia.it
authentication username 0123456700 password 7 <password account voip> realm voiptrunk.eutelia.it
nat symmetric role active
nat symmetric check-media-src
no remote-party-id
retry invite 2
retry response 3
retry bye 3
retry cancel 3
retry register 10
timers connect 100
timers keepalive active 100
registrar dns:voip.eutelia.it expires 900
sip-server dns:voip.eutelia.it
connection-reuse
host-registrar

I purisiti mega certificati troveranno che dire, ma vi assicuro che a uno come me sarebbe servito come il pane trovare istruzioni del genere! Quindi sotto con i commenti ma non inferite troppo.

P.S. Per i soliti svegli: 01234567XX è un GNR di esempio…sostituite la vostra radice, mi raccomando.

Categorie:VoIP:Cisco, VoIP:Info

SIP Digest authentication: come funziona.

14/06/2011 3 commenti

Mi viene spesso chiesto come fa un client sip (softphone, ip-phone o IPPBX)  a comunicare le proprie credenziali di autenticazione al sip proxy server. In  effetti, facendo un tracciamento, si vedono solo lunghe stringhe esadecimali.

Quasi tutti gli apparati mandano un REGISTER al SIP Proxy Server, a cui viene risposto con un “401Unauthorized”. In questo pacchetto di risposta vi è una riga (header field) così fatta:

WWW-Authenticate: Digest realm=”voip.eutelia.it”, nonce=”447165da1af55bfd20e7e55d8d2bb81eba54e377″, qop=”auth”

L’apparato che vuole registrarsi ne trae non poche informazioni

  • il realm di riferimento (simile al concetto di dominio, gruppo logico degli account SIP)
  • il tipo di autenticazione (auth=determinato algoritmo di encryption)
  • una chiave randomica necessaria all’encryption detta nonce (abbrevia “number used once“)

A questo punto l’apparato rimanda il REGISTER ma con un nuovo campo dove è contenuta la password criptata:

Authorization: Digest

username=”0575123456″,realm=”voip.eutelia.it”,

nonce=”447165da1af55bfd20e7e55e8d2bb81eba54e377″,

response=”6f00b8e7c79455475750da9a8c044ecd”,

uri=”sip:voip.eutelia.it”,qop=auth,

cnonce=”B18606FEE42246E39B068D3210CCC691″,

algorithm=MD5, qop=auth, nc=00000001

La password dell’account è contenuta in response: il server ha tutte le informazioni (conoscendo a sua volta la password) per calcolare la response e confrontarla con quella mandata dal client. Quindi la vera domanda è: come si calcola la response?

Response è la somma MD5 della sequenza :

response = MD5 (HA1:nonce:nonceCount:clientNonce:qop:HA2)

Non è l’unica formula, ma siccome il SIP Proxy Server ha detto nel “401 Unauthorized” che il tipo di encyption è “qop=auth”, questa è la formula da applicare. I due parametri HA1 e HA2 si calcolano rispettivamente come segue:

HA1 = MD5 (username:realm:password)
HA2 = MD5 (method:digest uri)

Quindi con i parametri ricevuti nel “401 Unauthorized” il client (softphone, ip-phone o IPPBX,etc) si calcola HA1 e HA2 e quindi la response.  Il server può farlo solo dopo aver ricevuto il secondo REGISTER con il campo Authorization, fa il confronto e se coincidono da il 200 OK.

Facciamo un esempio con il numero VoIP 0575123456 avente password=SEgreTo .

HA1 = MD5 (0575123456:voip.eutelia.it:SEgreTo) =0e98fe2ed9acca9550cbde26dae69bef
HA2 = MD5 (REGISTER:sip:voip.eutelia.it) = b5bb07b61124a06d3490325b07f33528

Facendo riferimento alla risposta riportata sopra come esempio avremo:

nonce=”447165da1af55bfd20e7e55e8d2bb81eba54e377″
cnonce=”B18606FEE42246E39B068D3210CCC691″
nc=00000001

Di conseguenza la response sarà:

response = MD5 (0e98fe2ed9acca9550cbde26dae69bef:

447165da1af55bfd20e7e55e8d2bb81eba54e377:

00000001:

B18606FEE42246E39B068D3210CCC691

:auth

:b5bb07b61124a06d3490325b07f33528)

= bf6e05dc1df729023428bd9ddfa4442c

Se coincide con quella inviata, l’apparato sarà registrato.

Categorie:VoIP:Info