Iba2008 Servicios

Slideshow Transcript

1. Slide 1: Aplicaciones y Servicios Multimedia Joaquín Salvachúa Antonio Fumero
2. Slide 2: Guión Real-time Transport Protocol Session Initiation Protocol Mensajería SIP/SIMPLE Mensajería XMPP
3. Slide 3: Integración Integración de VoIP con: – Web Web – Email Juegos Presencia – Presencia y mensajería voz Comunicaciones interactivas video instantánea – Chats textuales IM Chat – Juegos Interactivos Email Telefonía por Internet
4. Slide 4: Necesidad • Azar y necesidad: – Aparecen redes de banda ancha por aplicaciones – Aparecen nuevas aplicaciones que utilizan redes de banda ancha. • Concepto de “killer application” superado: – Killer Cocktail • No hay aplicaciones que sustituyen totalmente a todas – Teoria del TAMBIÉN.
5. Slide 5: Real-time Transport Protocol (RTP)
6. Slide 6: Problemas • TCP servía para todo excepto: – Envío de audio – Envío de vídeo – Envío de información en tiempo real. • Enfoque adaptativo no es suficiente
7. Slide 7: ¿Un protocolo nuevo? • TCP necesita retransmisión – Necesidad de vencimiento de temporizador – Puede que la información retransmitida sea demasiado antigua. • UDP no tiene confirmación ni datos sobre el contenido: • No existe concepto de calidad de servicio (QoS).
8. Slide 8: Dos protocolos • RTP – Encapsulación de trafico en tiempo real • RTCP – Protocolo de reserva y garantía de calidad de servicio a determinados flujos RTP. • Necesidad de garantías en todo el recorrido. • Parte de un esquema mayor a nivel global.
9. Slide 9: Arquitectura
10. Slide 10: Objetivos • El protocolo No garantiza nada, solo ofrece las facilidades necesarias para hacerlo. • No esta asociado con ninguna aplicación concreta. • Necesidad de una descripción de : – Perfil de tráfico. – Formato de codificación.
11. Slide 11: Objetivos • Ligero: Implementación simple. • Flexible: No indica algoritmos • Neutral frente transporte • Escalable: Unicast, multicast, broadcast • Separación de datos y control • Seguro: posibilidad de encriptación y autenticación.
12. Slide 12: Características • Datos – Temporización – Detección de perdidas – Etiquetado de contenidos • Control – Realimentación de QoS – Estimación de miembros y detección de bucles.
13. Slide 13: Funcionalidad • Segmentación realizada por UDP ó IP • Re-secuenciación de paquetes. • Detección de perdidas para estimación posterior. • Sincronización entre media – Sincronización labios y control de retrasos • Realimentación de QOS y Velocidad • Identificación de la fuente.
14. Slide 14: Posibles piezas • Mezcladores – Un flujo a partir de múltiples. – Reduce el ancho de banda. – Aparece como una nueva fuente. • Traducciones – Codificación de un solo media. – Puede ser translación de protocolo (firewall) – Cambio de codificación (ancho de banda).
15. Slide 15: Cabecera RTP • Payload type: Tipo de media contenido • SSRC: indicación de sincronización • sequence number: ++ para detectar perdidas. • P: padding (for encryption) • M: marker bit; Indica comienzo de frame para delay. • CC: content source count (for mixers) • CSRC: lista de identificadores en mezclas.
16. Slide 16: Temporización en RTP • Incrementado en 1 por cada muestra – (e.g. 160 for 20 ms packets @ 8000 Hz) • Comienzo aleatorio • Velocidad constante para el audio – (e.g. 8000 Hz for PCM-law, 44100 Hz for linear, 16-bit, 90 kHz for video) • Múltiples imágenes de vídeo pueden tener el mismo (en silencios).
17. Slide 17: RTP en una red • Típico : UDP, sin puerto fijo; RTCP port = RTP port (par) + 1 • Típicamente el paquete de UDP esta limitado a unos cientos de bytes (OS, network, fragmentación) • Necesidad de minimizar descarte y congestón.
18. Slide 18: RTCP ancho de banda • Cada participante envía un paquete RTCP para que se sepa quienes están escuchando. • Ancho de banda de la sesión: – Audio – N * flujos de video.
19. Slide 19: Sincronización entre flujos • Necesidad de establecer sincronización entre múltiples flujos (vídeo, audio, transparencias). • Necesidad de correlar los tics con tiempo real (depende de envío de temporizaciones aleatorias). • Correlarlas con la generación de muestras.
20. Slide 20: RTCP Paquetes almacenables (similares a datos). – sender report (SR): bytes enviados y velocidad. – reports (RR): Jitter, Round-trip delay, perdidas. – source description (SDES): nombre, email, localización – CNAME (canonical name = user@host) – explicit leave (BYE): para conocer quienes estan. – extensions (APP): definidos por la aplicación (aún ninguno)
21. Slide 21: Referencias • RTP: A Transport Protocol for Real Time Applications http://www.ietf.org.internet-drafts/draft-ietf-avt-rtp-new-02. • RTP Profile for Audio and Video Conferences with Minimal Control http://www.ietf.org.internet-drafts/draft-ietf-avt-profile-new- • The RTP specification is a product of the Audio Video Transport (AVP) http://www.ietf.org/html.charters/avt-charter.html. • http://www.cs.columbia.edu/~hgs/rtp/faq.html
22. Slide 22: SIP como protocolo para los servicios multimedia del futuro
23. Slide 23: Requisitos VR HD videoconf HD-VoD VideoConf VoD BW MM-IM Web NFS/SMB DBMS Text-IM Calendar Email Latencia
24. Slide 24: Visión General Signaling Quality of Service Media transport MGCP/Megaco Media encaps Application daemon (H.261,MPEG) SDP reservation H.323 SIP RTSP RSVP RTP network transport TCP UDP IPv4,IPv6 kernel PPP AAL3/4 AAL5 PPP link Physical Sonet ATM Ethernet V.34
25. Slide 25: SIP, H.323 y MGCP Control de la llamada Señalización Media Flujos multimedia Audio/ H.323 Video H.225 MGCP MEGACO H.245 Q.931 RAS SIP RTP RTCP RTSP TCP UDP IP
26. Slide 26: Arquitectura • Terminal: Dispositivo final del usuario. • Gateway: Traductor entre mundos no H.323 • Gatekeeper: Gestión de una zona, identificación y recursos. • MCU: Control y flujos multiusuario.
27. Slide 27: Protocolos Annex G Gatekeeper Gatekeeper Q.931/H.245 RAS Q.931/ Q.931/ RAS H.245 H.245 Signalling (Q.931) Endpoint H.245 Endpoint RTP/RTCP Gatekeeper Routed Signaling Direct Routed Signaling
28. Slide 28: Aplicaciones Text telephony H.324 H.320 H.323 T.120 Data Multimedia Multimedia Multimedia conferencing T.140 T.140 Voice T.140 Voice T.140 Voice T.140 and and and video video video Compatibility Trans- AL1 H.245 H.224 T.134 T.124 TCP H.245 equalizers parent Client 2 GCC H.223 H.221 H.225.0 V.18 Network Network T.123 V.34/V.80 access access PSTN PSTN ISDN IP Network Any Network Gateway functions, with transparent transmission of T.140 data between the different T.140 data channel types. T1607190-99
29. Slide 29: Terminal Video I/O Video Codec Equipment H.261, H.263 Receive Path Delay (jitter buffer) Audio Codec Audio I/O Equipment G.711, G.722 G.723, G.728 G.729 Local Area Network User Data Applications Interface H.225.0 Layer T.120, etc System Control H.245 Control System Control User Interface Call Control H.225.0 RAS Control H.225.0
30. Slide 30: SIP: Session Initiation Protocol • Estándar del IETF (RFC 3261) • Protocolo genérico de establecimiento de sesiones multimedia. • Interoperabilidad con anteriores VoIP. • Diseñado específicamente para IP e Internet: similar a HTTP. • Permitirá la aparición de nuevos servicios y aplicaciones • Escalable y flexible • Bajo coste de establecimiento de llamada.
31. Slide 31: Protocolos de tiempo real (IETF) – Control de flujos y sesión: SIP, RTSP – Descripción de los flujos: SDP – Transporte de datos t. Real: RTP / RTCP – Reserva de recursos (QoS): RSVP / DiffServ
32. Slide 32: Direccionamientos @ • La dirección SIP es similar a la de correo • No tiene porque ser IP: user@host. user@host • Por ejemplo, son URL: – sip:hostname@vovida.org – sip:hostname@192.168.10.1 – sip:14085551212@vovida.org
33. Slide 33: Componentes SIP Agentes de Usuario: – Cliente que inicia las llamadas – Modo cliente y servidor. Servidores – Proxy: Registration • Statefull: Con estado Server • Stateless: Sin estado. Redirect – Redirect Server – Registration Proxy Proxy Server Server UAC UAS
34. Slide 34: Es de Igual a Igual Peer-to-Peer SIP Components User Agent User Agent
35. Slide 35: Un sistema típico SIP Components Location Redirect Registrar Server Server Server PSTN User Agent Gateway Proxy Proxy Server Server
36. Slide 36: Despliegue SIP rtspd Quicktime RTSP media RTSP server Telephone sipconf RTSP clients SIP conference sipum Telephone SIP/RTSP server switch Unified Web based messaging configuration sipd Web T1/E1 SIP proxy, server redirect SQL RTP/SIP server database e*phone Cisco 2600 gateway Hardware Internet (SIP) sipc phones NetMeeting sip323 Software SIP SIPH.323 H.323 user agents convertor
37. Slide 37: Similar a HTTP
38. Slide 38: Mensajes SIP SIP Requests: SIP Responses: – INVITE – Initiates a call by inviting – 1xx - Informational user to participate in session. Messages. – ACK - Confirms that the client has received a final response to an – 2xx - Successful INVITE request. Responses. – BYE - Indicates termination of the – 3xx - Redirection call. Responses. – CANCEL - Cancels a pending – 4xx - Request Failure request. – REGISTER – Registers the user Responses. agent. – 5xx - Server Failure – OPTIONS – Used to query the Responses. capabilities of a server. – 6xx - Global Failures – INFO – Used to carry out-of-bound Responses. information, such as DTMF digits.
39. Slide 39: SIP / SIMPLE – Presencia Nueva entidad: Presence Agent – Entidad lógica – Conoce el estado del usuario – Recibe peticiones SUBSCRIBE – Genera respuestas NOTIFY – Co-located with proxy/registrar or User Agent
40. Slide 40: Señalización SIP
41. Slide 41: Jabber • Protocolo abierto basado en XML – Control de presencia – Mensajería instantánea • Extensible • Seguro • Distribuido • Descentralizado
42. Slide 42: Jabber (2) • Distintas implementaciones servidor de mensajería instantánea
43. Slide 43: XMPP
44. Slide 44: Cluster XMPP
45. Slide 45: Comunicación XMPP
46. Slide 46: Asterisk • Centralita PBX completa – Trabaja con la mayoría de protocolos VoIP • Soporta VoiceMail, IVR, perfiles de usarios (contexto,…) • Teléfonos SIP sin necesidad de licencia • Ampliamente documentado • Extensible (Seguridad ZRTP, SRTP,…)
47. Slide 47: Flash • Maquina virtual en cada navegador. • Similar a java. Mas especializado. Mayor integración con los SO. • Flex : modelo C-S para app. distribuidas.
48. Slide 48: FLV • Flash Video Format • http://osflash.org/flv
49. Slide 49: RTMP
50. Slide 50: RTMP • RTMP protocolo para enviar, en tiempo real, objetos, vídeo y audio usando una conexión TCP o HTTP. • Es un contenedor de paquete de datos de AMF, audio o FLV. • Una conexión puede multiplexar diversos canales. • Similar al SIP-Trunking o IAX2.
51. Slide 51: Tipos de datos 0×01 Chunk Size changes the chunk size for packets 0×02 Unknown anyone know this one? 0×03 Bytes Read send every x bytes read by both sides 0×04 Ping ping is a stream control message, has subtypes 0×05 Server BW the servers downstream bw 0×06 Client BW the clients upstream bw 0×07 Unknown anyone know this one? 0×08 Audio Data packet containing audio 0×09 Video Data packet containing video data 0x0A - 0xE Unknown anyone know? 0x0F Flex Stream Stream with variable length 0×10 Flex Shared Object Shared object with variable length 0×11 Flex Message Shared message with variable length 0×12 Notify an invoke which does not expect a reply 0×13 Shared Object has subtypes 0×14 Invoke like remoting call, used for stream actions too.
52. Slide 52: Conexión HTTP • RTMPT basically is a HTTP wrapper • Usa POST de cliente a servidor. • RTMPT requires the clients to poll for updates periodically in order to get notified about events that are generated by the server or other clients.
53. Slide 53: Mundos virtuales
54. Slide 54: Del ciberespacio al metaverso 1992 Metaverso Cyberspacio 1984
55. Slide 55: ¿Cambio de metáfora? MATRIX
56. Slide 56: Second first – Life is life
57. Slide 57: Elementos básicos HTTP cHTTP – certified HTTP REST LSL – Linden Scripting Language LLSD – Linden Lab Structured Data http://wiki.secondlife.com/wiki/Main_Page
58. Slide 58: Funcionamiento ..Each \"sim\" or simulator of a portion of the virtual world in Second Life is created on a server running Debian GNU/Linux, Apache, Squid and MySQL; currently there are several thousand of these PC boxes. To allow for fast response times, the virtual world is sent not as pixels or even as a mesh, but as a series of 3D primitives - \"prims\". The Second Life client creates the world by converting the stream of information about prims and their position into a visual representation...
59. Slide 59: Arquitectura Grid http://wiki.secondlife.com/wiki/Main_Page
60. Slide 60: Dominios separados http://wiki.secondlife.com/wiki/Main_Page
61. Slide 61: Escalabilidad http://wiki.secondlife.com/wiki/Main_Page
62. Slide 62: Multiversos
63. Slide 63: Identidad
64. Slide 64: Laws of identity 1. User Control and Consent. Technical identity systems must only reveal information identifying a user with the user’s consent 2. Minimal Disclosure for a Constrained Use. The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution. 3. Justifiable Parties. Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship. 4. Directed Identity. A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles. 5. Pluralism of Operators and Technologies. A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers 6. Human Integration. The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks. 7. Consistent Experience Across Contexts. The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies. http://www.identityblog.com/stories/2004/12/09/thelaws.html
65. Slide 65: mIDm 1. A user tries to access a page on a service to which a login is required. 2. The service obtains the user's mIDm server location from the user's browser header 3. The service redirects the user to the user's mIDm server along with a secret code 4. The user logs on to the mIDm server (typically using cookies) and stores the secret code on the mIDm server 5. The mIDm server returns the user to the service 6. The service then independently checks the mIDm server to see whether the code has been stored 7. The mIDm server returns the code and requested user information to the service 8. On receiving the code, the service is satisfied, and proceeds to log in the user http://www.downes.ca/cgi-bin/page.cgi?post=32667
66. Slide 66: OpenID – ¿Qué es? OpenID es un mecanismo de SSO distribuido Es un URI antoniofumero.myopenid.com https://irss.dit.upm.es/move/users/amfumero
67. Slide 67: OpenID – Elementos Identity provider Relying party End user / user agent
68. Slide 68: OpenID – ¿Cómo funciona?
69. Slide 69: OpenID – Elementos Identity provider Relying party End user / user agent
70. Slide 70: I4U – Mobile 2.0
71. Slide 75: SPAIN IS DIFFERENT