oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: voip

Three headphones until I get succeed

Reading time: 3 – 4 minutes

This is post entry is a summary of my experience with three different headphones until I found one which is compatible with Google Meet (professional version of Google Hangout). I spent a lot of hours every day working with video conference applications like Skype and others. It means stay sat for a long time, and when I don’t have to be in front of my screen I appreciate if I can walk around my room. Of course, this is only possible when the headphones that you use are wireless. A long time ago I had wired headphones and ended tired of having small incidents which damage my ears or drop off anything which was on my table.

So, I decided to read some benchmarks about high-quality headphones, I considered a tool for my job and I decided to spend my money. Having my requirements as a reference and using the benchmark readings for checking them I finally bought the Sennheiser PXC550. I’m not going to say whatever you can find in regular reviews, just some words to say this is a very good product with an excellent sound quality. But, not works with Google Meet (Hangout). What I mean is my voice it could not be understood by other peers. It’s impossible to understand anything. Using applications like Skype, or phone calls the quality was very good. Or using the headphones from my mobile phone and the Google Meet application the quality was good.

Thanks to Amazon guarantee I returned the product and I bought the Bose QuietComfort 35. Also a very good product, maybe a little bit worse than the Sennheiser one in some aspects but anyway a world-class product. Problems with Google Meet (Hangout) were even worst, in this case, sound quality was bad not only from my mic also other people of conversation had a really bad quality. Again with Skype, the quality was good. But when I connect the headphones to my mobile using Google Meet the sound quality was horrible, impossible to use.

Finally, I bought the Plantronics BackBeat PRO 2 SE. From those three that I tried this is the product with less quality IMHO. But Google Meet from my laptop works, my voice quality is not very good but it’s good enough for using them. Again I’m talking about a very good product, with a very good quality. In front of the other two, these ones are weighty, old fashion design, less comfortable, and worst sound quality. Some advantages that I found, the most important of course is it works with Google Meet (Hangout). The sound is louder at the maximum volume, and there are physical buttons for mute and on/off/pairing. Another advantage is the Bluetooth class 1 which give better coverage when I’m not next to the computer.

I didn’t say anything so far, but I’m talking always about Bluetooth connections with my laptop where I have a Windows 10 installed with Google Chrome. Laptop Bluetooth version is 4.0 HCI and LMP version: 6.1280 manufactured by Intel and driver version is 19.30.1646.853 (date: 2016-11-14).

If anybody knows a little bit more about this topic or wants to exchange any similar experience I’ll appreciate.

Asterisk, enrutadors de trucades i altres similars

Reading time: 3 – 5 minutes

En Benja hem va preguntar si coneixia algún producte que per un cost raonable (estem parlant de menys de 300€) permetés enrutar les trucades de veu de casa seva a través d’una línia RTB convecional o d’una línia GSM. A nivell lògic la cosa és ben simple, es tracte de enviar totes les trucades a través de la línia RTB excepte les que comencen per 6 i 7 amb un número de 9 xifres. Doncs per aquesta finalitat vaig trobar navegant per internet un producte de l’empresa Portech que escencialment fa això, concretament és el model MT-350 disponible via la web de l’empresa per uns 140€.

Portech MT350

Per altre banda, si el que cal és tenir un dial-plan una mica més elavorat sempre podem tirar de solucions basades en Asterisk, de fet fa uns mesos vaig arribar a trobar versions d’Asterisk preparades per ser instal·lades en un Linksys WRT54GL, impressionant. Però si cal quelcom més professional en aquest sentit sempre hi ha les solucions de ATCOM, per exemple, amb models com el ATCOM IP01 des de 295$. De fet, jo no coneixo aquest producte de primera mà però en Byteman el va usar per una ONG a l’Àfrica, té pinta de tenir un acabat molt professional.

Askozia PBXPer altre banda, he de reconeixer que jo sobre el problema que hem plantejava en Benja el primer que vaig pensar va ser aprofitar 20 unitats de PIII a 500MHz amb 256Mb RAM i 40GB d’HD (ordinadors industrials) que tinc arraconants i en els que havia pensat instal·lar Askozia PBX.

Askozia PBX és una distribució de Linux d’uns 30MB amb un Asterisk incrustat i amb més funcions de les que ens podem imaginar per la mida de la que estem parlant:

  • An Embedded System
    • less than a 15MB download, less than 30MB installed
    • only 200Mhz and 64MB RAM needed to run
    • low resource requirements means low energy requirements
    • scales up to match the hardware it is running on
  • Telephony Services
    • conference rooms with optional access pins
    • voicemail to e-mail
    • call groups
    • multilingual audio prompts
  • Automated Configuration
    • automatic network configuration with DHCP client support
    • automatic detection and configuration of telephony ports
    • auto-provisioning of SIP telephones
    • automatic configuration of remote gateways
  • Connectivity
    • support for SIP, IAX, Skinny, Analog and ISDN accounts
    • calls freely routable between different technologies
    • integrate external phones (mobile telephones) into your local dialplan
    • outgoing provider fail-over routing
  • Installation, Administration and Configuration Management
    • distributed as a firmware image, individual software component compatibility thoroughly tested
    • entire system configuration is stored in a single XML file simplifying backups, restores and provisioning
    • administration is carried out through our multilingual WebGUI, going beyond the configuration of Asterisk, it also configures the system’s network, dyndns, ntp, and smtp settings
    • manual file appends and overrides supported

