SIPdoc VoIP2Day 2009 (Madrid SIMO)

Presente y futuro de las comunicaciones VoIP VoIP2day 2k9 - http://www.voip2day.net

¿Y éstos quiénes son?

SIPdoc Team

Trabajadores con familia, hijos, … oh wait!
Trabajan en empresas serias de día y SIPean con nocturnidad y alevosía.
¡Hay vida más allá de Asterisk!

¡En serio!

Imagine there is no PSTN

SIPdoc Team (II)

Iñaki Baz (ibc)

Ese hombre que no sale a por el pan si no se ha leído el RFC o draft correspondiente.

Jon Bonilla (manwe)

Ese hombre que tras comprar el pan y hacerse un bokata se lee el RFC o draft correspondiente mientras se lo come.

Saúl Ibarra (saghul)

Ese ¿hombre? que no dormiría si pudiera evitarlo y no toca nada con botones que no pueda flashear.

SIPdoc Team (III)

Éstos nos dan de comer:

¿Qué nos van a contar?

índice

Infraestructuras de servicios VoIP (saghul)

Quiero montar un proveedor, ¿cómo hago?
Arquitectura y componentes

Presencia SIP avanzada (ibc)

Presencia SIMPLE
XCAP

VoIP en telefonía móvil e IMS (manwe)

Convergencia entre las redes de VoIP y móvil
El futuro: IMS

Infraestructuras de servicios VoIP

Arquitectura básica de proveedor

Servicio a usuarios residenciales
Enlaces SIP con IP-PBX
Elementos implicados

Proxy SIP
Gateway PSTN
…

El proxy lo hace todo

Registro
Accounting
...

Arquitectura básica de proveedor (II)

Componentes de la arquitectura básica

SIP proxy

Sólo habla SIP
Registro de usuarios
Enlaces con gateways PSTN
Enlaces con otros proveedores (peering)
Facturación (accounting)

Muy poca inteligencia -> ¡no es una PBX!

Componentes de la arquitectura básica (II)

Gateways PSTN

Puede ser hardware integrado o algo software -> Asterisk, FreeSWITCH, CallWeaver, YATE, ...
Encargado de conectar el mundo SIP a la PSTN

Componentes de la arquitectura básica (III)

Proxy RTP

Procesa el audio .
Necesario para ofrecer tratamiento de NAT transparente al usuario.
Si la carga es baja podemos incluirlo en el mismo servidor físico que el proxy.

Componentes de la arquitectura básica (IV)

Ventajas

Relativamente fácil de montar.
Poco coste inicial si el número de clientes no es muy elevado.
Pocas funcionalidades -> poca complejidad -> pocos errores.

Componentes de la arquitectura básica (V)

Inconvenientes

Sólo con un proxy no podemos ofrecer servicios adicionales como buzón de voz...
Escalabilidad: si separamos los servicios al principio, escalar en el futuro será más sencillo.
Posible saturación del servidor.
Hacer el accounting en el proxy no siempre es una buena idea...

Mejorando la arquitectura básica

Servicios separados desde un inicio.
Media Server para ofrecer servicios de valor añadido.
Balanceo de carga en salida.

Mejorando la arquitectura básica (II)

Mejorando la arquitectura básica (III)

Añadidos los servidores AMS1 y AMS2 para ofrecer servicios endpoint de buzón de voz y conferencias.

Nice and cool sexy features, yeah!

Proxy SIP adicional para hacer el balanceo de carga hacia la PSTN.

Capacidad de hacer failover.

Servidor de BBDD independiente.

Menor carga para el core proxy.

Añadiendo redundancia

Nuestro servicio es crítico para los clientes.

Como no puedan llamar -> ¡pánico!

Redundar los sistemas evitará que la caída de un servidor provoque un corte en el servicio.
El mayor número de 'nueves' posible.

Sin llegar a la paranoia.

Añadiendo redundancia (II)

