Your SlideShare is downloading. ×
  • Like
[VoIP2Day 2009] Presente y futuro de las comunicaciones VoIP
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

[VoIP2Day 2009] Presente y futuro de las comunicaciones VoIP

  • 789 views
Published

A talk in Madrid SIMO VoIP2Day 2009 about large SIP deployments, SIP SIMPLE and XCAP presence, and SIP in mobile networks. With Saúl Ibarra and Jon Bonilla.

A talk in Madrid SIMO VoIP2Day 2009 about large SIP deployments, SIP SIMPLE and XCAP presence, and SIP in mobile networks. With Saúl Ibarra and Jon Bonilla.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
789
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
52
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Presente y futuro de las comunicaciones VoIP VoIP2day 2k9 - http://www.voip2day.net
  • 2. ¿Y éstos quiénes son?
  • 3. SIPdoc Team
    • Trabajadores con familia, hijos, … oh wait!
    • 4. Trabajan en empresas serias de día y SIPean con nocturnidad y alevosía.
    • 5. ¡Hay vida más allá de Asterisk!
      • ¡En serio!
    • Imagine there is no PSTN
  • 6. 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.
  • 7. SIPdoc Team (III)
    • Éstos nos dan de comer:
  • 8. ¿Qué nos van a contar?
  • 9. índice
    • Infraestructuras de servicios VoIP (saghul)
      • Quiero montar un proveedor, ¿cómo hago?
      • 10. Arquitectura y componentes
    • Presencia SIP avanzada (ibc)
      • Presencia SIMPLE
      • 11. XCAP
    • VoIP en telefonía móvil e IMS (manwe)
      • Convergencia entre las redes de VoIP y móvil
      • 12. El futuro: IMS
  • 13. Infraestructuras de servicios VoIP
  • 14. Arquitectura básica de proveedor
    • Servicio a usuarios residenciales
    • 15. Enlaces SIP con IP-PBX
    • 16. Elementos implicados
    • El proxy lo hace todo
  • 21. Arquitectura básica de proveedor (II)
  • 22. Componentes de la arquitectura básica
    • SIP proxy
      • Sólo habla SIP
      • 23. Registro de usuarios
      • 24. Enlaces con gateways PSTN
      • 25. Enlaces con otros proveedores (peering)
      • 26. Facturación (accounting)
    Muy poca inteligencia -> ¡no es una PBX!
  • 27. Componentes de la arquitectura básica (II)
    • Gateways PSTN
      • Puede ser hardware integrado o algo software -> Asterisk, FreeSWITCH, CallWeaver, YATE, ...
      • 28. Encargado de conectar el mundo SIP a la PSTN
  • 29. Componentes de la arquitectura básica (III)
    • Proxy RTP
      • Procesa el audio .
      • 30. Necesario para ofrecer tratamiento de NAT transparente al usuario.
      • 31. Si la carga es baja podemos incluirlo en el mismo servidor físico que el proxy.
  • 32. Componentes de la arquitectura básica (IV)
    • Ventajas
      • Relativamente fácil de montar.
      • 33. Poco coste inicial si el número de clientes no es muy elevado.
      • 34. Pocas funcionalidades -> poca complejidad -> pocos errores.
  • 35. Componentes de la arquitectura básica (V)
    • Inconvenientes
      • Sólo con un proxy no podemos ofrecer servicios adicionales como buzón de voz...
      • 36. Escalabilidad: si separamos los servicios al principio, escalar en el futuro será más sencillo.
      • 37. Posible saturación del servidor.
      • 38. Hacer el accounting en el proxy no siempre es una buena idea...
  • 39. Mejorando la arquitectura básica
    • Servicios separados desde un inicio.
    • 40. Media Server para ofrecer servicios de valor añadido.
    • 41. Balanceo de carga en salida.
  • 42. Mejorando la arquitectura básica (II)
  • 43. 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.
  • 44. 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.
    • 45. El mayor número de 'nueves' posible.
      • Sin llegar a la paranoia.
  • 46. Añadiendo redundancia (II)
  • 47. 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.
      • 48. Los nodos activos todo el rato.
    • Servidor de BBDD
      • Cluster MySQL Master - Master.
  • 49. 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.
  • 50. Proveedor con centralita virtual
    • Más orientado a empresas que a usuarios residenciales.
    • 51. Ofrece servicios de centralita (PBX) de manera remota.
      • Ahorro de costes.
    • ¡Necesitamos un dialplan !
      • Hacer esto con un proxy apesta.
  • 52. Proveedor con centralita virtual (II)
    • Su infraestructura es mucho más compleja.
  • 53. Proveedor con centralita virtual (III)
    • Arquitectura típica: El Rombo .
      • Proxy SIP para registro de usuarios.
      • 54. Batería de PBX con la lógica de cada empresa.
      • 55. Balanceo de carga en salida. (PSTN u otros proveedores SIP)
  • 56. Proveedor con centralita virtual (IV)
  • 57. Proveedor con centralita virtual (V)
    • Mejorando El Rombo :
      • Batería de servidores Asterisk con la misma configuración .
      • 58. Balanceo de carga en ambos extremos: cualquier empresa usa cualquier servidor indistintamente.
  • 59. Proveedor con centralita virtual (VI)
  • 60. ¿Hemos terminado?
    • ¿Es ésta la arquitectura definitiva?
    • 61. ¿Voy a molar más que nadie?
    • 62. ¿Es indestructible?
    • 63. ¿Es el papa espacial un lagarto?
  • 64. ¿Qué nos falta?
    • Necesitamos algo que se sitúe entre el proxy y los demás sistemas.
    • 65. Ɐ algo != Asterisk
    • 66. Algo con lo que se pueda hacer accounting sin riesgos.
    • 67. Algo que tenga el control de la llamada en todo momento.
    • 68. Algo que no se trague el RTP.
  • 69. ¿Qué nos falta? Un B2BUA
  • 70. ¿Qué nos falta? (II) Alice Bob T1 T2 T3 Diálogo 1
  • 71. ¿Qué nos falta? (III) Alice b2bua Bob
  • 72. 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, …
      • 73. Posibilidad de desarrollar aplicaciones propias.
  • 74. Algo más que un B2BUA (II)
    • No tiene porqué encargarse del audio.
    • 75. Asterisk no es un Application Server.
      • Aunque hagas AGIs en PHP... ¡wow!
    • Software disponible:
      • WeSIP
      • 76. Glassfish
      • 77. Un b2bua (solo señalización)+ un Media Server + pegamento
        • ¿OpenSIPS + SEMS? Quién sabe...
  • 78. Ahora sí
  • 79. Ahora sí (II)
  • 83. Arbitro, ¡cambio!
  • 84. Presencia SIP SIMPLE y XCAP more than voice...
  • 85. Lo que conocemos...
  • 86. Lo que conocemos... (II)
    • XMPP
      • IM y presencia
        • Y la ñapa de “Jingle” para voz.
    • MSN
      • IM, presencia y voz (limitada)
      • 87. “Dicen” que usa una especie de SIP “custom”
    • Skype
      • IM, presencia y voz
      • 88. Pero apesta
  • 89. Pero nos gusta la VoIP
    • Venimos del mundo de la voz
      • La prioridad es el teléfono
      • 90. 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?”
  • 91. ¿SIP + XMPP?
    • Solución híbrida
      • PBX SIP + servidor XMPP
    • Desventajas
      • Doble mantenimiento de usuarios (ñapas)
      • 92. Pocos terminales/softphones implementan bien ambos protocolos
      • 93. “Integración” Asterisk + OpenFire...
        • Hay vida más allá de Asterisk. En serio.
    • ¿Alguna otra sugerencia?
      • ...
  • 94.  
  • 95. 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...”
  • 96. SUBSCRIBE
    • Subscripción al estado de presencia de otro usuario
    • 97. RFC 3856
      • [email_address] quiere conocer el estado de presencia de [email_address] .
      • 98. [email_address] envía un SUBSCRIBE:
  • 99. SUBSCRIBE (II)
          • SUBSCRIBE sip:manwe@sipdoc.net SIP/2.0
          • 100. Via: SIP/2.0/UDP 192.168.1.101:6060;rport;branch=z9hG4bKwrezomkl
          • 101. Max-Forwards: 70
          • 102. To: <sip:manwe@sipdoc.net>
          • 103. From: &quot;IBC&quot; <sip:ibc@sipdoc.net>;tag=hzxgf
          • 104. Call-ID: osrcavbozglnyzs@ibc-laptop
          • 105. CSeq: 724 SUBSCRIBE
          • 106. Contact: <sip:ibc@192.168.1.101:6060>
          • 107. Accept: application/pidf+xml
          • 108. Event: presence
          • 109. Expires: 3600
          • 110. User-Agent: Twinkle/1.4.2
          • 111. Content-Length: 0
  • 112. PUBLISH
    • Un usuario publica su estado de presencia
    • 113. RFC 3903
      • [email_address] publica su estado “online” enviando un PUBLISH al servidor de presencia:
  • 114. PUBLISH (II)
        • PUBLISH sip:manwe@sipdoc.net SIP/2.0
        • 115. Via: SIP/2.0/UDP 192.168.1.101:22630;branch=z9hG4bK754z
        • 116. Max-Forwards: 70
        • 117. Contact: <sip:manwe@192.168.1.101:22630>
        • 118. To: &quot;Manwe&quot;<sip:manwe@sipdoc.net>
        • 119. From: &quot;Manwe&quot;<sip:manwe@sipdoc.net>;tag=e837
        • 120. Call-ID: NzEzYjRkZDIzOTMU
        • 121. CSeq: 2 PUBLISH
        • 122. Expires: 3600
        • 123. Content-Type: application/pidf+xml
        • 124. User-Agent: eyeBeam
        • 125. Event: presence
        • 126. Content-Length: 419
        • <?xml version='1.0' encoding='UTF-8'?>
        • 127. <presence xmlns='urn:ietf:params:xml:ns:pidf'
        • 128. xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'
        • 129. xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid'
        • 130. xmlns:c='urn:ietf:params:xml:ns:pidf:cipid'
        • 131. entity='sip:manwe@sipdoc.net'>
        • 132. <tuple id='t7045d830'>
        • 133. <status>
        • 134. <basic>open</basic>
        • 135. </status>
        • 136. </tuple>
        • 137. <dm:person id='p3b5c9a33'>
        • 138. <rpid:activities>
        • 139. <rpid:busy/>
        • 140. </rpid:activities>
        • 141. <dm:note>Busy</dm:note>
        • 142. </dm:person>
        • 143. </presence>
  • 144. NOTIFY
    • Recibimos notificaciones de cambio de presencia de un usuario
    • 145. RFC 3856
      • [email_address] ha cambiado su estado y [email_address] recibe un NOTIFY:
  • 146. NOTIFY (II)
            • NOTIFY sip:ibc@88.218.216.202:8258 SIP/2.0
            • 147. Via: SIP/2.0/UDP 92.121.79.216:5062;branch=z9hG4bK742c.300d82e6.0
            • 148. To: <sip:ibc@sipdoc.net>;tag=616ab145
            • 149. From: <sip:manwe@sipdoc.net>;tag=5e49c2c8b
            • 150. CSeq: 2 NOTIFY
            • 151. Call-ID: NGYwOTlkNWIyMTg3Ym
            • 152. Content-Length: 214
            • 153. User-Agent: OpenSIPS
            • 154. Max-Forwards: 70
            • 155. Event: presence
            • 156. Contact: <sip:presence@92.121.79.216:5065>
            • 157. Subscription-State: active;expires=3550
            • 158. Content-Type: application/pidf+xml
            • 159. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
            • 160. <presence xmlns=&quot;urn:ietf:params:xml:ns:pidf&quot; entity=&quot;sip:manwe@sipdoc.net&quot;>
            • 161. <tuple id=&quot;xlglfs&quot;>
            • 162. <status>
            • 163. <basic>closed</basic>
            • 164. </status>
            • 165. </tuple>
            • 166. </presence>
  • 167. XCAP
    • Protocolo sobre HTTP
    • 168. RFC 4825
      • Para publicar, obtener, modificar y borrar documentos XML en un servidor:
        • Lista de contactos (RFC 4826).
        • 169. Reglas de privacidad de presencia (RFC 5025).
        • 170. 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.
  • 171. 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.
  • 172. XCAP (III)
          • PUT /xcap-root/pres-rules/users/ibc@sipdoc.net/index HTTP/1.1
          • 173. Content-Type: application/auth-policy+xml
          • 174. Content-Length: 1288
          • 175. <?xml version='1.0' encoding='UTF-8'?>
          • 176. <cp:ruleset xmlns:pr=&quot;urn:ietf:params:xml:ns:pres-rules&quot;
          • 177. xmlns:cp=&quot;urn:ietf:params:xml:ns:common-policy&quot;>
          • 178. <cp:rule id=&quot;pres_whitelist&quot;>
          • 179. <cp:conditions>
          • 180. <cp:identity>
          • 181. <cp:one id=&quot;sip:manwe@sipdoc.net&quot;/>
          • 182. <cp:one id=&quot;sip:saghul@sipdoc.net&quot;/>
          • 183. </cp:identity>
          • 184. </cp:conditions>
          • 185. <cp:actions>
          • 186. <pr:sub-handling>allow</pr:sub-handling>
          • 187. </cp:actions>
          • 188. </cp:rule>
  • 199. XCAP (IV)
    • Problemas de XCAP
      • Especificaciones demasiado “amplias”.
      • 200. Difícil interoperabilidad entre distintos clientes XCAP.
        • No hay un formato XML “rígido”.
    • Alternativas
      • XDM
        • By OpenMobileAlliance (OMA).
        • 201. Subconjunto de especificaciones XCAP + extensiones.
        • 202. Previsto su uso en IMS (pero no exclusivo).
  • 203. ¿Quién publica la presencia?
    • Lo típico: online, busy, away...
      • El propio usuario publica su estado de presencia (MSN, XMPP, Skype...)
      • 204. O el propio software
        • Estado “idle” (parado) al ausentarse del ordenador.
    • ¿Acaso hay otras formas?
  • 205. Presence Agent
    • Un nodo publica presencia por nosotros
      • Ubicado en la red, en un servidor...
      • 206. Ejemplos:
        • Un proxy/PBX conoce desde dónde nos hemos registrado y publica nuestra geolocalización.
        • 207. Un servidor de media publica los participantes en una multi-conferencia.
        • 208. Etc...
  • 209. Mensajería Instantánea
    • MESSAGE
  • 212. Mensajería Instantánea (II)
          • MESSAGE sip:manwe@sipdoc.net SIP/2.0
          • 213. Via: SIP/2.0/UDP 192.168.1.101:6060;rport;branch=z9hG4bKpfsw
          • 214. To: &quot;manwe&quot; <sip:manwe@sipdoc.net>
          • 215. From: &quot;IBC&quot; <sip:ibc@sipdoc.net>;tag=itiwa
          • 216. Call-ID: rmsvvperobxofer@ibc-laptop
          • 217. CSeq: 320 MESSAGE
          • 218. Content-Type: text/plain;charset=utf-8
          • 219. User-Agent: Twinkle/1.4.2
          • 220. Content-Length: 43
          • 221. hola, tienes lista tu parte del VoIP2Day?
  • 222. Mensajería Instantánea (III)
    • MSRP
      • RFC 4975
      • 223. Sessión de mensajería
        • Los mensajes pertenecen a un contexto (sesión)
        • 224. Incluye transferencia de ficheros
  • 225. me aburro...
  • 226. futuro comunicaciones unificadas convergencia bla bla bla... humo No más teoría por favor...
  • 227. show me the code !
  • 228. Demo
  • 229. 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
  • 230. Presencia y XCAP Presence Server sip:manwe@sipdoc.net sip:ibc@sipdoc.net XCAP Server
  • 231. Asterisk MeetMe Presence Agent Asterisk sip:manwe@sipdoc.net sip:ibc@sipdoc.net Presence Server
  • 232. Presence Agent Application Server Presence Server i n t e r n é sip:manwe@sipdoc.net
  • 233. Gateway SIP MESSAGE -> Application Server Proxy / Registrar i n t e r n é sip:ibc@sipdoc.net
  • 234. Gateway SIP MESSAGE ↔ e-Mail Application Server Proxy / Registrar i n t e r n é sip:ibc@sipdoc.net
  • 235. GeoLocation Presence Agent Proxy / Registrar sip:ibc@sipdoc.net Presence Server sip:saghul@sipdoc.net
  • 236. 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?
  • 237. THE END
      BYE sip: [email_address] SIP/2.0 From: sip: [email_address] Content-Type: text/plain Accept: APLAUSOS, ABUCHEOS ¡Gracias!
  • 238. THE END (II)
      REFER sip: [email_address] SIP/2.0 Refer-To: sip: [email_address] From: sip: [email_address]
  • 239. VoIP en telefonía móvil e IMS
  • 240. Estado actual
  • 241. ¿Dónde estamos?
    • Tenemos centralitas
  • 242. ¿Dónde estamos?
    • Tenemos infraestructuras de operador
  • 243. ¿Dónde estamos?
    • Tenemos buena presencia
  • 244. ¿Qué falta?
    • Ahora no estoy en casa o en el trabajo
  • 245. ¿Qué falta?
    • Sólo tengo el móvil
  • 246. VOIP en la red móvil actual
    • Tenemos terminales 3G
  • 247. VOIP en la red móvil actual
    • Las tarifas de datos son caras
  • 248. VOIP en la red móvil actual
    • Las aplicaciones están controladas
  • 249. VOIP en la red móvil actual
    • Podemos hacer jailbreaking
  • 250. VOIP en la red móvil actual
    • El contrato tiene letra pequeña
  • 251. VOIP en la red móvil actual
    • El panorama general...
  • 252. VOIP en la red móvil actual
    • Banda ancha en España
  • 253. Cimientos
    • La pregunta es sencilla:
    HOYGAN
  • 254. Cimientos
    • La respuesta no lo es:
    42
  • 255. Soluciones en el cliente
  • 256. Enlaces GSM - PBX
    • ¿Solución? más extendida
  • 257. Enlaces GSM – PBX I
    • Llamada entrante a DID
    PSTN Red móvil Notify!
  • 258. Enlaces GSM – PBX II
    • Llamada entrante a móvil
    PSTN Red móvil Notify!
  • 259. Enlaces GSM – PBX III
    • Es una ñapa:
      • No nos enteramos del estado del terminal.
      • 260. Necesitamos N enlaces.
      • 261. Lógica de PBX sólo en llamadas entrantes o salientes apañadas.
      • 262. Pagamos por todas las llamadas, tanto entrantes como salientes.
  • 263. Enlatadas PBX-Móvil I
    • Soluciones de convergencia PBX-móvil
        • Ej: Divitas
  • 264. Enlatadas PBX-Móvil II
    • Llamada entrante a DID
    PSTN Red móvil Notify
  • 265. Enlatadas PBX-Móvil III
    • Llamada saliente
    PSTN Red móvil Notify
  • 266. Enlatadas PBX-Móvil IV
    • Es una ñapa:
      • Pero es una ñapa mejor.
      • 267. Es cara.
      • 268. Seguimos pagando todas las llamadas entrantes y salientes.
  • 269. Solución OMV
  • 270. Solución OMV I
    • Punto de partida...
    Red móvil Movil empresa X CDR
  • 271. Solución OMV II
    • Llegamos a un acuerdo...
    Red móvil Movil empresa X Red IP
  • 272. 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
  • 273. 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
  • 274. 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!
  • 275. 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!
  • 276. Solución OMV VI
    • Esto sí es una solución.
      • Es del lado del operador.
      • 277. Integración red móvil y red IP.
      • 278. 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.
  • 279. Solución IMS
  • 280. Intro
    • I p M ultimedia S ubsystem:
    • 281. Arquitectura para el establecimiento de sesiones multimedia en redes IP.
    INTERNET RED MÓVIL
  • 282. Antecedentes IMS ITU-R IETF ETSI 3GPP2 3GPP OMA TISPAN
  • 283. Ventajas
    • Primera parte de la charla.
    • 284. Quality of Service.
    • 285. Tipos de sesión.
    • 286. Integración de servicios.
    • 287. Interconexión red-agnóstica.
  • 288. Requerimientos I
    • Establecimiento de sesiones MM en redes de conmutación de paquetes.
    • 289. Interoperabilidad con redes tradicionales no-IMS.
    • 290. Soporte de políticas de servicio.
    • 291. QoS.
  • 292. Requerimientos II
    • Múltiples tecnologías de acceso a red de datos.
    • 293. Uso de protocolos de Internet.
    • 294. Agilidad en estandarización de servicios.
    • 295. Roaming.
  • 296. 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
  • 297. Acceso a IMS
    • Contrato de servicio IMS.
    • 298. Conexión a red IP.
    • 299. Obtener dirección del proxy.
    • 300. Registro en red IMS.
  • 301. 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
  • 302. 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
  • 303. 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
  • 304. Conclusiones
  • 305. 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
  • 306. Conclusiones “ No fracasé, sólo descubrí 999 maneras de cómo no hacer una bombilla.” Thomas Alba Edison
  • 307. Conclusiones “ Pienso que hay mercado en el mundo como para unos cinco ordenadores.” Thomas J. Watson Presidente de IBM
  • 308. Conclusiones “ Dales lo que piden, no lo que necesitan.” Lucifer
  • 309. Conclusiones “ No dejes para mañana lo que puedas hacer hoy.” Refrán popular
  • 310. Conclusiones “ Sólo somos una organización de recogida de datos. Nosotros no exculpamos a nadie. Nosotros no condenamos a nadie.&quot; J. Edgar Hoover
  • 311. 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!&quot; Bender B. Rodríguez
  • 312. 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
  • 313. Conclusiones “ Un Anillo para gobernarlos a todos. Un Anillo para encontrarlos, un Anillo para atraerlos a todos y atarlos en las tinieblas.” Sauron
  • 314. 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
  • 315. Conclusiones &quot;Somos los Borg. Serán asimilados. La resistencia es fútil.” Locutus Piccard
  • 316. Agradecimientos
  • 319. Mayéutica