La gent d’Askozia també tenen productes integrats amb hardware i d’un acabat també molt professional si ús interessa comprar quelcom fet doneu-hi un cop d’ull que té bona pinta. Podeu anar directament a la botiga online i contrastar els preus.

Com sempre passa, la manca de temps per coordinar l’acció segur que acaba fent que no faci la integració que dubto que fos massa més d’1 setmaneta de feina per deixar-ho tot ben profesional. Però si algú si volgués apuntar ja ho sabeu.

Snap: el complement d’escriptori ideal per l’asterisk

Reading time: 2 – 2 minutes

De fet, personalment no em fa gaire utilitat aquesta eina. Però no puc dir el mateix dels meus clients. Per fi, he trobat una eina econòmica que els permet interactuar amb l’asterisk de forma senzilla i fer les típices pijades que sempre em demanen quan els monto un asterisk, gràcies Marc pel descobriment. Snap és un programet per Windows que permet veure qui ens esta trucant a la pantalla del PC, buscar aquest número a l’agenda. Marca el número de telèfon que ens apareix al firefox mentre naveguem. Marca on volem trucar des d’una petita aplicació que ens surt a la pantalla. Invocar el CRM requerint la informació del client que ens esta trucant, o fins hi tot connectar-lo via AGI a funcions més avançades d’Asterisk. Però la cosa no s’acaba aquí, s’integra amb Outlook, permet tenir un registre de les trucades que fem i que rebem. Entre d’altres coses.

snap.png

El programa té dues versions la free i la pro, aquesta última costa uns ~30$ per usuari. El que ambdues tenen en comú és la integració amb Office, Outlook, firefox i thunderbird. La versió pro a més ens mostra una finstra flotant quan entre una trucada, permet connectivitat contra el CRM per trucades entrants i sortints, disposa d’un driver TAPI (TSP driver), a més d’una versió avançada de l’identificador de trucades i del buscador de números de teléfon.

Gtalk-to-VoIP

Reading time: 2 – 2 minutes

gtalk-to-voip.png

GTalk2VoIP és un servei que permet connectar la nostre compte de Gtalk o de MSN a les xarxes PSTN, per fer i rebre trucades de VoIP, a telèfons fixes i mòbils convencionals.

Serveis disponibles:

  • Outgoing calls from Google Talk or Windows Live Messenger to any telephone number (PSTN) around the world in a very cheap manner.
  • Incoming calls from PSTN to Google Talk or Windows Live Messenger users (phone number lease service).
  • Free voice mail service for Google Talk or Windows Live Messenger users.
  • Free voice conference chat service for Google Talk or Windows Live Messenger users.
  • Ranking (by voting and real-time ASR monitoring) of VoIP service providers used for your calls routing.
  • Free off-line messaging for Google Talk users.
  • Call from the Web service allows you to receive phone calls from your potencial customers right from your web site.
  • Free outgoing calls to SIP phones.
  • Free incoming calls from SIP phones.
  • Free access to Google Talk and Windows Live Messenger from PSTN via SIPBroker (large number of PSTN gateway phone numbers).

El millor és que no hem d’instal·lar cap programa nou ni res de res, realment interessant sobretot per usar-ho des del nokia 770, tot i que encara no ho he fet però ja me’n moro de ganes de provar-ho.

Com funciona la VoIP: protocols, codecs i altres

Reading time: 10 – 16 minutes

Aquí teniu la continuació que us vaig prometre de les bases de la VoIP. Aquest article intentaré fer-lo tan entenedor com l’anterior però no serà senzill perquè els temes ha parlar són ja força tècnics i especialitzats. Malgrat això és molt necessari tenir-los clars sinó quan toquem sistemes de VoIP reals no sabrem a que es refereixen els manuals o els altres companys quan ens expliquen els motius pels que passen les coses. O simplement, perquè fan falta certs dispositius en les configuracions.

Altre cop he de fer referència a Network System Design Line, aquest cop a l’article How VoIP works: Protocols, codecs, and more (local).

Resumint les idees bàsiques

En l’article de les bases de la VoIP va quedar molt clar el procés que segueix una trucada de VoIP. També es va insinuar la importància del temps que es triga en mostrejar les ones analògiques de la veu (digitalitzar la veu) i l’espai que ocupa aquesta digitalització. Això repercutirà de forma directa en el temps que triguem en transportar aquesta informació fins a l’altre extrem on es farà el procés invers fins que l’interlocutor senti la nostre veu.

Bé doncs, en aquest document em centraré en explicar que es fa després de digitalitzar la veu, o sigui, es comprimeix aquesta informació abans de ser transportada perquè ocupi menys espai (això ho fan els codecs). Per altre banda, cal que pensem que quan enviem un email o una fotografia a través d’una xarxa IP aquesta informació no és sensible al temps. O sigui, ens és igual que trigui uns segons més o menys en arribar això no afecta en el missatge que es transporta. Obviament en una conversa això no és així i aquests paquets han d’arribar prou ràpid a l’altre extrem perquè la sensació de “temps real” sigui suficient.

