Category: Networking and Internet

Nous gadgets que corren per casa

Reading time: 7 – 12 minutes

El que faré en aquesta entrada és un petit recull de comentaris sobre els últims dispositius que hi ha per casa.

Consola Wii + Wii Fit + Wii Motion Plus

Wii

Mai m’havia imaginat que em compraria una consola, de fet, tècnicament tampoc ho he fet ja que va ser un regal que li vaig fer a Estefania pel seu aniversari a finals de maig. Però com ja era la idea és un regal que disfrutem tots dos. Realment és un concepte totalment diferent del que jo havia entès sempre com a consola. Sota el meu punt de vista és una eina d’entreteniment que dona un punt d’interactivitat tan innovador que potser fins hi tot li caldria un nom diferent, enlloc de ser una consola més.

Wii Fit

Si ens fixem en l’ús que jo li dono, fins hi tot podriem anomenar-ho màquina de fer esport. Per sort no només faig esport amb la Wii, però he de dir que entre els 30min de footing que faig dia si dia no, més el control del meu IMC que hem permet portar la Wii Fit i la experiència brutal que em dona el Wii Motion Plus quan jugo al Virtua Tennis 2009 és una màquina de fer esport molt entretinguda i a sobre m’ajuda a mantenir-me en forma.

Wii Motion Plus

A més no cal oblidar la component social, crec que és una consola ideal per disfrutar amb els amics i deixar de banda els sovint aborrits jocs de taula. Segur que hi ha molta gent que no es cansa mai de jugar al parxís o a la oca; però jo de ben petit sempre he tingut repelús a aquest jocs, fins hi tot quan no sabia ni el que era un ordinador.

Archos 5 + DVR Station Generation 6

De fet l’Archos5 ja fa molts dies que corre per casa, fins hi tot hauria de dir pel món. Ja que com a dispositiu portàtil per això va ser pensat per emportarte’l pel món. Com passa sovint amb aquests gadgets Estefania els disfruta sobretot quan anem de viatge, però jo en el meu dia a dia l’uso per ambietar les meves jornades de treball o per animar els viatges que faig a Barcelona.

Els seus 120Gb de disc dur trobo que són ideals, mai els he trobat excessius com a molt algún cop n’hagués volgut més. Ja que sempre es pot usar com a disc dur portàtil. Potser una cosa que no m’agradam massa és que no puc usar la funció de dispositiu mass storage (disc dur extern) mentre reprodueixo música. Trobo que seria ideal tenir-lo connectat al portàtil mentre treballo i escolto musica, de forma que quan tingués alguna cosa que copiar-me per emportar: PDFs, més música, podcasts, etc. ho fes directament. Però no es pot tenir tot.

He de dir que les funcions que més uso quan viatjo són les de veure videos, escoltar música i llegir PDFs. Aquesta última funció és un pel lenta pel meu gust però sovint l’utilitzo ja que sempre porto una bona col·lecció de llibres tècnics que no puc evitar fullejar o fins hi tot llegir. Això si, no ús recomano fer-ho més d’1h seguida ja que és força dur per la vista les 5″ de la pantalla tampoc donen per tan.

Archos5 DVR Station

Pel que fa a la DVR station només fa unes setmanes que la vaig comprar, obviament la tenim al menjador i gràcies al seu comandament a distància més que complert l’usem per veure pel·lícules o per posar música usant la TV del menjador. L’usabilitat del comandament a distància és bona en general, potser el problema més greu és que el ratolí (per dir-li d’alguna forma) que incorpora el comandament és força inusable però això només cal usar-ho si volem navegar per internet.

Archos5 DVR Station Generation 6 - Remote Control

Pel que fa a l’accés del contingut que tinc a la xarxa es fa via UPnP i el servidor UPnP que tinc instal·lat al meu NAS (Openfiler) és el Mediatomb, cosa que de moment m’està donant una serie d’inconvenients que no he resolt. Per un costat, a l’hora de buscar contingut em mostra tot el media en una sola carpeta, cosa força inusable degut a la quantitat. Malgrat això és culpa de que el servidor UPnP exporta el contingut de forma poc òptima per defecte, hauré de mirar de configurar-lo millor. L’altre inconvenient és que si reps un contingut via UPnP no pots usar les funcions de ‘fast-forward’ i ‘rewind’ cosa realment molesta en moltes ocasions.