Añadiendo redundancia (III) Las acciones a tomar varían en función del tipo de servicio.

Proxy SIP y Load Balancer

Balanceo por DNS SRV Round-Robin.
Los nodos activos todo el rato.

Servidor de BBDD

Cluster MySQL Master - Master.

Herramientas adicionales para HA

HeartBeat

Balanceo de servicios en clusters.

UCARP

Balanceo de IP y ejecución de scripts entre varios nodos.

DRBD

Sincronización de datos por red.

Csync2

Sincronización de datos por red.

Proveedor con centralita virtual

Más orientado a empresas que a usuarios residenciales.
Ofrece servicios de centralita (PBX) de manera remota.

Ahorro de costes.

¡Necesitamos un dialplan !

Hacer esto con un proxy apesta.

Proveedor con centralita virtual (II)

Su infraestructura es mucho más compleja.

Proveedor con centralita virtual (III)

Arquitectura típica: El Rombo .

Proxy SIP para registro de usuarios.
Batería de PBX con la lógica de cada empresa.
Balanceo de carga en salida. (PSTN u otros proveedores SIP)

Proveedor con centralita virtual (IV)

Proveedor con centralita virtual (V)

Mejorando El Rombo :

Batería de servidores Asterisk con la misma configuración .
Balanceo de carga en ambos extremos: cualquier empresa usa cualquier servidor indistintamente.

Proveedor con centralita virtual (VI)

¿Hemos terminado?

¿Es ésta la arquitectura definitiva?
¿Voy a molar más que nadie?
¿Es indestructible?
¿Es el papa espacial un lagarto?

¿Qué nos falta?

Necesitamos algo que se sitúe entre el proxy y los demás sistemas.
Ɐ algo != Asterisk
Algo con lo que se pueda hacer accounting sin riesgos.
Algo que tenga el control de la llamada en todo momento.
Algo que no se trague el RTP.

¿Qué nos falta? Un B2BUA

¿Qué nos falta? (II) Alice Bob T1 T2 T3 Diálogo 1

¿Qué nos falta? (III) Alice b2bua Bob

Algo más que un B2BUA

Además de estar en medio necesitamos poder dar servicios.

Necesitamos un SIP Application Server.

Servidor SIP que hace de b2bua ¡y más!

Capacidad de interactuar con otras plataformas: XMLRPC, SOAP, HTTP, Servlets, …
Posibilidad de desarrollar aplicaciones propias.

Algo más que un B2BUA (II)

No tiene porqué encargarse del audio.
Asterisk no es un Application Server.

Aunque hagas AGIs en PHP... ¡wow!

Software disponible:

WeSIP
Glassfish
Un b2bua (solo señalización)+ un Media Server + pegamento

¿OpenSIPS + SEMS? Quién sabe...

Ahora sí

Ahora sí (II)

Arquitectura sostenible.
Escalable.
Extensible.
Future proof.

Arbitro, ¡cambio!

Presencia SIP SIMPLE y XCAP more than voice...

Lo que conocemos...

Lo que conocemos... (II)

XMPP

IM y presencia

Y la ñapa de “Jingle” para voz.

MSN

IM, presencia y voz (limitada)
“Dicen” que usa una especie de SIP “custom”

Skype

IM, presencia y voz
Pero apesta

Pero nos gusta la VoIP

Venimos del mundo de la voz

La prioridad es el teléfono
Y las funciones “molonas” de PBX

¿Puedes montar una PBX “enterprise” con Skype?

Amantes de chan_skype procedan a abandonar la sala.

Tenemos que añadir IM y presencia sobre nuestra infraestructura de VoIP (SIP)

“ ¿Cómo hago?”

¿SIP + XMPP?

Solución híbrida

PBX SIP + servidor XMPP

Desventajas

Doble mantenimiento de usuarios (ñapas)
Pocos terminales/softphones implementan bien ambos protocolos
“Integración” Asterisk + OpenFire...

Hay vida más allá de Asterisk. En serio.