Les xarxes IP, per defecte, són xarxes de tipus best-effort això vol dir que tots els paquets que viatgen a través d’elles intenten passar el més ràpid possible però sense cap tipus d’arbitratge. Parlant en plata, la llei del més fort. Per tant, es tracta inicialment d’un entorn poc indicat per transportar informació sensible al temps. Per exemple, informació en temps real (o streaming) d’audio i/o video.

Per tal d’adequar millor aquest medi a les comunicacions sensibles al temps s’usen tècniques de QoS. O sigui, intentem montar un sistema d’arbitratge en els nodes de la xarxa per tal de prioritzar el tràfic sensible al temps. Per exemple, el tràfic de VoIP. Si la xarxa en la que s’ha de treballar no té gaire càrrega de tràfic això no és massa important. Cal tenir present que internet no és una xarxa amb QoS. Per tant, és un entorn hostil per les nostres trucades de VoIP.

Entrant una mica en temes tècnics, el que hem d’aconseguir pel que fa als retards (delay) de la xarxa entre els dos extrems són temps inferiors a 100ms. Tot i que amb retards per paquet de 100 a 200ms poden arribar a passar trucades ja es poden començar a donar fenomens molestos pels interlocutors. Sovint problemes d’echo.

Problemes típics d’una xarxa IP

Quins són els problemes que hem d’intentar evitar que tingui una xarxa IP per poder-hi passar VoIP sobre d’ella:

  • Delay el retard, temps que triguen els paquets a viatjar del punt inicial al final. Els retards massa alts acostumen a provocar problemes d’echo acustic.
  • Packet loss perdua de paquets, sobretot es dona en les xarxes WAN, si els paquets han de viatjar a través de molts punts (gateways) es podrien perdre. Perdent doncs informació del missatge que es transporta.
  • Jitter canvis sobtats i no desitjats en el temps que triguen els paquets en arribar, això pot provar desordre. Per solucionar-ho sovint s’usen buffers i paquets petits, amb poca informació.
  • Echo els paquets arriben més d’una vegada per diferents camins. No és el mateix que l’echo acustic.

Resum de passos que segueix la veu fins arribar a l’altre extrem

En el següent gràfic podem veure quins són tots els passos, un per un, que segueix la nostre veu fins arribar a l’interl·locutor. Com podem veure cada un dels passos té una serie de codecs, protocols i normes associades que a continuació es descriuen.

adifigure1.jpg

Com ja s’ha comentat el primer que es fa després de mostrejar la veu (digitalitzar) es codifica i comprimeix per tal de reduir els requeriments d’amplada de banda. Aquest procés el porten a terme els codecs.

Els paquets de dades comprimits es mouen a través de les xarxes gràcies a un protocol de transport. Els gateways s’encarreguen d’enrutar aquests paquets entre diferents xarxes IP (o d’altres tipus, si cal) fins que els paquets arriben al seu destí. Quan arriba al destí es decodifiquen (i descomprimeixen) els paquets rebuts i es converteixen altre cop en audio.

VoIP en el model OSI

El model de 7 capes OSI defineix qualsevol procés de networking (interconnexió digital en una xarxa). Si hi ha dos extrems que volen tenir una sessió de comunicació, les dades que aquests generen comença a la capa 7, patint les encapsulacions necessaries fins arribar a al medi de transmissió (per on viatgen les dades: cable, aire, llum, etc) a l’altre extrem passa el procés invers des del medi fins a l’usuari. Bé doncs això és el que ens mostra el següent gràfic i ens col·loca cada un dels protocols en una de les capes.

adifigure2.jpg

Session control: H.323 vs. SIP

El primer que ens cal per establir una comunicació en VoIP és un protocol de sessió que ens indiqui com informem a la xarxa que existim, com intentem comunicar-nos amb altres usuaris o com rebem les comunicacions d’altres usuaris. Els dos protocols més coneguts que s’encarreguen d’això són H.323 i SIP. Malgrat n’hi ha molts d’altres com ara IAX (protocol usat per Asterisk).

International Telecommunication Union (ITU) H.323

L’H.323 és un estàndard de la ITU originariament desenvolupat per enviar veu i dades en temps real (videoconferencia i similars). Malgrat això una de les primeres aplicacions que va tenir va ser la VoIP. De fet, el H.323 més que un protocol és en si és un grup de d’estàndards, codecs i protocols que diuen com establir una comunicació multimedia a través d’una xarxa IP. Per exemple, el protocol de senyalització que usa H.323 és el H.225 i el protocol de negociació de funcionalitats el H.245.

Session Initiation Protocol (SIP)

El SIP el va definir la IETF a l’RFC 3261. Es va desenvolupar especialment per la telefonia IP. De fet, es considera una solució molt més neta i senzilla que l’H.323. SIP s’usa amb SDP per tal de descobrir usuaris; a més ofereix la capacitat de descobrir funcionalitats i de gestionar trucades. SDP és esencialment un format que descriu com fixar els paràmetres d’inicialització per tal d’intercanviar la informació multimèdia. Bàsicament SIP/SDP és analoga a H.225/H.245 en el protocol H.323.

