[VoIP2Day 2009] Presente y futuro de las comunicaciones VoIP

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

2. ¿Y éstos quiénes son?

3. SIPdoc Team <ul><li>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! </li><ul><li>¡En serio! </li></ul><li>Imagine there is no PSTN </li></ul>

6. SIPdoc Team (II) <ul><li>Iñaki Baz (ibc) </li><ul><li>Ese hombre que no sale a por el pan si no se ha leído el RFC o draft correspondiente. </li></ul><li>Jon Bonilla (manwe) </li><ul><li>Ese hombre que tras comprar el pan y hacerse un bokata se lee el RFC o draft correspondiente mientras se lo come. </li></ul><li>Saúl Ibarra (saghul) </li><ul><li>Ese ¿hombre? que no dormiría si pudiera evitarlo y no toca nada con botones que no pueda flashear. </li></ul></ul>

7. SIPdoc Team (III) <ul><li>Éstos nos dan de comer: </li></ul>

8. ¿Qué nos van a contar?

9. índice <ul><li>Infraestructuras de servicios VoIP (saghul) </li><ul><li>Quiero montar un proveedor, ¿cómo hago?

10. Arquitectura y componentes </li></ul><li>Presencia SIP avanzada (ibc) </li><ul><li>Presencia SIMPLE

11. XCAP </li></ul><li>VoIP en telefonía móvil e IMS (manwe) </li><ul><li>Convergencia entre las redes de VoIP y móvil

12. El futuro: IMS </li></ul></ul>

13. Infraestructuras de servicios VoIP

14. Arquitectura básica de proveedor <ul><li>Servicio a usuarios residenciales

15. Enlaces SIP con IP-PBX

16. Elementos implicados </li><ul><li>Proxy SIP

17. Gateway PSTN

18. … </li></ul><li>El proxy lo hace todo </li><ul><li>Registro

19. Accounting

20. ... </li></ul></ul>

21. Arquitectura básica de proveedor (II)

22. Componentes de la arquitectura básica <ul><li>SIP proxy </li><ul><li>Sólo habla SIP

23. Registro de usuarios

24. Enlaces con gateways PSTN

25. Enlaces con otros proveedores (peering)

26. Facturación (accounting) </li></ul></ul>Muy poca inteligencia -> ¡no es una PBX!

27. Componentes de la arquitectura básica (II) <ul><li>Gateways PSTN </li><ul><li>Puede ser hardware integrado o algo software -> Asterisk, FreeSWITCH, CallWeaver, YATE, ...

28. Encargado de conectar el mundo SIP a la PSTN </li></ul></ul>

29. Componentes de la arquitectura básica (III) <ul><li>Proxy RTP </li><ul><li>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. </li></ul></ul>

32. Componentes de la arquitectura básica (IV) <ul><li>Ventajas </li><ul><li>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. </li></ul></ul>

35. Componentes de la arquitectura básica (V) <ul><li>Inconvenientes </li><ul><li>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... </li></ul></ul>

39. Mejorando la arquitectura básica <ul><li>Servicios separados desde un inicio.

40. Media Server para ofrecer servicios de valor añadido.

41. Balanceo de carga en salida. </li></ul>

42. Mejorando la arquitectura básica (II)

43. Mejorando la arquitectura básica (III) <ul><li>Añadidos los servidores AMS1 y AMS2 para ofrecer servicios endpoint de buzón de voz y conferencias. </li><ul><li>Nice and cool sexy features, yeah! </li></ul><li>Proxy SIP adicional para hacer el balanceo de carga hacia la PSTN. </li><ul><li>Capacidad de hacer failover. </li></ul><li>Servidor de BBDD independiente. </li><ul><li>Menor carga para el core proxy. </li></ul></ul>

44. Añadiendo redundancia <ul><li>Nuestro servicio es crítico para los clientes. </li><ul><li>Como no puedan llamar -> ¡pánico! </li></ul><li>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. </li><ul><li>Sin llegar a la paranoia. </li></ul></ul>

46. Añadiendo redundancia (II)

47. Añadiendo redundancia (III) Las acciones a tomar varían en función del tipo de servicio. <ul><li>Proxy SIP y Load Balancer </li><ul><li>Balanceo por DNS SRV Round-Robin.

