Tema 6: Protocolos para aplicaciones multimedia.

Transcripción

1 Tema 6: Protocolos para aplicaciones multimedia. 1. Introducción. 2. IP multicast y MBONE 3. RSVP: Reserva de recursos en Internet. 4. RTP/RTCP: Transporte de flujos multimedia 5. RTSP: Control de sesión y localización de medios 6. Protocolos para establecimiento y gestión de sesiones multimedia SIP H.323 Bibliografía [FLU95] Fluckiger, "Understanding networked multimedia [KUR05] J. Kurose, K. Ross, Computer Networking: A Top Down Approach Featuring the Internet, [RFC1112] Host Extensions for IP Multicasting [RFC2236] Internet Group Management Protocol, Version 2 [Whi97] RSVP and Integrated Services in the Internet: A Tutorial [Kurose] RTP and RSVP introduction [RFC2326] Real Time Streaming Protocol [RFC2543] Session Initiation Protocol [h323turorial] H.323 Tutorial. Arquitecturas de red para la distribución de contenidos

2 Internet y las aplicaciones multimedia (I) Las aplicaciones multimedia requieren servicios de transporte específicos: Garantía de un ancho de banda (tasa de bits). Retardos y jitters acotados y constantes. Una tasa de error razonablemente baja. Mecanismos de difusión multidestino. En Internet, el protocolo IP ofrece el servicio de transporte de paquetes sin conexión: No existen mecanismos explícitos de control de flujo ni reserva de recursos en la red. Los paquetes pueden ser descartados, desordenados, dañados o retrasados. 2

3 Internet y las aplicaciones multimedia (II) Los routers IP son capaces de llegar a la utilización máxima del enlace (95%). Es independiente del hardware de red. Capacidad de difusiones multidestino. Soporta IP las demandas de las aplicaciones multimedia? Las redes IPv4 actuales NO ofrecen servicios de transporte con una cierta calidad de servicio (QoS) No se puede garantizar un ancho de banda, los retardos de tránsito pueden llegar a segundos, etc. Filosofía de las redes IP: Relegar a los extremos las tareas de recuperación ante las dificultades que la red introduce. 3

4 Internet y las aplicaciones multimedia (III) Qué podemos añadir a IP para soportar los requerimientos de las aplicaciones multimedia? Técnicas de ecualización de retardos (buffering) Protocolos de transporte que se ajusten mejor a las necesidades de las aplicaciones multimedia: RTP (Real-Time Transport Protocol) RFC RTSP (Real-Time Streaming Protocol) RFC Técnicas de control de admisión y reserva de recursos (QoS) RSVP (Resource reservation Protocol) RFC 2205 Arquitecturas y protocolos específicos: Protocolos SIP (RFC 2543), SDP (RFC 2327), SAP (RFC 2974), etc.. ITU H.323 IP define un mecanismo de difusión multidestino. 4

6 IP Multicast Imprescindibles para aplicaciones multimedia de difusión Videoconferencia, vídeo en demanda, difusión de canales de radio y TV, etc. En las redes IP se dispone de un mecanismo de difusión de paquetes multidestino: Direcciones multidestino (Grupo D) Protocolo IGMP (Internet Group Management Protocol) Gestión de grupos de difusión dentro de una red IP. Protocolos de encaminamiento multidestino: DVMRP, MOSPF, PIM, etc. MBONE: Red de difusión multidestino en Internet. 6

7 IP define direcciones multidestino (Clase D) Dirección de grupo (multidestino) Direcciones multidestino especiales: IP multicast: Direcciones : Reservada, no se puede utilizar : Identifica todos los hosts (y routers) que están participando en difusiones multidestino. (dentro de una red IP) Existen direcciones de grupo bien-conocidas que están reservadas para servicios estándar (RFC 1700). Ej.: , RWHOD Las direcciones multidestino SOLO pueden usarse como direcciones destino de un paquete IP. 7