El protocol SIP ens permet a més establir connexions entre dos extrems sense la necessitat de disposar d’un servidor. Tot i que no és l’habitual. Ja que normalment el que fan els clients SIP és registrar-se contra un servidor públic per tal de mostrar-se a la resta de clients de la xarxa.

Transport layer protocols

Els protocols de senyalització descrits anteriorment són els responsables d’establir les configuracions a usar en una sessió multimèdia entre dos usuaris. Però aquesta informació de senyalització viatjarà per la xarxa a través dels protocols de transport de sempre, o sigui, UDP (no orientat a connexió) i/o TCP (orientat a connexió).

Transportant la conversa: RTP

El protocol RTP ofereix un servei d’entrega de paquets amb informació d’audio i video que ha de ser servida en temps real. Aquest protocol usa com a protocol de transport el UDP per minimitzar la capçalarela (la capçalera UDP és molt més petita que TCP). A canvi d’això no pot garantir l’entrega dels paquets que transporta (UDP no és orientat a connexió, no hi ha retransmissió de paquets perduts), a més tampoc pot garantir que l’ordre en que entrega els paquets sigui el correcte.

Estructura d’un paquet RTP:

adifigure3.jpg

Així doncs el que intenta fer RTP és afegir aquelles funcionalitats que no li dona UDP per tal de que les dades que transporta siguin el màxim útils possible. Les funcionalitats que dona RTP a UDP són: nivell de QoS, marques de temps (timestamps), números de seqüència i confirmació de recepció per cada paquet enviat. També pot suportar esquemes de correcció d’errors per fer més rebustes les dades que transporta, fins hi tot algunes opcions de xifrat bàsiques per les dades del paquet.

Obviament això carrega una mica el paquet UDP, en aquest gràfic podem veure una comparació amb el preu que paguem per obtenir totes aquestes funcionalitats.

adifigure4.jpg

RTP Control Protocol (RTCP)

RTCP és un protocol complementari a RTP i s’usa per enviar informació de control, com a ara el número de paquets perduts, jitter, retard, etc. És molt útil per saber quina és la qualitat de la sessió que estem mantenint. Gràcies a la informació d’aquest protocol podem saber la necessitat que té la nostre xarxa de que li donem suport de QoS. O la necessitat de canviar els codecs que estem usant per ajustar-nos millor a les necessitats de la xarxa en la que treballem.

Codecs

A dalt de tot de la pila VoIP hi trobem els protocols encarregats de comprimir la informació que s’ha mostrejat de la font de digitalització (la nostre veu, imatges de video, etc). Els factors que determinen la eficència d’una codec són: el nivell de compresió (quan més comprimeixi millor), temps compresió i descompresió (quan menys trigui en fer el procés millor), suport a la perdua de paquets (capacitat de reproduir la informació original sense tenir tots els paquets en el destí), correcció d’errors, cost intel·lectual (cal pensar que no tots els codecs són lliures, n’hi ha molts de pagament).

Codecs d’audio:

  • G.711 (any 1988) estàndard internacional per la codificació de converses telefóniques. Usa 64kbps d’amplada de banda per cada conversa.
  • G.723.1 (any 1996) usa de 5.3 a 6.3kbps d’amplada de banda. És capaç de detectar la no activitat de la veu, per tal de consumir menys amplada de banda i també és capaç de generar soroll de confort (soroll necessari per saber que la trucada esta en curs i que no hi ha problemes a la línia). És força bo suportant perdua de paquets i en corregir errors de bits erronis. La família d’estàndards internacional per transportar video H.324 estableix aquest protocol d’audio com a estàndard per l’audio.
  • G.729 (any 1996) usa uns 8kbps d’amplada de banda, però també pot treballar amb 6.4kbps o 11.8kbps. Suporta detecció d’activitat de la veu i generació de soroll de confort.
  • GSM codecs de veu coneguts gràcies a la telefonia mòbil, definits per l’ETSI. L’amplada de banda que usen per treballar és d’uns 13kbps.
  • Speex és OpenSource i el varem desenvolupar a xiph.org. Capaç de treballar amb mostres de 8, 16 i 32kHz. Capaç de treballar amb amplades de banda de 2kpbs fins a 44kbps. A més és resistent als erros de la xarxa, suporta detecció d’activitat de la veu. A més també suporta variable-bit-rates, o sigui, pot adaptar el mostreix segons la complexitat dels sons a enviar, fins hi tot és capaç de soportar codificació en estereo.

Per acabar…

Amb aquest document ja em fet un repas a grans trets dels elements que composen una comunicació de VoIP. Quan ens diposem a configurar un sistema de VoIP trobarem moltes altres sigles, codecs, protocols, etc. però aquest document ens serveix com una referència bàsica sobre la que començar a treballar mentre anem adquirint experiència en aquest món tan interessant.

Bases de la VoIP

Reading time: 8 – 12 minutes