48. Los nodos activos todo el rato. </li></ul><li>Servidor de BBDD </li><ul><li>Cluster MySQL Master - Master. </li></ul></ul>

49. Herramientas adicionales para HA <ul><li>HeartBeat </li><ul><li>Balanceo de servicios en clusters. </li></ul><li>UCARP </li><ul><li>Balanceo de IP y ejecución de scripts entre varios nodos. </li></ul><li>DRBD </li><ul><li>Sincronización de datos por red. </li></ul><li>Csync2 </li><ul><li>Sincronización de datos por red. </li></ul></ul>

50. Proveedor con centralita virtual <ul><li>Más orientado a empresas que a usuarios residenciales.

51. Ofrece servicios de centralita (PBX) de manera remota. </li><ul><li>Ahorro de costes. </li></ul><li>¡Necesitamos un dialplan ! </li><ul><li>Hacer esto con un proxy apesta. </li></ul></ul>

52. Proveedor con centralita virtual (II) <ul><li>Su infraestructura es mucho más compleja. </li></ul>

53. Proveedor con centralita virtual (III) <ul><li>Arquitectura típica: El Rombo . </li><ul><li>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) </li></ul></ul>

56. Proveedor con centralita virtual (IV)

57. Proveedor con centralita virtual (V) <ul><li>Mejorando El Rombo : </li><ul><li>Batería de servidores Asterisk con la misma configuración .

58. Balanceo de carga en ambos extremos: cualquier empresa usa cualquier servidor indistintamente. </li></ul></ul>

59. Proveedor con centralita virtual (VI)

60. ¿Hemos terminado? <ul><li>¿Es ésta la arquitectura definitiva?

61. ¿Voy a molar más que nadie?

62. ¿Es indestructible?

63. ¿Es el papa espacial un lagarto? </li></ul>

64. ¿Qué nos falta? <ul><li>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. </li></ul>

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 <ul><li>Además de estar en medio necesitamos poder dar servicios. </li><ul><li>Necesitamos un SIP Application Server. </li></ul></ul><ul><li>Servidor SIP que hace de b2bua ¡y más! </li><ul><li>Capacidad de interactuar con otras plataformas: XMLRPC, SOAP, HTTP, Servlets, …

73. Posibilidad de desarrollar aplicaciones propias. </li></ul></ul>

74. Algo más que un B2BUA (II) <ul><li>No tiene porqué encargarse del audio.

75. Asterisk no es un Application Server. </li><ul><li>Aunque hagas AGIs en PHP... ¡wow! </li></ul><li>Software disponible: </li><ul><li>WeSIP

76. Glassfish

77. Un b2bua (solo señalización)+ un Media Server + pegamento </li><ul><li>¿OpenSIPS + SEMS? Quién sabe... </li></ul></ul></ul>

78. Ahora sí

79. Ahora sí (II) <ul><li>Arquitectura sostenible.

80. Escalable.

81. Extensible.

82. Future proof. </li></ul>

83. Arbitro, ¡cambio!

84. Presencia SIP SIMPLE y XCAP more than voice...

85. Lo que conocemos...

86. Lo que conocemos... (II) <ul><li>XMPP </li><ul><li>IM y presencia </li><ul><li>Y la ñapa de “Jingle” para voz. </li></ul></ul><li>MSN </li><ul><li>IM, presencia y voz (limitada)

87. “Dicen” que usa una especie de SIP “custom” </li></ul><li>Skype </li><ul><li>IM, presencia y voz

88. Pero apesta </li></ul></ul>

89. Pero nos gusta la VoIP <ul><li>Venimos del mundo de la voz </li><ul><li>La prioridad es el teléfono

90. Y las funciones “molonas” de PBX </li><ul><li>¿Puedes montar una PBX “enterprise” con Skype? </li><ul><li>Amantes de chan_skype procedan a abandonar la sala. </li></ul></ul><li>Tenemos que añadir IM y presencia sobre nuestra infraestructura de VoIP (SIP) </li><ul><li>“ ¿Cómo hago?” </li></ul></ul></ul>

91. ¿SIP + XMPP? <ul><li>Solución híbrida </li><ul><li>PBX SIP + servidor XMPP </li></ul><li>Desventajas </li><ul><li>Doble mantenimiento de usuarios (ñapas)