¿Alguna otra sugerencia?

...

SIP SIMPLE

SIMPLE es un subgrupo de SIP que se encarga de IM y presencia

Existen especificaciones muy completas

RFC's de presencia:

3856, 3857, 3858, 3863, 4479, 4480, 4482...

RFC's de XCAP:

4825, 4826, 4827, 5025...

RFC's de IM:

3428, 3994, 4975...

OpenMobileAliance: XDM

Un refrito de todo lo anterior.

“SIMPLE is not simple...”

SUBSCRIBE

Subscripción al estado de presencia de otro usuario
RFC 3856

[email_address] quiere conocer el estado de presencia de [email_address] .
[email_address] envía un SUBSCRIBE:

SUBSCRIBE (II)

SUBSCRIBE sip:manwe@sipdoc.net SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:6060;rport;branch=z9hG4bKwrezomkl
Max-Forwards: 70
To: <sip:manwe@sipdoc.net>
From: "IBC" <sip:ibc@sipdoc.net>;tag=hzxgf
Call-ID: osrcavbozglnyzs@ibc-laptop
CSeq: 724 SUBSCRIBE
Contact: <sip:ibc@192.168.1.101:6060>
Accept: application/pidf+xml
Event: presence
Expires: 3600
User-Agent: Twinkle/1.4.2
Content-Length: 0

PUBLISH

Un usuario publica su estado de presencia
RFC 3903

[email_address] publica su estado “online” enviando un PUBLISH al servidor de presencia:

PUBLISH (II)

PUBLISH sip:manwe@sipdoc.net SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:22630;branch=z9hG4bK754z
Max-Forwards: 70
Contact: <sip:manwe@192.168.1.101:22630>
To: "Manwe"<sip:manwe@sipdoc.net>
From: "Manwe"<sip:manwe@sipdoc.net>;tag=e837
Call-ID: NzEzYjRkZDIzOTMU
CSeq: 2 PUBLISH
Expires: 3600
Content-Type: application/pidf+xml
User-Agent: eyeBeam
Event: presence
Content-Length: 419

<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf'
xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'
xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'
xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'
entity='sip:manwe@sipdoc.net'>
<tuple id='t7045d830'>
<status>
<basic>open</basic>
</status>
</tuple>
<dm:person id='p3b5c9a33'>
<rpid:activities>
<rpid:busy/>
</rpid:activities>
<dm:note>Busy</dm:note>
</dm:person>
</presence>

NOTIFY

Recibimos notificaciones de cambio de presencia de un usuario
RFC 3856

[email_address] ha cambiado su estado y [email_address] recibe un NOTIFY:

NOTIFY (II)

NOTIFY sip:ibc@88.218.216.202:8258 SIP/2.0
Via: SIP/2.0/UDP 92.121.79.216:5062;branch=z9hG4bK742c.300d82e6.0
To: <sip:ibc@sipdoc.net>;tag=616ab145
From: <sip:manwe@sipdoc.net>;tag=5e49c2c8b
CSeq: 2 NOTIFY
Call-ID: NGYwOTlkNWIyMTg3Ym
Content-Length: 214
User-Agent: OpenSIPS
Max-Forwards: 70
Event: presence
Contact: <sip:presence@92.121.79.216:5065>
Subscription-State: active;expires=3550
Content-Type: application/pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:manwe@sipdoc.net">
<tuple id="xlglfs">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>

XCAP

Protocolo sobre HTTP
RFC 4825

Para publicar, obtener, modificar y borrar documentos XML en un servidor:

Lista de contactos (RFC 4826).
Reglas de privacidad de presencia (RFC 5025).
Publicación de estado por defecto (RFC 4827).

Interacción con el servidor de presencia

El “presence server” obtiene estos documentos

Ej: para decidir si un usuario puede ver el estado de otro.

XCAP (II)

GET

Obtener un documento o parte de él.

PUT

Publicar un documento o insertar elementos.

DELETE