Des de fa un parell d’anys s’ha posat molt de moda parlar de Veu sobre IP (VoIP) però sovint comencem la casa per la taulada i de vegades val la pena tenir una referència on acudir per consultar com funciona tot plegat des de sota, així doncs amb aquest article espero poder explicar una mica que hi ha darrera d’aquest màgia. Després d’aquest article en tinc un altre preparat que és molt més aplicat i específic no tan teòric, parlant més a fons dels aspectes tècnics de la VoIP.

Com ja comença a ser habitual per escriure articles d’aquest tipus m’inspiro en articles escrits a Network Systems Design Line, concretament m’he inspirat en Voice over IP (VoIP)–The basics (local).

Quan parlem de VoIP ens referima un conjunt de serveis que pretenen oferir un servei telefonic tan a usuaris residencials com a empreses. A més la VoIP la usen els proveedors de serveis per transportar trucades entre ells. A més les empreses tan petites com grans la poden usar per comunicar les seves oficines. A més la VoIP es pot usar com a substitut o complement a la telefonia convencional.

Sovint les operadores telefóniques usen serveis de VoIP de forma transparent pels usuaris per tal de connectar les trucades entre usuaris. Així poden reaprofitar les seves infraestructures tan per transportar veu com dades simultaneament. La principal diferència entre els serveis tradicionals de telèfon i la VoIP és que el primer es basa en la conmutació de circuits i el segon en la conmutació de paquets. Així doncs quan connectem dues trucades de veu convencionals en el fons el que estem fent és connectar un cable d’un extrem de la trucada a l’altre. Això implica tenir els recursos de la xarxa reservats durant el temps que dura la trucada. Per tant, es fa un ús molt ineficient de l’amplada de banda disponible en aquest cable/circuit que esta connectat durant tot el temps de la trucada de forma permanent. Aquest problema es soluciona en la conmutació de paquets ja que es multiplexen les trucades en el temps i un mateix circuit pot transportar més d’una trucada de forma simultanea.

EFigure1.gif

Arribats en aquest punt ja tenim clar que l’ús de les xarxes de conmutació de paquets són més eficients si la densistat de trucades a transportar de forma simultanea augmenta. Perquè ens fem una idea les fibres òptiques transosceaniques poden transportar més de 100 milions de trucades cada una.

Components bàsics d’un servei telefónic

Bàsicament per tal de poder posar en funcionament un servei de telèfon fan falta els següents 4 components:

  • Senyalització es refereix a la comunicació entre el telèfon i el servei telefónic. Informa de que hem despenjat/penjat el telèfon, quin número hem marcat, que ens esta entrant una trucada, etc.
  • Conversa la veu que es transmet a través de la xarxa.
  • Funcionalitats trucada en espera, desviament de trucades, bústia de veu, etc.
  • Alimentació com enviem l’eletricitat al telèfon perquè funcioni. En els serveis telfónics convencionals aquesta alimentació l’ofereix la pròpia línea.

Senyalització en la VoIP

La senyalització es refereix bàsicament a com el telèfon es comunica amb la central telefónica. Però els conmutadors de xarxa intermitjos també han de reenviar-se aquestes senyals de control fins a arribar al teléfon de l’usuari. Així doncs cal entendre alguns tipus de senyalitzacions bàsiques.

Com un teléfon sap que volem fer una trucada? en el següent gràfic podem veure un esquema del procés. Quan despengem el telèfon, la central telefónica ens envia el to. Llavors marquem el número amb el que volem parlar, quan això passa s’intercanvien una serie de freqüències (o pulsos) entre el nostre teléfon i la centra telefónica per tal de comunicar a aquesta quin és el teléfon amb el que volem marcar. Llavors la central determina la ruta de la trucada que volem fer i notifica al destí que volem parlar amb ell, o sigui, es posa a sonar el teléfon destí.

EFigure2.gif

Fixeu-vos que en aquests senzills passos i que tots tenim tan clar ja hi ha una bona colla de senyalitzacions que han viatjat per la línia i encara no em començat la conversa. De tota aquesta idea hi ha un detall important, la part del sistema telefónic que hi ha dins de casa nostre no ha canviat des de fa 20 o 30 anys. Així tots els canvis s’han fet a la xarxa i de forma completament transparent pels usuaris.

Si un dels extrems de la trucada uses VoIP l’esquema podria quedar, per exemple, així:

EFigure3.gif

En aquest cas, el terminal telefónic esta connectata a un adaptador que el connecta a internet. Aquest adaptador actua com a traductor, converteix la nostre veu en paquets de tipus IP que s’envien a través d’internet. En aquest cas la senyalització és igual que en cas anterior, però l’adaptador es dedica a traduir les senyals analògiques en paquets que viatgen a través d’IP. Després el nostre proveedor de servei de VoIP convertirà aquests paquets en senyals altre cop compatibles amb la xarxa de teléfon convencional. Perquè el destí pugui entendre la trucada. Tot això serà completament transparent pels usuaris que no han de notar cap diferència.

Finalment si ens imaginem la senyalització entre dues trucades de VoIP, l’esquema quedaria així:

EFigure4.gif

El primer que salta a la vista és que ja no ens cal al xarxat telefónica convencional. Així doncs la senyalització digital que genera un extrem pot viatjar a través de la xarxa IP fins arribar al destí. Així doncs acabem de convertir el sistema de teléfon convencional en un sistema de dades IP completament. On no ens calen altre elements que els ja coneguts per les nostres xarxes de dades.