Archos5 DVR Station Generation 6 - Connections

Comentar també que la radio per internet que té instal·lada l’Archos5 és un programa que es diu vTuner i que malgrat té molt contingut i molt ben ordenat, entre el qual he trobat emisores que m’agraden molt també trobo molt a faltar el no poder usar eines d’internet com Spotify o LastFM. Cosa que a priori semblaria suportada perquè l’Archos5 suporta Flash tan en pàgines web com en aplicaciones standalone però no és capaç de reproduir cap de les coses que he comentat.

HTC Hero

htc hero

Finalment l’últim gadget a comentar és el mòbil que he adquirit: HTC Hero en lloc del HTC Touch Cruise que he tingut fins ara. De fet, no ha estat un canvi per gust sinó obligat ja que en un sopar a la fresca d’aquest estiu el mòbil va desapareixer i per tant vaig haver de buscar-me la vida. Així doncs, després d’una bona oferta per part d’Orange vaig adquirir aquest terminal.

Comentar que per fi sóc lliure! ja no depenc del coi de Windows Mobile que això més que un sistema operatiu era un mal son. Android no és la perfecció però em dona moltes alegries i bones experiències cada dia. Cosa que no es pot dir del anterior sistema.

Sobre el terminal comentar que aquesta petita curva que fa en la part inferior i que tanta por em feia que es convertís en una incomoditat, almenys per mi, s’ha acabat convertint en una comoditat ja que quan porto el terminal a la butxaca aquest s’adapta millor a la forma del cos.

Com a inconvenient comentar que la pantalla tàctil és una mica difícil d’usar quan tens les mans suades o humides de la calor o algún altre motiu. Sort del trackball que sovint ens facilita la vida. Això si, quan tens les mans ben seques la usabilitat tàctil del terminal és genial i el teclat virtual quan girem el terminal és realment còmode d’usar.

Per buscar-li coses negatives comentar que la cobertura GSM a vegades va i ve, sense massa explicacions i malgrat et diu que tens cobertura sembla que a qui et truca li diu que no estas disponible. Encara he d’acabar de validar si aquest problema és degut a la cobertura que hi ha a casa meva o bé, és realment un problema del terminal. Aquesta propera setmana tindré un altre teminal d’Orange per temes de feina i així ho podré contrastar.

Ubuntu Hardy (8.04) i monit 4.10.1

Reading time: 15 – 25 minutes

El paquet .deb de la versió 4.10.1 del monit no esta disponible per Ubuntu Hardy (v.8.04) el paquet més nou disponible és el 4.8 el problema més greu que suposa això és que no podem usar com servidor de notificacions servidors SMTP sense SSL, per exemple, no es pot usar smtp.gmail.com (gmail.com).

Si voleu instal·lar el paquet 8.10.1 el que s’ha de fer és:

cd /var/tmp
wget http://es.archive.ubuntu.com/ubuntu/pool/universe/m/monit/monit_4.10.1-3_i386.deb
sudo dpkg -i monit_4.10.1-3_i386.deb
monit -V

i veurem l’esperat:

This is monit version 4.10.1
Copyright (C) 2000-2007 by the monit project group. All Rights Reserved.

En cas de voler enviar els correus a gmail la configuració seria algo així:

set mailserver smtp.gmail.com port 587
    username [user]@gmail.com password [pass]
    using TLSV1
    with TIMEOUT 20 seconds

pkg-config: controlant les llibreries que tenim instal·lades

Reading time: 9 – 14 minutes

pkg-config és una eina que ens ajuda quan hem de compilar aplicacions i llibreries. Permet descobrir les opcions que s’han d’afegir al compilador.

Alguns exemples ràpids de coses que podem fer:

# descobrir llista de llibreries que tenim instal·lades:
pkg-config --list-all
# cflags per una lliberia concreta
pkg-config nom_llibreria --cflags
# llibreries a incloure al compilador per una llibreria concreta
pkg-config nom_llibreria --libs

Glosari de Telepathy

Reading time: 3 – 4 minutes

Abans que res una petita introducció a: Què és Telepathy?

