Substituts wireless dels cables USB
Actualment s’esta treballant en tres línies a l’hora d’elminar els cables del PC, normalment USB, el típic cable de ratolí, telcat, impresora, escaner, camara de fotos, etc. Totes les solucions són usant com a tecnologia de radio el UWB (wikipedia: UWB). De fet, durant aquest gener la IEEE va decidir desistir en l’estandarització d’aquesta tecnologia que havia de ser l’estàndard 802.15.3a. Però múltiples desacrods en el grup de treball van acabar en la conclusió de que no s’entandaritzaria.
Doncs bé les tendències en les que s’estan treballant per tal de substituir els cables del PC als periferics són:
- 1. Convertir directament les dades serie de l’USB en senyals de radio d’Ultra-Wideband(UWB). Ni els dispositius USB ni els host USB necessiten cap canvi ja que tot és completament transparent a nivel d’USB.
- 2. Usar només els connectors USB, però re-empaquetar totes les dades amb un altre protocol, per exemple TCP/IP. Així doncs la comunicació per aire es fa sobre aquest nou protocol, quan arriba al destí es re-converteix a USB. Així es manté compatibilitat amb els dispostius. Excepte les que usen el mode isochronous.
- 3. Consisteix en redissenyar l’USB internament fins hi tot els sistemes electrònics. Només mantenint compatibilitat en les aplicacions però re-fent tots els drivers de host i de dispositius.
Si voleu aprofundir més en la discusió podeu llegir l’article Making USB without wires work for consumers (local).
Hardware
Alguns dispositius que ja implementen alguna de les tècniques explicades anteriorment:
- CableFree USB Hub and Dongle (set) (F5U301) (~130$)
- Y-E Data HUB USB inal·làmbric (~200). 100Mbps a una distància màxima de 10m.
- USB Server (~129$)
Transistor LM3940 – de 5v a 3’3v
No sé d’on el puc treure que no sigui a l’estranger però l’hauré de buscar, el tinc al cap des de fa dies i per casualitat acabo de trobar la seva pàgina. Què té d’especial aquest transistor? doncs simplement que és el que passa de 5v a l’entrada a 3’3v a la sortida. Serveix per exemple, per alimentar a través d’USB un transmissor FM que tinc i així no he d’estar posant-li piles cada 2×3. Quan m’animi a fer l’inventillo ja el penjaré aquí.
A continuació podeu veure un simple gràfic de com usar-lo:
I fins hi tot un esquema de com és físicament, de fet, no té més. Simplement un transistor lineal.
Web on l’he trobat: LM3940 – IA Low Dropout Regulator for 5V to 3.3V Conversion.
symfony: protegint els entorns de desenvolupament, integració i producció
A l’article symfony: entorns de desenvolupament, integració i producció es pot entendre el perquè de treballar amb aquests tres espais de noms (environment) així doncs el que es preten explicar és:
- Impedir accés a les aplicacions en entorns de ‘dev’ i ‘int’ des de llocs no controlats. O sigui, que una IP d’internet no pugui executar myapp_dev.php o myapp_int.php però encanvi una IP de la xarxa del desenvolupador si que pugui.
- Impedir accés a aplicacions de backend des de l’entorn de producció. Si hem desenvolupat alguna aplicació per tal de fer el manteniment de l’aplicació principal, una part d’administració o backend aquesta no sigui accessible des d’IPs no controlades.
- Separar el fitxer de configuració config/cofnig.php per cada un dels entorns. Així podem definir constants o d’altres tasques de forma particular per cada un dels entorns.
Per tal d’aconseguir aquests objectius he creat el fitxer config/config.lib.php:
<?php
/**
* Comproba si la IP amb la que s'accedeix a l'aplicació permet connectar en aquest environment
*
* @param string $env nom de l'environment
* @param array $ips ips des de les que podem accedir a l'environment
* @param string $clientip ip del client que vol accedir al recurs
*/
function envCorrecte ($env,$ips,$clientip)
{
if (SF_ENVIRONMENT==$env)
{
$acces=0;
foreach($ips as $ip)
{
$ipclient=substr($clientip,0,strlen($ip));
if ($ipclient==$ip)
{
$acces=1;
}
}
if ($acces==0)
{
echo "You are not in '".$env."' environment! (".$ipclient."<>".$ip.")";
exit;
}
}
}
/**
* Comproba si l'aplicació amb la que s'accedeix al projecte és publica o no
*
* @param array $apps llista d'aplicacions no públiques
* @param array $ips llista d'IP amb les que es pot accedir a les apps no públiques
* @param string $clientip ip del client que vol accedir al recurs
*/
function appCorrecte ($apps,$ips,$clientip)
{
// solucionem problema de la clau '0'
$apps_aux[0]='';
$apps = $apps_aux + $apps;
//
if (array_search(SF_APP,$apps)!=false)
{
$acces=0;
foreach($ips as $ip)
{
$ADR=$HTTP_SERVER_VARS['REMOTE_ADDR'];
$ipclient=substr($clientip,0,strlen($ip));
if ($ipclient==$ip)
{
$acces=1;
}
}
if ($acces==0)
{
echo "Keep away! ".SF_APP." is not a public application!";
exit;
}
}
}
?>
Llavors des del fitxer config/config.php cal que cridem aquesta petita llibreria de funcions que he creat. La resta és més que lògica, aquí en teniu un exemple:
<?php
include("config.lib.php");
/**
* Controlem accés als 'environments' de 'env' i 'int'
*/
$ip_dev=array("10.138.0.","192.168.");
$ip_int=array("10.138.0.","192.168.");
envCorrecte('env',$ip_env,$HTTP_SERVER_VARS['REMOTE_ADDR']);
envCorrecte('int',$ip_int,$HTTP_SERVER_VARS['REMOTE_ADDR']);
/**
* Controlem accés a les 'apps' d'ús privat
*/
$ip_apps=array("10.138.0.","192.168.","w.x.y.z");
$apps=array('myapp_1','myapp_2','myapp_n');
appCorrecte($apps,$ip_apps,$HTTP_SERVER_VARS['REMOTE_ADDR']);
/**
* Carreguem el fitxer de configuració propi de l'"environment".
*/
include("config.".SF_ENVIRONMENT.".php");
/**
* Part comú en els 3 entorns
*/
?>
Com podeu veure el codi és molt senzill i la potència i el dinamisme, excepcionals.
Aquest codi també l’he publicat com un snippet a Access control to environment and applications and custom global config file for an environment.
symfony: entorns de desenvolupament, integració i producció
Al desenvolupar un projecte de software m’agrada treballar en 3 entorns. Mentre s’esta desenvolupant el projecte esta bé tenir un espai de variables (o entorn de noms) a l’aplicació que correspongui als ajustaments del servidor de desenvolupament (normalment una màquina pròpia), per exemple, els path, urls, dades de la bbdd, etc. tot això ha d’estar el màxim separat possible del codi per tal de poder crear les configuracions pels entorns d’integració i producció.
L’entorn d’integració és una màquina en l’entorn de desenvolupament del client, amb les característiques el més semblants possibles a l’entorn de producció. O sigui, les dades de configuració de l’espai de noms han d’apuntar a serveis si pot ser de la mateixa versió que l’entorn de producció. Així podem provar l’aplicació i millores de l’aplicació abans de passar-la a producció. Finalment hem de tenir l’entorn de noms per producció amb les dades de treball.
Per tal de suportar tot això symfony suporta en moltíssims fitxers de configuració la possibilitat de definir l’environment, en el cas que plantejo, ‘dev’, ‘int’ i ‘prod’. En el front controller de cada aplicació podem definir aquest entorn de noms així després s’accedirà a la part dels fitxers de configuració que pertoca.
Per exemple, si mirem el fixer config/databases.yml on symfony defineix els sistemes de BBDD que usa la nostre aplicació en cada un dels environments podriem tenir algo així:
dev:
nombbdd:
class: sfPropelDatabase
param:
phptype: mysql
hostspec: localhost
database: nombbdd
username: userbbdd
password: passbbdd
int:
nombbdd:
class: sfPropelDatabase
param:
phptype: oracle
username: nombbdd
password: nombbdd
hostspec: hostint
database: NULL
prod:
nombbdd:
class: sfPropelDatabase
param:
phptype: oracle
username: nombbdd
password: nombbdd
hostspec: hostprod
database: NULL
Al cridar el front controller és quan symfony diu amb quin environment treballarem, per exemple, per una aplicació anomenada myapp podriem tenir aquests tres front controllers un per cada entorn:
Entorn de desenvolupament web/myapp_dev.php:
<?php
define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'myapp');
define('SF_ENVIRONMENT', 'dev');
define('SF_DEBUG', true);
#
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
#
sfContext::getInstance()->getController()->dispatch();
?>
Entorn de integració web/myapp_int.php:
<?php
define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'myapp');
define('SF_ENVIRONMENT', 'int');
define('SF_DEBUG', true);
#
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
#
sfContext::getInstance()->getController()->dispatch();
?>
Entorn de producció web/myapp.php:
<?php
define('SF_ROOT_DIR', realpath(dirname(__FILE__).'/..'));
define('SF_APP', 'myapp');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG', false);
#
require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
#
sfContext::getInstance()->getController()->dispatch();
?>
Com es pot veure, tan desenvolupament com integració ens mostraran informació de debug i producció amagarà els missatges d’error i reportarà sempre l’error “internal server error”. A més podem veure que tots tres entorns criden el mateix fitxer de configuració global config/config.php.
Si voleu més informació sobre aquest tema us recomano els següents enllaços de la documentació de symfony:
Com funciona la VoIP: protocols, codecs i altres
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.
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.
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:
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.
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
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.
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í.
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í:
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í:
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.
Esquema dels processos de mostreix de la veu:
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.
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.