8 IP multicast: Mapeo de direcciones Asignación de direcciones multidestino IP a direcciones HW (Ethernet) Ethernet dispone de mecanismos de difusión multidestino: Direcciones multidestino Ethernet: 01.xx.xx.xx.xx.xx Se utiliza una asignación directa: Los 23 bits de menor peso de la dirección IP se colocan en los 23 bits de menor peso de la dirección Hw multidestino: E Ej.: Dirección > E Asignación rápida y sencilla que evita la interferencia con direcciones Hw multidestino de otros protocolos. 8

9 IGMP (Internet Group Management Protocol) Define una serie de extensiones de IP: Formación y mantenimiento de grupos multidestino Altas, bajas, miembros de un grupo, etc. Comunicación con el router multicast Envío y recepción de mensajes multicast, consulta de grupos, etc. El protocolo IGMP define sus propios mensajes. Ver. IP multicast: Protocolo IGMP (RFC 1112) Tipo Cero Checksum Dirección multidestino (o cero) Versión (4 bits): Versión 1 (2). Tipo (4 bits): 1 (petición/consulta) y 2 (respuesta/afiliación). Cero (8 bits): No usado, debe contener ceros. Checksum (16 bits): Sobre todo el mensaje (algoritmo IP). Dirección multidestino (32 bits) 9

10 IP multicast: Protocolo IGMP. Los mensajes IGMP se encapsulan en paquetes IP con dirección destino y TTL = 1. Descripción del protocolo (versión 1) Los routers multicast envían periódicamente mensajes IGMP de consulta (cada 2 minutos aprox.). Los hosts participantes responden indicando sus direcciones de grupo activas (1 IGMP/grupo). Para evitar una explosión de mensajes IGMP: Cada host usa temporizadores aleatorios para retrasar las réplicas Si un host recibe un informe de otro host relativo a uno de sus grupos, cancela el temporizador correspondiente. Si el router multicast no recibe un informe de un grupo activo, deja de encaminar los mensajes del mismo. 10

11 Diagrama de estados de IGMP. No pertenencia Unirse al grupo/ Lanzar timer Abandonar grupo/ Cancelar timer IP multicast: Protocolo IGMP. Timer activo Abandonar grupo Llega informe/ Cancelar timer Vence el timer/ Enviar informe Llega petición/ Lanzar el timer Miembro del grupo Cada host deberá guardar información de los grupos multidestino a los que pertenece. Las aplicaciones que deseen recibir mensajes de un determinado grupo deberán indicarlo a IGMP. 11

12 MBONE (Multicast BackbONE). Es una red multicast utilizada para difundir sesiones de vídeo y audio en vivo. Desde 1992 ha estado transportando conferencias, congresos, eventos de todo tipo, permitiendo el estudio y desarrollo de técnicas multidestino sobre Internet. Su estructura se basa en la definición de islas multidestino conectadas entre sí por túneles IP. Cada isla (red IP) dispone de uno o varios routers multicast (mrouters). Los mrouters encaminan el tráfico multidestino desde o hacia su isla a través de los túneles IP. 12

13 H H Isla A MR R MBONE (Multicast BackbONE). Los túneles IP conectan los routers multicast de las diferentes islas (topología MBONE). Los mensajes multidestino (IP multicast) se encapsulan dentro de paquetes IP (unicast). Cada túnel tiene un coste (número de saltos, retardo, etc) Internet (sin soporte multicast) A Túnel IP H MR MR B R MR Isla B H H 13

14 MBONE: Encaminamiento multidestino Cómo se realiza el encaminamiento multidestino? No existe un estándar consensuado para el encaminamiento de los mensajes multidestino. Esto hace que la mayoría de routers convencionales de Internet no sepan encaminar los mensajes multidestino. Existen varias propuestas de algoritmos de encaminamiento, como: DVMRP (Distance Vector Multicast Routing Protocol). MOSPF (Multicast Open Shortest Path First) CBT (Core-Based Tree). PIM (Protocol Independent Multicast) MBONE sirve como plataforma para la experimentación de los protocolos de encaminamiento multidestino. 14