Com ho fa la VoIP per transportar una conversa

La veu humana esta composta per ones de so analògiques. Els sistemes de teléfon tradicionals transporten la veu com una successió de canvis de voltatge a través d’un parell de cables (s’anomenen senyals portadores). Quan aquestes senyals arriben a l’altre extrem el que fan és amplificar-se a través d’un altaveu, això produeix un so molt semblant al so original. En els sistemes de telefonia digitals (inclosa la VoIP), no tenim un circuit dedicat a transferir la veu. La veu humana es converteix en un fluxe digital (o series de 1s i 0s) que arriba fins al destinari on s’intenta re-generar els sons que van ser emesos per l’emisor. La converció analogic-digital de l’origen s’anomena mostreix (sampling), bàsicament es tracta de prendre una serie de mesures sobre els freqüències emeses per la veu a intervals de temps fixes. Després el que es fa és transportar aquestes mesures i no pas les freqüències emeses per la veu.

EFigure5.gif

Esquema dels processos de mostreix de la veu:

EFigure6.gif

La gràcia perquè la senyal origen s’assembli al màxim possible amb la de destí esta en prendre el màxim número de mesures possible. Però cal pensar que quantes més mesures es prenguin més mesures s’hauran d’enviar i més ràpida haurà de ser la línia de dades. Així doncs cal buscar un compromís entre la qualitat de mostres preses i l’espai que ocupen, per poder-les enviar prou ràpid.

Perquè tinguem quatre dades reals la freqüència més baixa que emet la veu humana és d’uns 100Hz i la més alta de 1700Hz. Entre els sorolls i les freqüències harmoniques que emetem més o menys necessitem uns 4000Hz com a molt agut. S’agafen unes 8000 mostres cada segon, o sigui, la freqüència de mostreix és d’uns 8KHz. Aquestes unitats de mesura capturades es posen dins dels paquets i s’envien cap al destinari on es generen les freqüències segons les dades que indiquen les mesures rebudes.

Alimentant les xarxes de VoIP

En les xarxes telefóniques convencionals com he dit l’alimentació electrica del teléfon s’agafa de la línia així doncs no ens hem de preocupar d’endollar el teléfon a la xarxa eléctrica de casa. Això que sembla una tonteria permet, per exemple, fer trucades telefóniques quan s’envà la llum. En un sistema digital això seria un greu problema perquè la línia no transporta l’alimentació del terminal telefónic.

EFigure8.gif

Per tant, quan marxa la llum amb un sistema digital no podem fer trucades si s’envà la llum. Això suposa un gran problema ja que en cas d’emergència no ens podem comunicar. Així doncs, cal que pensem en algún sistema d’alimentació alternatiu per quan en cas d’emergència haguem d’usar el teléfon o quedarem aïllats.

Resumint

Escencialment la forma de trucar no ha canviat per l’usuari. Però si que els processos tècnics que composen el procés de fer una trucada han canviat moltíssim internament i tecnològicament ja no té res que veure un sistema de telefonia convencional amb els nous sistemes de telefonia de VoIP. Així doncs el que abans era un problema pels enginyers de telecomunicacions, ara és un problema pels enginyers de xarxes.

Thomson ST2030: la meva recomanació en tlf IP professionals

Reading time: 1 – 2 minutes

Dissabte vaig estar amb el Marc provant el Thomson ST2030. Només volia comentar que realment és el telèfon de VoIP més professional que he tocat parlant de gama professional baixa. Molt millor que els Cisco de gama baixa i més econòmic. Fins ara haviem provat molts telèfons xinesos d’aquests que no coneixen ni a casa seva. Però realment tenien moltes deficiències sobretot a nivell de so i de qualitat de firmware.

st2030.jpg

Si voleu aprofundir en les característiques del telèfon el datasheet esta prou bé a nivell de detalls. Sobre el tema de la qualitat de so i l’experiència a nivell d’usuari inmillorables. El preu es pot treure una unitat per poc més de 100€ i si compreu volum per una mica menys de 100€.

UTStarcom F1000

Reading time: 3 – 5 minutes

Ahir vaig estar jugant una estona amb el F1000, per fi l’he pogut configurar perquè treballi amb l’asterisk i fer proves de roaming al canviar d’AP enmig d’una trucada.

utstarcom.jpg

Configurant-lo per Asterisk

Doncs bé configurar-lo a l’asterisk té el seu truquillo. Perquè jo no acostumo a usar un parell de paràmetres que són indispensables perquè es pugui registrar el tlf com a extensió SIP. Aquí us poso la meva configuració al fitxer sip.conf:

[ebosc112]
type=friend
username=ebosc112
secret=ebosc112
host=dynamic
dtmfmode = rfc2833
callerid = "ebosc112" <112>
context=sip
mailbox=112
context=usuaris
defaultip=192.168.27.122