Es tracta d’un framework que unifica diferents sistemes de comunicació en temps real. Usa DBUS com a interficie de comunicació entre aplicacions.

Avantatges de Telepathy:

  • Temps real: suporta sistemes IM (un-a-un i grups), video trucades i trucades de veu.
  • Unificat: permet que diferentes aplicacions i de forma simultànea s’aprofitin de les capacitats del sistema i que treballin de forma col·laborativa.
  • Framework: disecciona el sistema de comunicacions en petites parts i les fa tan simples com pot perquè al usar-les contjuntament el procés de comuncació sigui el més senzill possible.

El glosari de termes, en poques paraules el que cal tenir en ment i recordar quan parlem de Telepathy.

  • MUC (multi user chat): o també anomenat chat room, o canal de xat.
  • Mission Control: responsable de la gestió de comptes de missatgeria: creació de connexions i manteniment dels estats de presència dels contactes.
  • Glabbe: és un connection manager de Jabber.
  • Tapioca: és un framework per VoIP i aplicacions IM. Suporta SIP/XMPP.
  • Farsight: idem que el Tapioca, però orientat a videoconferències.
  • Stream Engine: exporta les funcions de Farsight a DBUS. i viceversa.
  • Tubes: és el mecanisme que usa Telepathy per suportar transferència de dades entre aplicacions remotes, o sigui: remote IPC. La idea que hi ha darrera és “si dues persones connectades a un servei de IM poden parlar, perquè dues aplicacions connectades a un IM no poder intercanviar informació”.
  • Stream Tubes: és un mètode de transport usat per Telepathy molt similar al SOCK_STREAM sockets: enviament de paquets ordenat i confiable.
  • IB (in-band): quan els ‘Tubes’ usen el servidor de missatgeria per intercanviar dades. Aquest sistema pot ser molt lent per transportar depèn quin tipus d’informacions, per exemple, sessions VNC.
  • OOB (out of band): els ‘Tubes’ de dades usen diferents camins fora de la xarxa XMPP, per exemple, connexions directes entre peers via UDP o TCP.
  • Empathy: es tracta d’un client d’IM programat usant les llibreries de Telepathy.
  • XEP-0095 Stream Initiation: aquesta especificació defineix una extenció d’XMPP que iniciar fluxes de dades entre dos entitats connectades a la xarxa XMPP. El protocol soporta la possibilitat d’incloure metadades sobre el fluxe de dades a intercanviar.
  • XEP-0065 SOCKS5 bytestreams abstract: es defineix una extenció d’XMPP per establir connexions OOB entre dos peers, la connexió entre els peers pot ser directe o via un proxy SOCKS5, en principi la idea és usar TCP per aquests tipus d’enllaços malgrat també podria funcionar per UDP.
  • XEP-0163 PEP (Personal Eventing Protocol): defineix la semàntica d’un protocol que usant les funcions publish-subscribe d’XMPP dinfon els canvis d’estat i presencia. D’aquesta forma podem fer funcionar l’estat d’una compte com si es tractés d’un servei pubsub; simplificant la possibilitat de sindicar-nos a dades i notificacions associades amb aquella compte. Un exemple, per fer-ho més entendor: podem tenir un servei d’agenda que ens avisa que hem de fer certes coses si és que estem disponibles però si en canvi este ausents no té sentit que ens avisi.
  • XEP-0080 User Location: és una extenció per permet enviar informació sobre la posició geogràfica de l’usuari.

XMPP amb BOSH: usant HTTP com a protocol de transport

Reading time: 4 – 7 minutes

La potència de treballar amb BOSH (Bidirectional-streams Over Synchronous HTTP) rau en que malgrat aparentment l’única forma que hi ha d’implementar XMPP sobre HTTP seria mitjançant tècniques de polling, o sigui, que periódicament el client anés connectant-se al servidor per preguntar si hi ha alguna nova informació per ell.

Doncs BOSH aconsegueix millorar aquest algoritme i el que intenta descriure és quelcom així:

  1. El client fa una connexió ‘HTTP request’ al servidor
  2. El servidor no envia cap resposta, així doncs, la connexió no es tanca.
  3. Quan el servidor té una informació (asíncrona) a enviar al client, llavors busca alguna connexió oberta del client i que estigui esperant resposta, o sigui, qu estigui al punt 2. Llavors el que fa és enviar l’informació a través d’aquesta connexió com una ‘request response’. La connexió es tanca.
  4. Un cop el client rep l’informació inmediatament després de tancar-se l’enllaç, aquest torna a obrir una connexió contra el servidor, o sigui, tornem al punt 1.