15 MBONE: El protocolo DVMRP (RFC 1075) DVMRP (Distance Vector Multicast Routing Protocol) Cada mrouter conoce las direcciones de grupo (canales multicast) que son de interés para su isla (IGMP). Cada mrouter dispone de una tabla que le dice la mejor ruta para alcanzar a cada una de las islas MBONE. Se actualiza periódicamente intercambiandola con sus vecinos A ab Dest link coste B ab 1 C ab 2 D ad 1 B Dest link coste A ab 1 C bc 1 D bc 2 ad bc C Dest link coste A bc 2 B bc 1 C cd 1 E ce 1 D cd Dest link coste A ad 1 B cd 2 C cd 1 E de 1 ce de E Dest link coste C ce 1 D de 1 15

16 MBONE: El protocolo DVMRP (II). Cuando un mroute recibe un paquete multicast, anota la identificación del túnel por el que ha llegado: Si es el túnel que usaría para alcanzar al emisor de ese paquete (ruta óptima) entonces lo difunde por todos los túneles activos. En caso contrario, lo elimina (Reverse Path Broadcasting). A B D C RPB incompleto E Se mejoraría el RPB (RPB completo) si: Un mrouter sólo encamina paquetes a un vecino si el enlace con él es el que éste utilizaría para alcanzar al origen. A B D C RPB completo E 16

17 Reverse Path Multicasting (RPM): MBONE: El protocolo DVMRP (III). Propagación de mensajes de poda desde aquellos nodos (mrouters) que no les interesa un grupo de difusión. A A B B (a) D D C C Mensaje de poda (c) Para limitar el alcance de las difusiones se usan: El campo TTL y el coste de los túneles. E E A A B B D (b) (d) C D C E Mensaje de poda E 17

18 MBONE: Protocolos de encaminamiento. El DVMRP es el algoritmo que se viene utilizando en MBONE (mrouted), aunque no el más eficiente. Existen otras propuestas como: MOSPF (Multicast Open Shortest Path First) RFC 1584 Se basa en el conocimiento de toda la topología MBONE sobre la que se calculan las rutas óptimas a cada isla (Dijstra). CBT (Core-Based Tree) RFC 2189 Define un árbol compartido para cada grupo multidestino. Este árbol es mantenido por un backbone de mrouters. Especialmente útil para grupos con varias fuentes. PIM (Protocol Independent Multicast) RFC 2117 Dos versiones: PIM-DM (similar a RPM) y PIM-SM (Una variante de CBT). 18

20 RSVP: Introducción RSVP (Resource reservation Protocol) es un protocolo para la reserva de recursos en los routers y en los hosts de Internet Realiza la reserva de recursos en conexiones (sesiones) multipunto-multipunto Es un protocolo simplex La reserva de los recursos se hace en una dirección Es orientado al receptor El receptor inicializa la reserva de los recursos Posibilidad de agrupar un conjunto heterogéneo de receptores Utiliza soft-states Permite una gestión dinámica de los miembros de un grupo y de los posibles cambios de ruta 20

21 RSVP: Un ejemplo (I) 21 Arquitecturas de red para la distribución de contenidos

22 RSVP: Un ejemplo (II) 22 Arquitecturas de red para la distribución de contenidos

23 Principios de diseño Reserva de los recursos iniciada por el receptor El receptor puede evaluar de forma directa las características con las que le llegan los datos Se evita que a la fuente les lleguen una cantidad alta de descripciones de peticiones de recursos Separación de la reserva de los recursos del filtrado de los paquetes Sólo especifica la cantidad de recursos que hay que reservar y para quien. Otra cosa es identificar los paquetes (flujos) que pueden utilizar esos recursos Disponibilidad de diferentes estilos para la reserva; como agregar reservas en un mismo grupo multicast No-filter Fixed-filter Dynamic-filter 23

24 Principios de diseño Mantener soft-states en la red Estado de la ruta (path state) mensajes PATH Generados periódicamente por las fuentes Uso del flag F Estado de las reservas (reservation state) mensajes RESV Generados periódicamente por los receptores Información que contiene: Quien hizo la reserva Un filtro Cantidad de recursos reservados Controlar la carga (overhead) del protocolo Modularidad Descripción de los flujos Protocolo de encaminamiento Control de admisión 24