92. Pocos terminales/softphones implementan bien ambos protocolos

93. “Integración” Asterisk + OpenFire... </li><ul><li>Hay vida más allá de Asterisk. En serio. </li></ul></ul><li>¿Alguna otra sugerencia? </li><ul><li>... </li></ul></ul>

95. SIP SIMPLE <ul><li>SIMPLE es un subgrupo de SIP que se encarga de IM y presencia </li><ul><li>Existen especificaciones muy completas </li><ul><li>RFC's de presencia: </li><ul><li>3856, 3857, 3858, 3863, 4479, 4480, 4482... </li></ul><li>RFC's de XCAP: </li><ul><li>4825, 4826, 4827, 5025... </li></ul><li>RFC's de IM: </li><ul><li>3428, 3994, 4975... </li></ul><li>OpenMobileAliance: XDM </li><ul><li>Un refrito de todo lo anterior. </li></ul></ul><li>“SIMPLE is not simple...” </li></ul></ul>

96. SUBSCRIBE <ul><li>Subscripción al estado de presencia de otro usuario

97. RFC 3856 </li><ul><li>[email_address] quiere conocer el estado de presencia de [email_address] .

98. [email_address] envía un SUBSCRIBE: </li></ul></ul>

99. SUBSCRIBE (II) <ul><ul><ul><ul><li>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: "IBC" <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 </li></ul></ul></ul></ul>

112. PUBLISH <ul><li>Un usuario publica su estado de presencia

113. RFC 3903 </li><ul><li>[email_address] publica su estado “online” enviando un PUBLISH al servidor de presencia: </li></ul></ul>

114. PUBLISH (II) <ul><ul><ul><li>PUBLISH sip:manwe@sipdoc.net SIP/2.0

115. Via: SIP/2.0/UDP 192.168.1.101:22630;branch=z9hG4bK754z

117. Contact: <sip:manwe@192.168.1.101:22630>

118. To: "Manwe"<sip:manwe@sipdoc.net>

119. From: "Manwe"<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

126. Content-Length: 419 </li></ul></ul></ul><ul><ul><ul><li><?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> </li></ul></ul></ul>

144. NOTIFY <ul><li>Recibimos notificaciones de cambio de presencia de un usuario

145. RFC 3856 </li><ul><li>[email_address] ha cambiado su estado y [email_address] recibe un NOTIFY: </li></ul></ul>

146. NOTIFY (II) <ul><ul><ul><ul><ul><li>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

156. Contact: <sip:presence@92.121.79.216:5065>

157. Subscription-State: active;expires=3550

158. Content-Type: application/pidf+xml

159. <?xml version="1.0" encoding="UTF-8"?>

160. <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:manwe@sipdoc.net">

161. <tuple id="xlglfs">

162. <status>

163. <basic>closed</basic>

164. </status>

165. </tuple>

166. </presence> </li></ul></ul></ul></ul></ul>

167. XCAP <ul><li>Protocolo sobre HTTP

168. RFC 4825 </li><ul><li>Para publicar, obtener, modificar y borrar documentos XML en un servidor: </li><ul><li>Lista de contactos (RFC 4826).

169. Reglas de privacidad de presencia (RFC 5025).

170. Publicación de estado por defecto (RFC 4827). </li></ul></ul><li>Interacción con el servidor de presencia </li><ul><li>El “presence server” obtiene estos documentos </li><ul><li>Ej: para decidir si un usuario puede ver el estado de otro. </li></ul></ul></ul>

171. XCAP (II) <ul><li>GET </li><ul><li>Obtener un documento o parte de él. </li></ul><li>PUT </li><ul><li>Publicar un documento o insertar elementos. </li></ul><li>DELETE </li><ul><li>Borrar un documento o parte de él. </li></ul></ul>

172. XCAP (III) <ul><ul><ul><ul><li>PUT /xcap-root/pres-rules/users/ibc@sipdoc.net/index HTTP/1.1

173. Content-Type: application/auth-policy+xml

175. <?xml version='1.0' encoding='UTF-8'?>

176. <cp:ruleset xmlns:pr="urn:ietf:params:xml:ns:pres-rules"