Obviament quan el client té alguna cosa a enviar això es fa en el punt 1.

A l’hora de la veritat els servidors de Jabber/XMPP el que tenen per oferir accés via BOSH és un especie de proxy que rep les connexions HTTP i les processa tal com he explica més amunt, per l’altre costat captura els events que rep de cada un dels clients XMPP que esta instanciant i va connectant els fluxes de dades que rep a través d’XMPP als sockets HTTP que té esperant informació.

Servidors BOSH incrustats en servidors XMPP

Obviament això ens porta a pensar, que podem usar un servidor BOSH per un servidor XMPP que no el suporti a mode de proxy. Això es podria programar de forma força senzilla amb twisted, per altre banda, hi ha servidors XMPP que ja suporten de serie el servidor BOSH, alguns exemples són: ejabberd, Tigase, Openfire i Jabber XCP.

Avantatges de tenir el servidor BOSH dins del servidor XMPP:

  • Sovint esta més ben testejat que el codi que podem fer-nos o que ha desenvolupat un tercer per fer aquesta tasca.
  • A priori hauria de ser més eficient, ja que la part de recepció d’events/senyals es fa a través de l’API nativa i no pas d’un client XMPP. Cosa que permet estalviar recursos i ser més eficient en la seva tasca.
  • És més fàcil de configurar, sovint només cal descomentar la línia corresponent del fitxer de configuració i llestos.

Com que no tot podien ser avantatges aquí van els inconvenients:

  • Un servidor BOSH que esta incrustat en un servidor XMPP obviament només pot atendre les peticions que van cap aquell servidor, per tant, si volem que això sigui escalable haurem de montar un balencejador de càrrega sobre el port HTTP per anar desviant connexions entre diferents sevidor BOSH.
  • El suport del servidor BOSH esta lligat al suport que la comunitat doni al servidor XMPP amb el que va lligat, això no sempre és suficient.

Quan no hem de suportar més d’un servidor XMPP, i a més aquest ja suporti BOSH no hi ha hauran mai problemes. La cosa es complicarà quan haguem d’escalar aquesta infraestructura.

Servidors BOSH dedicats, per tant independents del servidor XMPP

Per exemple: Punjab, Araneo, JabberHTTPBind i rhb. Pel que fa les avantatges i desavantatges d’aquest tipus de servidors BOSH, obviament són les mateixes que les anteriors però invertides.

Un servidor BOSH dedicat, per tant, podrà connectar-se a una xarxa XMPP a través d’un servidor XMPP federat sense problemes. Sovint el preu de sobrecarrega que això suposa esta més que justificat. Cal pensar que per cada client s’hauran de tenir sovint dues connexions TCP/HTTP més una connexió TCP/XMPP; per tant, tres sockets oberts per cada client connectat al servidor BOSH. Amb això suposo que queda clara la similitut amb un servidor proxy, no?
Com ja he apuntat abans escalar els servidors BOSH a través de ‘load-balancers’ és molt senzill, per exemple ús recomano nginex. Penseu que amb aquest ‘load-balancer’ podem tenir fins a10.000 connexions HTTP i només consumir 2’5Mb de memòria RAM. Per tant, aquesta també és una molt bona raó per usar-los externs els servidors BOSH. De fet, això no només ho penso jo sinó que aquí també ho pensen: BOSH cloud.
De fet, hi ha gent tan agoserada que gosa dir que XMPP és millor si els clients usen BOSH per accedir-hi, de fet, si llegeixes el raonament no sembla tan dolent: XMPP is better with BOSH.

Nota final

Per si algú encara no ho tenia clar, això és el que usen les llibreries d’XMPP implementades en JavaScript, o sigui, els client de xat (Jabber/XMPP) que via Web. Per exemple, el client que podem usar des de la pàgina web de gmail.