25 ResvTear Elimina reservas PathTear Elimina información de estado acerca de las rutas ResvErr Informa sobre errores en el proceso de reserva PathErr Otros mensajes Informa sobre errores durante el procesamiento de un mensaje PATH 25

26 Routing Agent Input Driver Classifier Internet Forwarder RSVP Admission control RSVP en los routers Output Driver Policy Control packet scheduler 26

27 RSVP: Sink-tree RSVP permite establecer variables de estados en los routers a lo largo de ruta. Como las reservas son iniciadas por los receptores, RSVP tiene que garantizar que los paquetes de reserva sigan las rutas que utilizarán las fuentes Es necesario crear un sink-tree desde cada receptor hacia todas las fuentes H1 H2 S1 S2 S3 S4 H3 H5 H4 27

28 RSVP: Proceso de creación de las reservas Un nodo fuente envía periódicamente un mensaje PATH con las características del flujo (flowspec) Cuando un router recibe este mensaje actualiza o crea un nuevo elemento en su tablas de estado y lo reenvía (downstream) sobre le árbol multicast. El router determina el interfaz de salida apoyándose en el protocolo de encaminamiento Se actualiza la tabla de estado Los receptores reciben los mensajes PATH. Si están interesados en crear una reserva envían un mensaje RESV que contiene la flowspec que le ha llegado (es posible modificarla) Posibilidad de rechazo Envíos periódicos de mensajes RESV Los routers pueden combinar varias reservas 28

29 RSVP: Algunos ejemplos Un único grupo multicast La red tiene suficientes recursos para todos H2 L2 L3 H3 L6 S2 L7 S1 S3 L1 L5 L4 H4 H1 H5 29

30 Conferencia audio entre 5 participantes Hipótesis: Ya existe un árbol multicast PATH con F := OFF Todos los routers tienen la tabla de estado Ninguna reserva hecha H1 quiere recibir datos de todos y pide BW para un solo canal audio Envía RESV1(B, no-filter) a S1 S1 efectúa una reserva sobre L1 Ejemplo (reservas no-filter) (I) S1 S2 S3 IN-link L1,L2,L6 L5,L6,L7 L3,L4,L7 OUT-link L1,L2,L6 L5,L6,L7 L3,L4,L7 H2 H1 L2 S1 L1 L6 S2 L5 H5 L7 S3 S1 IN-link L1,L2,L6 OUT-link L1(B),L2,L6 L3 L4 H3 H4 30

31 Ejemplo (reservas no-filter) (II) S1 reenvía RESV1(B, no-filter) a todos los enlaces de salida, excluyendo L1 El mensaje llega a S2 y S3 que hacen las correspondientes reservas Ahora H2 quiere hacer su reserva Envía RESV2(B, no-filter) a S1 S1 actualiza su tabla de estado H2 S1 retransmite la petición sólo hacia L1 (por que hacia L6 ya lo hizo antes)... H1 L2 S1 L1 S1 IN-link L1,L2,L6 OUT-link L1(B),L2(B),L6 L6 S2 L5 H5 L7 S3 L3 L4 H3 H4 31

32 Ejemplo (reservas filtered) I Conferencia audio entre 5 participantes: H2-H5 son receptores y H1, H4 y H5 son fuentes PATH con F := ON Ninguna reserva hecha S1 ha recibido los mensajes PATH desde todas las fuentes S1 OUT-link L2(src:H1,H1 H4,S2 H5,S2),L6(src:H1,H1) H2 ahora envía un mensaje de reserva: RESV2(B, H4) S1 reserva B in L2 y re-envía el mensaje a S2 H2 H1 L2 S1 L1 L6 S2 L5 H5 L7 S3 L3 L4 H3 H4 32