177. xmlns:cp="urn:ietf:params:xml:ns:common-policy">

178. <cp:rule id="pres_whitelist">

179. <cp:conditions>

180. <cp:identity>

181. <cp:one id="sip:manwe@sipdoc.net"/>

182. <cp:one id="sip:saghul@sipdoc.net"/>

183. </cp:identity>

184. </cp:conditions>

185. <cp:actions>

186. <pr:sub-handling>allow</pr:sub-handling>

187. </cp:actions>

188. </cp:rule> </li></ul></ul></ul></ul><ul><ul><ul><ul><li><cp:rule id="pres_blacklist">

189. <cp:conditions>

190. <cp:identity>

191. <cp:one id="sip:bill@microsoft.com"/>

192. </cp:identity>

193. </cp:conditions>

194. <cp:actions>

195. <pr:sub-handling>block</pr:sub-handling>

196. </cp:actions>

197. </cp:rule>

198. </cp:ruleset> </li></ul></ul></ul></ul>

199. XCAP (IV) <ul><li>Problemas de XCAP </li><ul><li>Especificaciones demasiado “amplias”.

200. Difícil interoperabilidad entre distintos clientes XCAP. </li><ul><li>No hay un formato XML “rígido”. </li></ul></ul><li>Alternativas </li><ul><li>XDM </li><ul><li>By OpenMobileAlliance (OMA).

201. Subconjunto de especificaciones XCAP + extensiones.

202. Previsto su uso en IMS (pero no exclusivo). </li></ul></ul></ul>

203. ¿Quién publica la presencia? <ul><li>Lo típico: online, busy, away... </li><ul><li>El propio usuario publica su estado de presencia (MSN, XMPP, Skype...)

204. O el propio software </li><ul><li>Estado “idle” (parado) al ausentarse del ordenador. </li></ul></ul><li>¿Acaso hay otras formas? </li></ul>

205. Presence Agent <ul><li>Un nodo publica presencia por nosotros </li><ul><li>Ubicado en la red, en un servidor...

206. Ejemplos: </li><ul><li>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... </li></ul></ul></ul>

209. Mensajería Instantánea <ul><li>MESSAGE </li><ul><li>RFC 3428

210. Un único mensaje </li><ul><li>Sin contexto

211. Tipo SMS </li></ul></ul></ul>

212. Mensajería Instantánea (II) <ul><ul><ul><ul><li>MESSAGE sip:manwe@sipdoc.net SIP/2.0

213. Via: SIP/2.0/UDP 192.168.1.101:6060;rport;branch=z9hG4bKpfsw

214. To: "manwe" <sip:manwe@sipdoc.net>

215. From: "IBC" <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

221. hola, tienes lista tu parte del VoIP2Day? </li></ul></ul></ul></ul>

222. Mensajería Instantánea (III) <ul><li>MSRP </li><ul><li>RFC 4975

223. Sessión de mensajería </li><ul><li>Los mensajes pertenecen a un contexto (sesión)

224. Incluye transferencia de ficheros </li></ul></ul></ul>

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... <ul><li>SIP SIMPLE es poderoso </li><ul><li>La inteligencia está en el protocolo y en los terminales </li><ul><li>...y no en una PBX a base de DTMF's. </li></ul><li>La presencia SIP SIMPLE tiene futuro </li><ul><li>Faltan buenas implementaciones. </li></ul></ul><li>¿Qué es IAX? </li><ul><li>¿...y qué más dá? </li></ul><li>¿Cómo voy de tiempo? </li></ul>

237. THE END <ul>BYE sip: [email_address] SIP/2.0 From: sip: [email_address] Content-Type: text/plain Accept: APLAUSOS, ABUCHEOS ¡Gracias! </ul>

238. THE END (II) <ul>REFER sip: [email_address] SIP/2.0 Refer-To: sip: [email_address] From: sip: [email_address] </ul>

239. VoIP en telefonía móvil e IMS

240. Estado actual

241. ¿Dónde estamos? <ul><li>Tenemos centralitas </li></ul>

242. ¿Dónde estamos? <ul><li>Tenemos infraestructuras de operador </li></ul>

243. ¿Dónde estamos? <ul><li>Tenemos buena presencia </li></ul>