Borrar un documento o parte de él.

XCAP (III)

PUT /xcap-root/pres-rules/users/ibc@sipdoc.net/index HTTP/1.1
Content-Type: application/auth-policy+xml
Content-Length: 1288
<?xml version='1.0' encoding='UTF-8'?>
<cp:ruleset xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
xmlns:cp="urn:ietf:params:xml:ns:common-policy">
<cp:rule id="pres_whitelist">
<cp:conditions>
<cp:identity>
<cp:one id="sip:manwe@sipdoc.net"/>
<cp:one id="sip:saghul@sipdoc.net"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<pr:sub-handling>allow</pr:sub-handling>
</cp:actions>
</cp:rule>

<cp:rule id="pres_blacklist">
<cp:conditions>
<cp:identity>
<cp:one id="sip:bill@microsoft.com"/>
</cp:identity>
</cp:conditions>
<cp:actions>
<pr:sub-handling>block</pr:sub-handling>
</cp:actions>
</cp:rule>
</cp:ruleset>

XCAP (IV)

Problemas de XCAP

Especificaciones demasiado “amplias”.
Difícil interoperabilidad entre distintos clientes XCAP.

No hay un formato XML “rígido”.

Alternativas

XDM

By OpenMobileAlliance (OMA).
Subconjunto de especificaciones XCAP + extensiones.
Previsto su uso en IMS (pero no exclusivo).

¿Quién publica la presencia?

Lo típico: online, busy, away...

El propio usuario publica su estado de presencia (MSN, XMPP, Skype...)
O el propio software

Estado “idle” (parado) al ausentarse del ordenador.

¿Acaso hay otras formas?

Presence Agent

Un nodo publica presencia por nosotros

Ubicado en la red, en un servidor...
Ejemplos:

Un proxy/PBX conoce desde dónde nos hemos registrado y publica nuestra geolocalización.
Un servidor de media publica los participantes en una multi-conferencia.
Etc...

Mensajería Instantánea

MESSAGE

RFC 3428
Un único mensaje

Sin contexto
Tipo SMS

Mensajería Instantánea (II)

MESSAGE sip:manwe@sipdoc.net SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:6060;rport;branch=z9hG4bKpfsw
To: "manwe" <sip:manwe@sipdoc.net>
From: "IBC" <sip:ibc@sipdoc.net>;tag=itiwa
Call-ID: rmsvvperobxofer@ibc-laptop
CSeq: 320 MESSAGE
Content-Type: text/plain;charset=utf-8
User-Agent: Twinkle/1.4.2
Content-Length: 43
hola, tienes lista tu parte del VoIP2Day?

Mensajería Instantánea (III)

MSRP

RFC 4975
Sessión de mensajería

Los mensajes pertenecen a un contexto (sesión)
Incluye transferencia de ficheros

me aburro...

futuro comunicaciones unificadas convergencia bla bla bla... humo No más teoría por favor...

show me the code !

Demo

SIPdoc SIP SIMPLE Solution S 4 Media Server Asterisk & SEMS Proxy / Registrar Kamailio Presence Server OpenSIPS XCAP Server OpenXCAP Application Server SIPdoc RubySIP-AS EyeBeam Twinkle YASS VoIP2Day Special Edition

Presencia y XCAP Presence Server sip:manwe@sipdoc.net sip:ibc@sipdoc.net XCAP Server

Asterisk MeetMe Presence Agent Asterisk sip:manwe@sipdoc.net sip:ibc@sipdoc.net Presence Server

Presence Agent Application Server Presence Server i n t e r n é sip:manwe@sipdoc.net

Gateway SIP MESSAGE -> Application Server Proxy / Registrar i n t e r n é sip:ibc@sipdoc.net

Gateway SIP MESSAGE ↔ e-Mail Application Server Proxy / Registrar i n t e r n é sip:ibc@sipdoc.net

GeoLocation Presence Agent Proxy / Registrar sip:ibc@sipdoc.net Presence Server sip:saghul@sipdoc.net