Obviament les aplicacions Jabber/XMPP són infinites i no només com a clients de xat. Per tant, podeu aprofitar aquestes llibreries JS que implementen BOSH per mostrar de forma interactiva a les vostres interficies web qualsevol tipus de contingut que obtingueu a través de la xarxa XMPP.

Tuning d’un servidor MySQL

Reading time: 2 – 2 minutes

Aquesta última setmana he tingut alguns problemes de rendiment amb un servidor MySQL, de fet, hi havia en concret una taula que tenia fins a 53 milions de registres, malgrat el seu espai tampoc era tan gran al voltant de 4Gb l’accés de lectura i escriptura a la taula era molt lent, sobretot per funcions de filtrat una mica complexes.

Doncs bé, coses que he aprés que potser ús poden anar bé són:

  1. Cal habilitar les ‘slow_query_logs’ i tenir indexats tots els camps que apareixen després dels WHERE’s, això millora considerablement el rendiment.
  2. Cal incrementar el innodb_log_file_size fins a un 25% del valor del innodb_buffer_pool_size; això redueix considerablement el temps d’escriptura.
  3. Usar JFS, com a sistema de fitxers del directori ‘data’ del MySQL. És substancialment més ràpid que el ext3. Exemples de rendiment.
  4. Posar els logs en un disc dedicat, diferent del disc que té les dades.
  5. Usar el paràmetre ‘noatime’ en la partició que conté les de dades del MySQL.
  6. Deshabilitar la partició de SWAP, usar un ‘innodb buffer spool’ ben gran, sempre pensant amb la RAM disponible.
  7. Montar els directori temporal de MySQL sobre una partició RAM.
  8. Reduir el key_buffer size a 1-2Mb si no s’usen taules MyISAM.
  9. Usar el kernel 2.6 amb SMP amb processador multi-cos, és especialment important per aplicaions multithread com el MySQL.
  10. Usar RAID0 (stripped disks) i usar un servidor de replicació per les còpies de seguretat. Millora els temps d’I/O del disc, com és lògic.

llibre: “La economía Long Tail”

Reading time: 2 – 4 minutes

Almenys fa tres setmanes que tinc pendent escriure una ressenya sobre aquest llibre “La econmía Long Tail: De los mercados de masas al triunfo de lo minoritario” (ISBN: 978-84-934642-6-4) escrit per Chris Anderson (editor de la revista Wired). Per cert, el llibre me’l va recomanar el Jordi, així doncs li he d’agraïr que ho fes perquè desconeixia totalment el concepte ‘long tail’ i ara el veig a tots els racons.

Pels que com jo tampoc ús soni el terme, una bona forma d’intrudir-se és a partir de l’article de la wikipedia sobre el conepte. De fet, hi ha ben pocs conceptes que donin tan de si i que es poguin explicar amb algo tan senzill com aquesta gràfica:

long tail graph

El concepte ‘long tail’ faria referència a la part dreta de la gràfica, o sigui, on la gràfica tendeix a zero però mai arriba a ser-ho per molt a la dreta que anem. Aquí és on rau el valor de la teoria. Posaré un exemple, perquè s’entengui millor.

Imagineu que la gràfica aplica al index de ventes de DVDs; doncs bé, a l’esquerra tindriem els ‘top’, el que més es ven. A la dreta, tota la ‘long tail’ amb milions i milions de DVDs que pertanyen a infinitat de nitxols de mercat que són més o menys grossos, però que sovint si ens n’anéssim a la posició 100.000 d’aquest llistat de ventes de DVD trobariem que aquest DVD es continua venent encara que sigui en molt poques unitats, igualment segueix passant a la posició 500.000 o 1.000.000. El que preten demostrar la teoria del ‘long tail’ és que hi ha empreses com pot ser Netflix, Rhapsody, iTunes o d’altres similars que sovint acaben fent tants o més diners per la suma de ventes a la ‘long tail’ que no pas en els productes ‘top’.

Més enllà del concepte, la valoració que faig del llibre és bona. Diguem que li poso un 7 sobre 10. Aconsegueix mantenir-te força enganxat malgrat com ja em va comentar el Jordi si haguessin fet un treball de síntesis amb 15 pàgines es podia explicar tot el que ve a dir el llibre. Però l’assaig demostra la teoria i explica com s’ha arribat a poder afirmar això, contrastant-ho en diversos aspectes de l’economia actual i del comerç electrònic. A més, cal destacar l’important treball de camp que fa l’autor per contrastar la teoria. Així doncs, si penseu fer algún tipus de pla de negoci que toqui internet ni que sigui de passada, és una bona lectura a fer.