244. ¿Qué falta? <ul><li>Ahora no estoy en casa o en el trabajo </li></ul>

245. ¿Qué falta? <ul><li>Sólo tengo el móvil </li></ul>

246. VOIP en la red móvil actual <ul><li>Tenemos terminales 3G </li></ul>

247. VOIP en la red móvil actual <ul><li>Las tarifas de datos son caras </li></ul>

248. VOIP en la red móvil actual <ul><li>Las aplicaciones están controladas </li></ul>

249. VOIP en la red móvil actual <ul><li>Podemos hacer jailbreaking </li></ul>

250. VOIP en la red móvil actual <ul><li>El contrato tiene letra pequeña </li></ul>

251. VOIP en la red móvil actual <ul><li>El panorama general... </li></ul>

252. VOIP en la red móvil actual <ul><li>Banda ancha en España </li></ul>

253. Cimientos <ul><li>La pregunta es sencilla: </li></ul>HOYGAN

254. Cimientos <ul><li>La respuesta no lo es: </li></ul>42

255. Soluciones en el cliente

256. Enlaces GSM - PBX <ul><li>¿Solución? más extendida </li></ul>

257. Enlaces GSM – PBX I <ul><li>Llamada entrante a DID </li></ul>PSTN Red móvil Notify!

258. Enlaces GSM – PBX II <ul><li>Llamada entrante a móvil </li></ul>PSTN Red móvil Notify!

259. Enlaces GSM – PBX III <ul><li>Es una ñapa: </li><ul><li>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. </li></ul></ul>

263. Enlatadas PBX-Móvil I <ul><li>Soluciones de convergencia PBX-móvil </li><ul><ul><li>Ej: Divitas </li></ul></ul></ul>

264. Enlatadas PBX-Móvil II <ul><li>Llamada entrante a DID </li></ul>PSTN Red móvil Notify

265. Enlatadas PBX-Móvil III <ul><li>Llamada saliente </li></ul>PSTN Red móvil Notify

266. Enlatadas PBX-Móvil IV <ul><li>Es una ñapa: </li><ul><li>Pero es una ñapa mejor.

267. Es cara.

268. Seguimos pagando todas las llamadas entrantes y salientes. </li></ul></ul>

269. Solución OMV

270. Solución OMV I <ul><li>Punto de partida... </li></ul>Red móvil Movil empresa X CDR

271. Solución OMV II <ul><li>Llegamos a un acuerdo... </li></ul>Red móvil Movil empresa X Red IP

272. Solución OMV III <ul><li>Llegamos a un acuerdo </li></ul>Red móvil Móvil empresa X Red IP #include operador SIP Empresa X Un móvil cualquiera

273. Solución OMV IV <ul><li>Ejemplo I </li></ul>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 <ul><li>Ejemplo II </li></ul>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 <ul><li>Ejemplo III </li></ul>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 <ul><li>Esto sí es una solución. </li><ul><li>Es del lado del operador.

277. Integración red móvil y red IP.

278. Convergencia real. </li></ul><li>Pero... seguimos teniendo red móvil. </li><ul><li>El terminal sigue siendo tonto. Nos enteramos de su estado pero él no se entera del estado de los demás. </li></ul></ul>

279. Solución IMS

280. Intro <ul><li>I p M ultimedia S ubsystem:

281. Arquitectura para el establecimiento de sesiones multimedia en redes IP. </li></ul>INTERNET RED MÓVIL

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

283. Ventajas <ul><li>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. </li></ul>

288. Requerimientos I <ul><li>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. </li></ul>

292. Requerimientos II <ul><li>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. </li></ul>

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 <ul><li>Contrato de servicio IMS.

298. Conexión a red IP.

299. Obtener dirección del proxy.

300. Registro en red IMS. </li></ul>

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." 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!" 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 "Somos los Borg. Serán asimilados. La resistencia es fútil.” Locutus Piccard

316. Agradecimientos <ul><li>Avanzada 7

317. Irontec y Xtratelecom

318. X. Caballero </li></ul>

319. Mayéutica

[VoIP2Day 2009] Presente y futuro de las comunicaciones VoIP

Iñaki Baz Castillo

[VoIP2Day 2009] Presente y futuro de las comunicaciones VoIP