No acostumo a posar la defaultip a cap extensió SIP, però degut a que el tlf quan fem molts salts entre APs a vegades queda desregistrat de la PBX això m’ajuda a que pugui rebri trucades malgrat no està registrat. Tot i resoldre el problema de rebre trucades no serveix per solucionar el problema de no poder trucar per no estar registrat i s’ha d’apagar el terminal i tornar-lo a encendre. Sort que va ràpid, uns 20seg.

Quan configureu el tlf tot s’ha de fer normal tal i com explica el manual, només comentaré la part de configurar el SIP que és on es fa una mica més complicat.(us comento la meva configuració)

Anem al menú de configuració SIP: MENU->WiFi Settings->Signal Protocol->SIP

Usem IP per referir-nos al servidor SIP: SIP Proxy Mode->IP

Definim IP del servidor SIP: SIP Proxy IP address->192.168.1.1

Usem IP per referir-nos al servidor SIP: SIP Proxy Mode->IP

Definim el nom d’usuari SIP: SIP User Name->ebosc112

Paraula d’accés al servidor SIP: SIP Authentication String->ebosc112

Paraula clau d’accés al server SIP: SIP Password->ebosc112 per introduir aquesta paraula hi ha ‘truquillo’ ja que en principi el tlf ús demana un codi numeric que es mostrarà per pantalla amb ‘*’ el codi de desbloqueix per poder escriure el ‘password’ heu de posar ‘888888’. Llavors saltarà a una altre pantalla que us deixarà escriure el password.

Doncs bé tota la problemàtica venia perquè aquest útlim detallet que he comentat no ho posava al manual i ho he trobat al forum de suport a l’usuari d’UTStarcom. Una suada per trobar això 😉

Roaming

Com sabeu el que realment m’interessa és poder anar saltant entre diferents APs sense que es tallin les trucades. Doncs bé tot i el gran resultat obtingut amb el Cisco 7920 aquest terminal triga una mica més a fer el canvi d’AP i almenys durant uns 5s es perden paquets i es per la veu de la trucada, tot i que per sort no es talla la trucada.

També he fet una prova una mica més radical i és que quan estic sota la cobertura de dos APs si apago un dels APs he comprobat que la trucada es talla i que el telèfon no es registra altre cop fins que no l’apaguem i l’encenem de nou.

Valoració

Malgrat va prou bé i les trucades se senten força bé i el rendiment de la bateria és molt bo. Cal dir que després de tocar el Cisco 7920 es nota que l’UTStarcom F1000 costa 1/5 part que el Cisco. Tot i que com dic és un terminal molt recomanable ja que la relació qualitat preu és molt bona.

El proper objectiu és provar el Zyxel que segons m’ha dit el Xoli a MicroBR el tenen en súper-oferta per 130¤, pensant que abans valia més de 300¤ la diferència és substancial… bé ja us comentaré quan el provi.

Sembla que hagin passat els reis

Reading time: 2 – 3 minutes

Després de les proves amb el Cisco 7920, el tlf wifi amb el que vaig estar fent roaming. Em quedava provar un cosa important que ja vaig comentar a l’article, per tal de posar solució a la prova avui ha arribat el UTStarcom F1000 el tlf wifi de VoIP que usa peoplecall pels seus serveis. Així que aprofitant la oferta de 130¤ que tenen pel terminal n’hem comprat un pel projecte que tenim entre mans.

utstarcom.jpg

Per aquest mateix projecte també m’han arribat un parell de meravelles de la tecnologia que podeu veure a continuació. Per un costat la intel PRO/1000 MT una targeta de xarxa de 4 ports a 10/100/1000 que ens permet tenir en un slot PCI64 (PCI-X) 4 targetes de xarxa. Quina pijada,eh!? doncs si, no ha estat pas per gust que ens hem gastat més de 400¤ en aquest coi de targeta sinó perquè el server Dell PowerEdge 800 que hem comprat pel projecte només té una PCI32 i 2xPCI64 quina ràbia quan al obrir-lo vaig haver de tornar les 4 NIC 10/100 PCI32 de tota la vida que per dos duros fan la mateixa feina.

intelquad.jpg

Finalment la peça més important per montar l’Asterisk com a PBX per l’empresa del client. Una Junghans quadBRI amb 4xBRI RDSI que donen fins a 8 canals de veu simultanis i només ocupa un slot PCI32. L’hem comprat a avanzada 7 i costa uns 625¤ despeses i impostos apart.

isdnquad.jpg

Cisco 7920 + Asterisk in roaming across 2x WRT54G

Reading time: 6 – 9 minutes

De fet, per fer això en principi no cal cap 7920 de Cisco, ja que amb qualsevol altre tlf wifi en teoria hauria de funcionar. El problema és que de moment només teniem aquest a mà. El tema és molt senzill voliem comprobar com canviant l’associació d’un AP (Linksys WRT54G) a un altre AP no perdiem la trucada en curs i que els problemes de l’enllaç eren mínims. Això és el que us intentaré explicar molt breument en aquest article. Per què molt breument? doncs perquè és realment molt senzill de fer.

2xwrt54.jpg

Doncs bé conceptualment el tema és molt senzill. Un cop tenim connectat el tlf VoIP WiFi (Cisco 7920) a l’Asterisk, al final del fitxer comento ràpidament com es configura, només cal ocupar-se de la configuració dels APs. Per tal de que quedi clar el que volem montar a continuació us adjunto un petit esquema que he fet:

Configurem els APs

Els Linksys WRT54 porten per defecte un bridge fet entre els 4 ports ethernet de la LAN i la connexió WLAN. Així doncs només cal que desactivem el tràfic internet/wan perquè tinguem un AP en mode bridge. És important tenir el mateix SSID i posar els APs en diferents freqüències, nosaltres hem usat un AP al canal 1 i l’altre al canal 6. Si posem els dos APs en el mateix rang de xarxa i a més treballem amb IP estàtica, no ho hem provat amb DHCP. Ja ho tenim tot apunt perquè quan iniciem una trucada associats en l’AP1 no hi hagi talls a la conversa al desplaçar-nos a la zona de cobertura del l’AP2. Com a molt notarem que es perd durant menys d’1s la veu però ràpidament funcionarà tot igual que si no haguessim canviat d’AP.

Si tanquem els ulls un segon i somiem això a la ‘n’, podriem montar cobertura en una zona molt extensa amb telèfons wifi, teoricament molt senzills que funcionarien perfectament en tot l’espai de cobertura imaginat. Us sona d’algo això??? potser a la xarxa GSM? 😉 Quan parlo de telèfons molt senzills em refereixo a tlf que només suporten un SSID i que no saben res de protocols tan sofisticats com el WDS (Wireless Domain Services) de Cisco, no confondre amb WDS: Wireless Distribution System que implementen molts APs, el qual ens permet treballar amb FSR (Fast Secure Roaming de Cisco).

Si voleu més informació d’aquestes meravelles que s’inventa Cisco i que l’únic problema és que no són prou estàndards com per disfrutar-ne, podeu llegir-vos el document: Configuring WDS, Fast Secure Roaming, and Radio Management ( cache).

Seguretat

En les proves que hem fet no hem usat ni WEP, ni LEAP que són els dos sistemes de seguretat suportats pel telèfon. De fet, tota la seguretat l’hem basat només en la MAC i la IP del telèfon. A més com es pot veure en el gràfic enmig de la xarxa WIFI hi ha un firewall el qual ens permet a més deixar que només passi tràfic SIP+RTP cap a l’asterisk. Amb això considerem més que suficient la seguretat per l’entorn que hem fet les proves. Així podem ser menys exigents en les característiques dels telèfons a usar. Ja que la intenció no és gastar-nos 600¤ (preu del Cisco 7920, aprox) en cada telèfon que posem a la xarxa.

De fet, una idea que es vol provar és aprofitar el telèfon Wifi SIP de PeopleCall que es pot obtenir per 130¤ amb l’alta al servei de d’aquesta operadora IP inclosa.

wifipromo.gif

Configurar el Cisco 7920 amb l’Asterisk

Aquest telèfon seguint la línia de Cisco usa un munt de protocol propietaris i en aquest cas la cosa arriba a tal extrem que ni tan sols usa SIP. Així que varem haver de configurar l’asterisk amb suport SCCP (Skinny Client Control Protocol). El qual no es suporta de serie amb l’Asterisk.

A voip-info teniu un HOWTO del SCCP ( cache). És un bon punt d’inici. Cal que penseu en tenir instal·lat un servidor tftp en algún lloc de la xarxa ja que els Cisco el necessiten per agafar la configuració de veu al arrancar. Un bon manual per configurar el atftp en gentoo: Gentoo Linux based Netboot HOWTO (cache)mireu-vos només la secció: The tftpd Daemon.

Després de fer el que comentem anteriorment el problema més greu que teniem és que no podiem fer trucades només rebre-les. El problema esta en el codi del sccp que necessita 7 ‘patches’ per funcionar correctament, sembla broma però és així. Si voleu anar directa al gra, us recomano que us baixeu el paquet que jo he usat: chan_sccp-mayday05+patches amb els pegats i el binari per la versió 1.0.7 d’asterisk. Un cop descomprimit el paquet si no heu de recompilar només cal que copieu el chan_sccp.so a /usr/lib/asterisk/modules. La pàgina web on podeu seguir les noves versions del chan_sccp per l’asterisk és: chan_sccp Project.

No oblideu a afegir a /etc/asterisk/modules.conf:

load => chan_sccp.so

Amb tot això ja podem tenir el Cisco 7920 funcionant amb l’Asterisk.

Truquillo

Com podeu veure a la foto dels dos linksys que hem usat per temes d’espai els hem posat un sobre l’altre el que feiem per simular les dues arees de cobertura era molt senzill. Teniem un linksys configurat amb el màxim de potència i l’altre amb el mínim. Apagabem el de màxima potència perquè el tlf s’associes al de mínima potència. Un cop fet això establiem una trucada i amb la trucada en curs, enceniem el segon AP, el de màxima potència, el canvi d’AP no es fa fins que l’AP associat no té problemes de cobertura amb el terminal així l’únic que haviem de fer era posar-nos a caminar fins a perdre la cobertura i notar aquest ‘micro-tall’ que ens indicava el canvi d’AP. A més mirant els menús del tlf i dels linksys verificabem que el canvi efectivament s’havia fet sense problemes.