Acabando...

SIP SIMPLE es poderoso

La inteligencia está en el protocolo y en los terminales

...y no en una PBX a base de DTMF's.

La presencia SIP SIMPLE tiene futuro

Faltan buenas implementaciones.

¿Qué es IAX?

¿...y qué más dá?

¿Cómo voy de tiempo?

THE END

BYE sip: [email_address] SIP/2.0 From: sip: [email_address] Content-Type: text/plain Accept: APLAUSOS, ABUCHEOS ¡Gracias!

THE END (II)

REFER sip: [email_address] SIP/2.0 Refer-To: sip: [email_address] From: sip: [email_address]

VoIP en telefonía móvil e IMS

Estado actual

¿Dónde estamos?

Tenemos centralitas

¿Dónde estamos?

Tenemos infraestructuras de operador

¿Dónde estamos?

Tenemos buena presencia

¿Qué falta?

Ahora no estoy en casa o en el trabajo

¿Qué falta?

Sólo tengo el móvil

VOIP en la red móvil actual

Tenemos terminales 3G

Las tarifas de datos son caras

Las aplicaciones están controladas

Podemos hacer jailbreaking

El contrato tiene letra pequeña

El panorama general...

Banda ancha en España

Cimientos

La pregunta es sencilla:

HOYGAN

Cimientos

La respuesta no lo es:

42

Soluciones en el cliente

Enlaces GSM - PBX

¿Solución? más extendida

Enlaces GSM – PBX I

Llamada entrante a DID

PSTN Red móvil Notify!

Enlaces GSM – PBX II

Llamada entrante a móvil

PSTN Red móvil Notify!

Enlaces GSM – PBX III

Es una ñapa:

No nos enteramos del estado del terminal.
Necesitamos N enlaces.
Lógica de PBX sólo en llamadas entrantes o salientes apañadas.
Pagamos por todas las llamadas, tanto entrantes como salientes.

Enlatadas PBX-Móvil I

Soluciones de convergencia PBX-móvil

Ej: Divitas

Enlatadas PBX-Móvil II

Llamada entrante a DID

PSTN Red móvil Notify

Enlatadas PBX-Móvil III

Llamada saliente

PSTN Red móvil Notify

Enlatadas PBX-Móvil IV

Es una ñapa:

Pero es una ñapa mejor.
Es cara.
Seguimos pagando todas las llamadas entrantes y salientes.

Solución OMV

Solución OMV I

Punto de partida...

Red móvil Movil empresa X CDR

Solución OMV II

Llegamos a un acuerdo...

Red móvil Movil empresa X Red IP

Solución OMV III

Llegamos a un acuerdo

Red móvil Móvil empresa X Red IP #include operador SIP Empresa X Un móvil cualquiera

Solución OMV IV

Ejemplo I

Red móvil Móvil empresa X Red IP #include operador SIP Empresa X Un móvil cualquiera Allo! Buzón Locución personalizada Desvío condicional

Solución OMV V

Ejemplo II

Red móvil Móvil empresa X Red IP #include operador SIP Empresa X Un móvil cualquiera Notify! Allo!

Solución OMV VI

Ejemplo III

Red móvil Móvil empresa X Red IP #include operador SIP Empresa X Un móvil cualquiera Notify PSTN Allo!

Solución OMV VI

Esto sí es una solución.

Es del lado del operador.
Integración red móvil y red IP.
Convergencia real.

Pero... seguimos teniendo red móvil.

El terminal sigue siendo tonto. Nos enteramos de su estado pero él no se entera del estado de los demás.

Solución IMS

Intro

I p M ultimedia S ubsystem:
Arquitectura para el establecimiento de sesiones multimedia en redes IP.

INTERNET RED MÓVIL

Antecedentes IMS ITU-R IETF ETSI 3GPP2 3GPP OMA TISPAN

Ventajas