33 Ejemplo (reservas filtered) II S2 OUT-link L5(src:H1,S1 H4,S3), L6(src:H4,S3 H5,H5),L7(src:H1,S1 H5,H5) S2 actualiza su tabla de estado reservando B en L6 y retransmite el mensaje a S3 S3 OUT-link L3(src:H1,S2 H4,H4 H5,S2), L4(src:H1,S2 H5,S2), L7(src:H4,H4) S3 reserva B en L7 y reenvía el mensaje a H4 H2 H1 L2 S1 L1 L6 S2 L5 H5 L7 S3 L3 L4 H3 H4 33

34 Ahora H5 envía RESV5(B, *) Cuando S2 recibe el mensaje Ejemplo (reservas filtered) III RESERVA 2B en L5 y REENVÍA el mensaje hacia L6 y L7 Cuando S1 recibe el mensaje descubre que solo hay una fuente que utilice L6 RESERVA B en L6 y REENVÍA el mensaje a H1 Cuando S3 recibe RESV5(B, *)... Descubre que sólo hay una fuente que utilice L7 y que ya se ha realizado una reserva fixed-filter NO reserva nada H2 H1 L2 S1 L1 L6 S2 L5 H5 L7 S3 L3 L4 dynamic-filter H3 H4 34

36 RTP (Real-time Transport Protocol) Se basa en el concepto de sesión: la asociación entre un conjunto de aplicaciones que se comunican usando RTP Una sesión es identificada por: Una dirección IP multicast Dos puertos: Uno para los datos y otro para control (RTCP) Un participante (participant) puede ser una máquina o un usuario que participa en una sesión Cada media distinto es trasmitido usando una sesión diferente. Por ejemplo, si se quisiera transmitir audio y vídeo harían falta dos sesiones separadas Esto permite a un participante solamente ver o solamente oír 36

37 RTP (Real-time Transport Protocol) Audio-conferencia con multicast y RTP Sesión de audio: Una dirección multicast y dos puertos Datos de audio y mensajes de control RTCP. Existirá (al menos) una fuente de audio que enviará un stream de pequeños segmentos de audio (20 ms) utilizando UDP. A cada segmento se le asigna una cabecera RTP La cabecera RTP indica el tipo de codificación (PCM, ADPCM, LPC, etc.) Número de secuencia y fechado de los datos. Control de conferencia (RTCP): Número e identificación de participantes en un instante dado. Información acerca de cómo se recibe el audio. Audio y Vídeo conferencia con multicast y RTP Si se utilizan los dos medios, se debe crear una sesión RTP independiente para cada uno de ellos. Una dirección multicast y 2 puertos por cada sesión. Existencia de participantes que reciban sólo uno de los medios. Temporización independiente de audio y vídeo. 37

38 Mezcladores (Mixers). RTP: Mezcladores y traductores Permiten que canales con un BW bajo puedan participar en una conferencia. El mixer re-sincroniza los paquetes y hace todas las conversiones necesarias para cada tipo de canal. Traductores (Translators). Permiten conectar sitios que no tienen acceso multicast (p.ej. que están en una sub-red protegida por un firewall) 38

39 VP 32 bits RTP: Formato de mensaje (I) X CC M PT Sequence number Timestamp Synchronization Source (SSRC) ID Contributing Source (CSRC) ID V: versión; actualmente es la 2 P: si está a 1 el paquete tiene bytes de relleno (padding) X: presencia de una extensión de la cabecera 39

40 VP RTP: Formato de mensaje (II) 32 bits X CC M PT Sequence number Timestamp Synchronization Source (SSRC) ID Contributing Source (CSRC) ID CC: Identifica el número de CSRC que contribuyen a los datos M: Marca (definida según el perfil) PT: Tipo de datos (según perfil) 40

41 VP RTP: Formato de mensaje (III) 32 bits X CC M PT Sequence number Timestamp Synchronization Source (SSRC) ID Contributing Source (CSRC) ID Sequence number: Establece el orden de los paquetes Timestamp: Instante de captura del primer octeto del campo de datos SSRC: Identifica la fuente de sincronización CSRC: Fuentes que contribuyen 41