compilar VMWare Workstation amb una FC11

Reading time: 8 – 12 minutes

Nota tècnica, per assegurar-se que tenim tot el que fa falta per compilar VMWare Workstation en una Fedora Core 11, executar com a root:

yum install kernel-devel kernel-headers gcc
yum groupinstall "Development Tools" "Development Libraries"

En cas de que al fer un:

vmware-modconfig --console --install-all

encara doni errors de compilació, a mi el que m’ha funcionat ha estat descarregar els fitxers:

després he executat altre cop el ‘vmware-modconfig’ i ja ha compilat, malgrat dona força warning tot ha funcionat bé.

Això ho he fet amb les versions:

  • kernel: 2.6.29.5-191.fc11.i586
  • VMware Workstation v6.5.1.126130

La solució l’he trobat al thread:[VMware] Compile kernel problem..

NAT traversal: Com funciona ICE?

Reading time: 5 – 8 minutes

Per tal d’entendre com funciona ICE el millor és explicar-lo conjuntament amb un altre protocol; ja que com es va comentar a la introducció del NAT traversal el protol ICE usa una combinació del protocol TURN i STUN en funció del cas, això és molt senzill d’entendre si parlem d’un cas pràctic d’ús. O sigui, quan s’intenta que per exmple, SIP travessi un firewall/gateway/router per fer arribar una trucada a un telefon IP.

Què són els candidats?

El Caller envia un missatge de SIP INVITE amb informació SDP que descriu per quina IP i per quins PORTS l’aplicació pot rebre audio i/o video. Aquestes adreces i ports es coneixen com candidates. Aquests candidates s’obtenen del servidor ICE (sovint es troba dins el firewall/router/gateway).

Podriem descriure un candidate com una IP i un port a través dels quals un peer pot rebre dades d’un altre peer. Hi ha tres tipus de candidates:

  • Local candidate: IP local del client.
  • Reflexive or STUN candidates: una adreça IP pública del servidor NAT.
  • Relay o TURN candidate: una adreça o un relay server que ha estat reservat pel client.

El tràfic sempre es podrà enviar amb èxit a través dels relay candidates, a menys que un firewall bloquegi l’enllaç, aleshores no hi ha tècnica possible de NAT traversal a aplicar. El problema d’usar relay candidates és que requereix usar recursos d’un servidor, això fa que el tràfic que arriba al peer tingui retards, perdues i problemes de jitter.

Procés d’establiment d’una trucada SIP via ICE

1. Caller aconsegueix els seus candidates

En el següent gràfic es pot veure com el Caller determinada els reflexive i relay candidates per una connexió. El client envia una petició d’ALLOCATE al servidor, llavors el servidor localitza un parell IP/port (el relay candidate). Aquesta informació s’envia altre cop al Caller (reflexive candidate), aquest missatge conté la IP pública que usarà el Caller quan emeti un missatge a internet, sovint això és la IP a través de la qual s’aplicarà el NAT.

stun_turn_candidates

2. Caller envia un SIP INVINTE

El Caller construeix un missatge SIP INVITE usant la informació dels candidates que ha obtingut del seu servidor ICE, després l’envia al seu destí.

3. Callee aconsegueix els candidates

Quan es rep el missatge SIP INVITE, el Callee aconsegueix els candidates de la mateixa manera que ho ha fet el Caller en el punt (1).

4. El Callee envia una resposta 1xx

Seguint amb el protocol SIP, el Callee ha de generar un missatge de resposta al SIP INVITE, per exemple, un SIP 183 (Session Progress). Quan es construeixi aquest missatge dins de l’informació SDP el Callee també hi encapsularà els seus candidates. Fins que aquest missatge no s’hagi rebut i confirmat per part del Caller (200 OK) no es considerarà exitosa la negociació.

5. ICE connectivity checks