Primera parte de la charla.
Quality of Service.
Tipos de sesión.
Integración de servicios.
Interconexión red-agnóstica.

Requerimientos I

Establecimiento de sesiones MM en redes de conmutación de paquetes.
Interoperabilidad con redes tradicionales no-IMS.
Soporte de políticas de servicio.
QoS.

Requerimientos II

Múltiples tecnologías de acceso a red de datos.
Uso de protocolos de Internet.
Agilidad en estandarización de servicios.
Roaming.

Arquitectura MRFP IM-SSF QSA-SCS SIP-AS P-CSCF MRFC P-CSCF MGCF BGCF MGW I-CSCF S-CSCF SGW HSS SLF Access Network Access Network

Acceso a IMS

Contrato de servicio IMS.
Conexión a red IP.
Obtener dirección del proxy.
Registro en red IMS.

Ejemplo: sesión I Alice Bob P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF Originating Visited Network Originating Home Network Terminating Home Network Terminating Visited Network INVITE Alice Alice 100 Trying INVITE 100 Trying INVITE 100 Trying Diameter INVITE 100 Trying INVITE 100 Trying INVITE 100 Trying 183 Session Progress 183 Session Progress 183 Session Progress 183 Session Progress 183 Session Progress 183 Session Progress

Ejemplo: sesión II Alice Bob P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF Originating Visited Network Originating Home Network Terminating Home Network Terminating Visited Network PRACK PRACK PRACK PRACK PRACK 200 OK 200 OK 200 OK 200 OK 200 OK UPDATE UPDATE UPDATE UPDATE UPDATE 200 OK 200 OK 200 OK 200 OK 200 OK

Ejemplo: sesión III Alice Bob P-CSCF S-CSCF I-CSCF HSS S-CSCF P-CSCF Originating Visited Network Originating Home Network Terminating Home Network Terminating Visited Network Alice 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing PRACK PRACK PRACK PRACK PRACK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK ACK ACK ACK ACK ACK

Conclusiones

Conclusiones “ No se ofusque con este terror tecnológico que ha construido. La posibilidad de destruir un planeta es algo insignificante comparado con el poder de la fuerza.” Darth Vader

Conclusiones “ No fracasé, sólo descubrí 999 maneras de cómo no hacer una bombilla.” Thomas Alba Edison

Conclusiones “ Pienso que hay mercado en el mundo como para unos cinco ordenadores.” Thomas J. Watson Presidente de IBM

Conclusiones “ Dales lo que piden, no lo que necesitan.” Lucifer

Conclusiones “ No dejes para mañana lo que puedas hacer hoy.” Refrán popular

Conclusiones “ Sólo somos una organización de recogida de datos. Nosotros no exculpamos a nadie. Nosotros no condenamos a nadie." J. Edgar Hoover

Conclusiones “ ¡Vale! ¡Pues montaré mi propio operador! ¡Con casinos! ¡Y furcias! ¡Es más, paso del operador! ¡Y de los casinos! ¡Al cuerno con todo!" Bender B. Rodríguez

Conclusiones “ El que llega primero al campo de batalla espera la llegada del enemigo fresco para combatir. Quien llega tarde al campo de batalla tiene que apresurarse y arriba exhausto al combate.” Sun Tzu

Conclusiones “ Un Anillo para gobernarlos a todos. Un Anillo para encontrarlos, un Anillo para atraerlos a todos y atarlos en las tinieblas.” Sauron

Conclusiones “ No conoceré el miedo. El miedo mata la mente. El miedo es la pequeña muerte que conduce a la destrucción total. Afrontaré mi miedo. Permitiré que pase sobre mí y a través de mí. Y cuando haya pasado, giraré mi ojo interior para escrutar su camino. Allá donde haya pasado el miedo ya no habrá nada. Sólo estaré yo.” Letanía contra el miedo de la Bene Gesserit

Conclusiones "Somos los Borg. Serán asimilados. La resistencia es fútil.” Locutus Piccard