42 La especificación de RTP para una aplicación particular va acompañada de: Un perfil (profile) que define un conjunto de códigos para los tipos de datos transportados (payload) El formato de transporte de cada uno de los tipos de datos previstos RTP y las aplicaciones Ej.: RFC 1890 para audio y vídeo PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) 0 PCMU A A G721 A GSM A unassigned? reserved N/A N/A N/A unassigned? dynamic? PCMU Corresponde a la recomendación CCITT/ITU-T G.711. El audio se codifica con 8 bits por muestra, después de una cuantificación logarítmica. PCMU es la codificación que se utiliza en Internet para un media de tipo audio/basic. 42

43 RTCP (RTP Control Protocol) RTCP se basa en envíos periódicos de paquetes de control a los participantes de una sesión RTP Permite realizar una realimentación de la calidad de recepción de los datos (estadísticas). Los paquetes de control siempre llevan la identificación de la fuente RTP: CNAME Asociar más de una sesión a un mismo fuente (sincronización). El envío de estos paquetes debe ser controlado por cada participante (sistema ampliable). Control de sesión (opcional) Información adicional de cada participante. Entrada y salida de participantes en las sesión. Negociación de parámetros y formatos. 43

44 RTCP (RTP Control Protocol) RTCP permite controlar el trafico que no se auto-limita (p.ej cuando el número de fuentes aumenta) Para ello se define el ancho de banda de la sesión. RTCP se reserva el 5% (bwrtcp) A cada fuente se le asigna 1/4 de bwrtcp El intervalo entre cada paquete RTCP es > 5 sec 44

45 Formato de un paquete RTCP: Existen distintos tipos de paquetes RTCP: RTCP (RTP Control Protocol) SR (Sender Report): Informes estadísticos de transmisión y recepción de los elementos activos en la sesión. RR (Receiver Report): Informes estadísticos de recepción en los receptores. SDES (Source Description): Información del participante (CNAME, , etc). BYE: Salida de la sesión. APP: Mensajes específicos de la aplicación. Cada paquete RTCP tiene su propio formato. Su tamaño debe ser múltiplo de 32 bits (padding). Se pueden concatenar varios paquetes RTCP en uno (compound RTCP packet). 45

46 cabecera Sender info Report block 1 32 bits RTCP: Mensajes SR V P RC PT=SR=200 Longitud SSRC del sender NTP timestamp msw NTP timestamp lsw RTP timestamp Contador de los paquetes del sender Contador de los bytes del sender SSRC_1 Frac perd Total paquetes perdidos Num sec más alto recibido Jitter de inter-llegada Ultimo SR (LSR) Retraso del último SR (LSR) 46