Arribats en aquest punt tan el Caller com el Calle saben mutuament els candidates que tenen cadascún i és el moment d’usar el que s’anomena ICE connectivity checks. Això es fa enviant un missatge STUN des del local candidate cap al remote candidate, això es pot fer per tants candidates com hi hagin des del que té més prioritat fins al que en té menys. Això ho faran ambdós costats de l’enllaç si és que tots dos es troven darrera un gateway amb ICE. Quan s’hagi determinat quin dels candidates és el millor per establir cada un dels canals llavors s’escollirà aquest candidate per començar a enviar i rebre media a través seu.

A continuació es poden veure tres exemples de com es fan aquestes proves dels candidates. El primer esquema seria el cas en que ambdós hosts són enrutables directament perquè, per exmple, estan a la mateixa LAN. El segon esquema s’aconseguiria l’enllaç via la metologia STUN i en el tercer via la metodologia TURN.

ICE_connection_check

6. Callee envia SIP 180 (ringing)

En aquest punt el Callee envia el missatge SIP 180 (ringing) al Caller per informar-lo de que el teléfon del Callee esta sonant. Al haver negociat previament el canal de dades a través d’ICE quan el Callee despengi el teléfon ja podrà parlar sense retards, si això es negocies després hi hauria un efecte de retard desagradable pels peers.

7. Accepta la trucada i parlen

Així doncs, quan el Callee despengi s’enviarà un missatge 200 OK i via RTP (per exemple) i usant els canals negociats via ICE el fluxe de dades multimedia (en aquest cas audio) començarà travessant de forma transparent els dos gateways que donen accés a internet als dos peers.

Unes notes per aclarir el tema

En aquest exemple es preten demostrar que podem establir un enllaç RTP a través de dos peers que es troben darrera de NAT gràcies al protocol ICE. Com a protocol per controlar la sessió RTP s’usa SIP, això fa que ambdós peers necessitin una redirecció DNAT al seu gateway cap als ports TCP/UPD 5060. En cas de voler evitar això el que s’hauria d’usar és un altre protocol de senyalització diferent de SIP. Per exemple, si no volem/podem redirigir cap port al gateway es podria usar XMPP.

Glosari

  • Caller: qui fa la trucada
  • Calee: qui rep la trucada
  • SDP: Session Description Protocol
  • SIP: Session Initiation Protocol
  • Peer: un extrem de la connexió

Referències


NAT traversal: Com funciona STUN?

Reading time: 2 – 3 minutes

El servidor STUN ha de publicar la seva IP (3478TCP/UPD o 5349TLS) a un gateway que tingui una IP interna i una externa (privada i pública). La comuniació comença quan el client que esta a la xarxa enmascarada llença una serie de requests contra la IP pública del servidor STUN. El servidor STUN contestarà al client informant dels parells de ports usats a l’exterior del NAT, amb això el client aprent de quin tipus de NAT disposa i quin és el TTL dels bindings que es fan a l’exterior per re-enviar les seves peticions.

Una aplicació client per tal de saber qui és el seu servidor STUN el que fa és buscar al seu domini DNS la resolució del nom _stun_.domini_exemple.com o _stun._udp.domini_exemple.com pels tipus de registre SRV. Després de saber qui és el seu servidor STUN el que fa l’aplicació és buscar l’adreça pública del servidor STUN. Per tal de descobrir quin haurà de ser l’origen dels seus paquets a internet. Així quan construeixi els paquets amb les dades d’aplicació podrà advertir quina és l’adreça pública del seu servidor STUN.

Arribats a aquest punt sovint en tenim prou com per començar la comunicació amb el destí final del nostre enllaç, ja que aquest l’únic que haurà de fer és contestar els paquets pels mateixos ports que el gateway esta fent binding en aquell moment. Aquí és on el STUN server fa la seva feina mantenint els ports oberts. Un dels problemes amb els que ens podem trobar és que el node destí no pugui atacar aquells ports per alguna restricció del seu firewall o similar. Cosa que complica la possibilitat de fer l’enllaç. Si els dos hosts que volem comunicar estan tots dos darrera del NAT-masquerade la cosa és fa molt difícil i sovint fa falta un proxy entre els dos servidors STUN per tal de que la cosa funcioni, o sigui, que es complica moltíssim.

Diagrama de fluxe del protocol:

Esquema NAT
Click for (+) Zoom

Scroll to Top