47 47 RTCP: Cálculo del Jitter Es una estimación de la variancia del tiempo de interllegada de los paquetes RTP S i RTP timestamp del paquete i R i Instante de llegada del paquete i ) ( ) ( ) ( ) ( ), ( i i j j i j i j S R S R S S R R j i D 16 /, i i i J i D i J J

49 Real-Time Streaming Protocol RFC 2326 Tiene la función de un mando a distancia por la red para servidores multimedia Permite establecer y controlar uno o más flujos de datos sincronizados NO existe el concepto de conexión RTSP sino de sesión RTSP Además, una sesión RTSP no tiene relación con ninguna conexión especifica de nivel transporte (p.ej. TCP o UDP) Los flujos de datos no tienen por que utilizar RTP Está basado en HTTP/1.1 Diferencias importantes: No es stateless Los clientes y servidores pueden generar peticiones 49

50 Conferencia Media stream Una instancia única de un medio continuo: Un stream audio, Un stream vídeo Una whiteboard Presentación: Es el conjunto de uno o más streams, que son vistos por el usuario como un conjunto integrado Imagen de las transparencias Imagen del público Terminología RTSP Voz del conferenciante Imagen del conferenciante Voz del público 50

51 Cliente RTSP: Ejemplo de una sesión HTTP GET descripción de la sesión SETUP PLAY RTP audio RTP vídeo RTCP PAUSE TEARDOWN Media server Web server 51

52 RTSP: Comandos de petición Request = Request-Line ; *( general-header request-header entity-header ) CRLF [ message-body ] Request-Line = Method SP Request-URI SP RTSP-Version CRLF Method = "DESCRIBE "ANNOUNCE" "GET_PARAMETER" extension-method = token "OPTIONS "PAUSE" "PLAY" "RECORD" "REDIRECT" "SETUP" "SET_PARAMETER" "TEARDOWN" extension-method Request-URI = "*" absolute_uri RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT 52

53 Response = Status-Line ; *( general-header response-header entity-header ) CRLF [ message-body ] RTSP: Mensajes de respuesta Status-Line = RTSP-version SP Status-Code SP Reason-Phrase CRLF Status-Code = 1xx: Información (Comando recibido, procesando,..) 2xx: Exito (Comando recibido y ejecutado con éxito) 3xx: Re-dirección (Comando recibido pero aún no completado) 4xx: Error del cliente (El comando tiene errores de sintaxis) 5xx: Error del servidor (Error interno del servidor) 53

54 web server W 1 cliente C C->W: GET /twister.sdp HTTP/1.1 Host: Accept: application/sdp W->C: HTTP/ OK Content-Type: application/sdp RTSP: Una sesión completa (I) 2 3 media server A media server V v=0 o= IN IP s=rtsp Session m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio.en m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video 4 54

55 RTSP: Una sesión completa (II) C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port= A->C: RTSP/ OK CSeq: 1 Session: Transport: RTP/AVP/UDP;unicast;client_port= ; server_port= C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port= V->C: RTSP/ OK CSeq: 1 Session: Transport: RTP/AVP/UDP;unicast;client_port= ; server_port=

56 RTSP: Una sesión completa (III) C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: Range: smpte=0:10:00- V->C: RTSP/ OK CSeq: 2 Session: Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq= ;rtptime= C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 2 Session: Range: smpte=0:10:00- A->C: RTSP/ OK CSeq: 2 Session: Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=

57 RTSP: Una sesión completa (IV) C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 3 Session: A->C: RTSP/ OK CSeq: 3 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 3 Session: V->C: RTSP/ OK CSeq: 3 57

59 What is Voice Over Data? Voice over Data (VoD) transmits traditional voice services over data networks. Such data networks can be Frame Relay (VoFR), ATM (VoATM) or IP (VoIP). Voice is usually compressed to save bandwidth Internet phone can provide very low-cost, long-distance and international phone calls. Internet traffic quickly surpasses voice traffic in volume; therefore, why transfer data over voice networks (e.g. today s modems) when you can optimize for data and transfer voice over data? New carriers can build a single, integrated data network to support both voice and data services. Delta-3, IDT and others already implement VoD phone calls 59

60 VoD Enables New Applications Click to talk web sites for e-commerce Digital white-board conferences Broadcast audio and video over the Internet or a corporate Intranet Integrated messaging: check (or leave) voice mail over the Internet Instant messaging Voic notifications Stock notifications Callback notification Fax over IP Etc. 60

61 Routing a call over the Internet PC-to-PC (MS NetMeeting, appliances) PC-to-phone (net2phone.com) phone-to-phone (Paegas) PSTN Phone IP Phone IP Phone Ingress PSTN Gateway Internet Internet Internet Internet Telephony Egress PSTN Gateway Egress PSTN Gateway PSTN Phone PSTN Phone 61

62 What protocols are needed? Signaling protocol to establish presence, locate users, set up, modify and tear down sessions SIP/SDP (IETF) Adopted by 3gpp Lower production and operation costs H.323 (ITU-T) Media Transport Protocols for transmission of packetized audio/video Media: RTP (IETF s, adopted by ITU-T) Transport: UDP, TCP, (Stream Control Transmission Protocol RFC 2960) Supporting Protocols Gateway Location, QoS, interdomain AAA (Authentication, Authorization and Accounting), address translation, IP, etc. DNS, TRIP, RSVP, RTSP, etc. 62