Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ Requisitos de red.  Se definen 3 parámetros críticos que la red debería suministrar a las aplicaciones multimedia:  Productividad (Throughput)  Número de bits que la red es capaz de entregar por unidad de tiempo (tráfico soportado).  CBR (streams de audio y vídeo sin comprimir)  VBR (ídem comprimido) –Ráfagas (Peak Bit Rate y Mean Bit Rate)  Retardo de tránsito (Transit delay) Retardo extremo-a-extremo Retardo de acceso Retardo de tránsito Retardo de transmisión Mensaje listo para envío Envío del primer bit del mensaje Primer bit del mensaje recibido Ultimo bit del mensaje recibido Retardo de acceso Mensaje listo para recepción

Transmisión de Datos Multimedia - Master IC 2006/  Varianza del retardo (Jitter)  Define la variabilidad del retardo de una red.  Jitter físico (redes de conmutación de circuito) –Suele ser muy pequeño ( ns )  LAN jitter (Ethernet, FDDI). –Jitter físico + tiempo de acceso al medio.  Redes WAN de conmutación de paquete (IP, X.25, FR) –Jitter físico + tiempo de acceso + retardo de conmutación de paquete en conmutadores de la red D1D1 D 2 = D 1 D 3 > D 1 t t Emisor Receptor Requisitos de red (II).

Transmisión de Datos Multimedia - Master IC 2006/ Internet y las aplicaciones multimedia  ¿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

Transmisión de Datos Multimedia - Master IC 2006/ Internet Protocols Slide thanks to Henning Schulzrinne

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ Scheduling And Policing Mechanisms  scheduling: choose next packet to send on link  FIFO (first in first out) scheduling: send in order of arrival to queue  discard policy: if packet arrives to full queue: who to discard?  Tail drop: drop arriving packet  priority: drop/remove on priority basis  random: drop/remove randomly

Transmisión de Datos Multimedia - Master IC 2006/ Scheduling Policies: more Priority scheduling: transmit highest priority queued packet  multiple classes, with different priorities  class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..

Transmisión de Datos Multimedia - Master IC 2006/ Scheduling Policies: still more round robin scheduling:  multiple classes  cyclically scan class queues, serving one from each class (if available)

Transmisión de Datos Multimedia - Master IC 2006/ Scheduling Policies: still more Weighted Fair Queuing:  generalized Round Robin  each class gets weighted amount of service in each cycle

Transmisión de Datos Multimedia - Master IC 2006/ Policing Mechanisms  Goal: limit traffic to not exceed declared parameters  Three common-used criteria:  (Long term) Average Rate: how many pkts can be sent per unit time (in the long run)  crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average!  Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate  (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle)

Transmisión de Datos Multimedia - Master IC 2006/ Policing Mechanisms Token Bucket: limit input to specified Burst Size and Average Rate.  bucket can hold b tokens  tokens generated at rate r token/sec unless bucket full  over interval of length t: number of packets admitted less than or equal to (r t + b).

Transmisión de Datos Multimedia - Master IC 2006/ Policing Mechanisms (more)  token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee! WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic

Transmisión de Datos Multimedia - Master IC 2006/ IETF Integrated Services  architecture for providing QOS guarantees in IP networks for individual application sessions  resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req’s  admit/deny new call setup requests: Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

Transmisión de Datos Multimedia - Master IC 2006/ Intserv: QoS guarantee scenario  Resource reservation  call setup, signaling (RSVP)  traffic, QoS declaration  per-element admission control  QoS-sensitive scheduling (e.g., WFQ) request/ reply

Transmisión de Datos Multimedia - Master IC 2006/ Call Admission Arriving session must :  declare its QOS requirement  R-spec: defines the QOS being requested  characterize traffic it will send into network  T-spec: defines traffic characteristics  signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required)  RSVP

Transmisión de Datos Multimedia - Master IC 2006/ Intserv QoS: Service models [RFC2211, RFC2212] Guaranteed service:  worst case traffic arrival: leaky- bucket-policed source  simple (mathematically provable) bound on delay [Parekh 1992, Cruz 1988] Controlled load service:  "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element." WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic

Transmisión de Datos Multimedia - Master IC 2006/ IETF Differentiated Services Concerns with Intserv:  Scalability: signaling, maintaining per-flow router state difficult with large number of flows  Flexible Service Models: Intserv has only two classes. Also want “qualitative” service classes  “behaves like a wire”  relative service distinction: Platinum, Gold, Silver Diffserv approach:  simple functions in network core, relatively complex functions at edge routers (or hosts)  Don’t define define service classes, provide functional components to build service classes

Transmisión de Datos Multimedia - Master IC 2006/ Edge router:  per-flow traffic management  marks packets as in-profile and out-profile Core router:  per class traffic management  buffering and scheduling based on marking at edge  preference given to in-profile packets  Assured Forwarding Diffserv Architecture scheduling... r b marking

Transmisión de Datos Multimedia - Master IC 2006/ Edge-router Packet Marking  class-based marking: packets of different classes marked differently  intra-class marking: conforming portion of flow marked differently than non-conforming one  profile: pre-negotiated rate A, bucket size B  packet marking at edge based on per-flow profile Possible usage of marking: User packets Rate A B

Transmisión de Datos Multimedia - Master IC 2006/ Classification and Conditioning  Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6  6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive  2 bits are currently unused

Transmisión de Datos Multimedia - Master IC 2006/ Classification and Conditioning may be desirable to limit traffic injection rate of some class:  user declares traffic profile (e.g., rate, burst size)  traffic metered, shaped if non-conforming

Transmisión de Datos Multimedia - Master IC 2006/ Forwarding (PHB)  PHB result in a different observable (measurable) forwarding performance behavior  PHB does not specify what mechanisms to use to ensure required PHB performance behavior  Examples:  Class A gets x% of outgoing link bandwidth over time intervals of a specified length  Class A packets leave first before packets from class B

Transmisión de Datos Multimedia - Master IC 2006/ Forwarding (PHB) PHBs being developed:  Expedited Forwarding: pkt departure rate of a class equals or exceeds specified rate  logical link with a minimum guaranteed rate  Assured Forwarding: 4 classes of traffic  each guaranteed minimum amount of bandwidth  each with three drop preference partitions

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ Signaling in the Internet connectionless (stateless) forwarding by IP routers best effort service no network signaling protocols in initial IP design + =  New requirement: reserve resources along end-to-end path (end system, routers) for QoS for multimedia applications  RSVP: Resource Reservation Protocol [RFC 2205]  “ … allow users to communicate requirements to network in robust and efficient way.” i.e., signaling !  earlier Internet Signaling protocol: ST-II [RFC 1819]

Transmisión de Datos Multimedia - Master IC 2006/ RSVP Design Goals 1. accommodate heterogeneous receivers (different bandwidth along paths) 2. accommodate different applications with different resource requirements 3. make multicast a first class service, with adaptation to multicast group membership 4. leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes 5. control protocol overhead to grow (at worst) linear in # receivers 6. modular design for heterogeneous underlying technologies

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: does not…  specify how resources are to be reserved  rather: a mechanism for communicating needs  determine routes packets will take  that’s the job of routing protocols  signaling decoupled from routing  interact with forwarding of packets  separation of control (signaling) and data (forwarding) planes

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: overview of operation  senders, receiver join a multicast group  done outside of RSVP  senders need not join group  sender-to-network signaling  path message: make sender presence known to routers  path teardown: delete sender’s path state from routers  receiver-to-network signaling  reservation message: reserve resources from sender(s) to receiver  reservation teardown: remove receiver reservations  network-to-end-system signaling  path error  reservation error

Transmisión de Datos Multimedia - Master IC 2006/ Call Admission  Session must first declare its QOS requirement and characterize the traffic it will send through the network  R-spec: defines the QOS being requested  T-spec: defines the traffic characteristics  A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required;  RSVP is a leading candidate for such signaling protocol

Transmisión de Datos Multimedia - Master IC 2006/ RSVP request (T-Spec)  A token bucket specification  bucket size, b  token rate, r  the packet is transmitted onward only if the number of tokens in the bucket is at least as large as the packet  peak rate, p  p > r  maximum packet size, M  minimum policed unit, m  All packets less than m bytes are considered to be m bytes  Reduces the overhead to process each packet  Bound the bandwidth overhead of link-level headers

Transmisión de Datos Multimedia - Master IC 2006/ Call Admission  Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

Transmisión de Datos Multimedia - Master IC 2006/ Integrated Services: Classes  Guaranteed QOS: this class is provided with firm bounds on queuing delay at a router; envisioned for hard real-time applications that are highly sensitive to end-to-end delay expectation and variance  Controlled Load: this class is provided a QOS closely approximating that provided by an unloaded router; envisioned for today’s IP network real-time applications which perform well in an unloaded network

Transmisión de Datos Multimedia - Master IC 2006/ R-spec  An indication of the QoS control service requested  Controlled-load service and Guaranteed service  For Controlled-load service  Simply a Tspec  For Guaranteed service  A Rate (R) term, the bandwidth required  R  r, extra bandwidth will reduce queuing delays  A Slack (S) term  The difference between the desired delay and the delay that would be achieved if rate R were used  With a zero slack term, each router along the path must reserve R bandwidth  A nonzero slack term offers the individual routers greater flexibility in making their local reservation  Number decreased by routers on the path.

Transmisión de Datos Multimedia - Master IC 2006/ QoS Routing: Multiple constraints  A request specifies the desired QoS requirements  e.g., BW, Delay, Jitter, packet loss, path reliability etc  Two type of constraints:  Additive: e.g., delay  Maximum (or Minimum): e.g., Bandwidth  Task  Find a (min cost) path which satisfies the constraints  if no feasible path found, reject the connection

Transmisión de Datos Multimedia - Master IC 2006/ Path msgs: RSVP sender-to-network signaling  path message contents:  address: unicast destination, or multicast group  flowspec: bandwidth requirements spec.  filter flag: if yes, record identities of upstream senders (to allow packets filtering by source)  previous hop: upstream router/host ID  refresh time: time until this info times out  path message: communicates sender info, and reverse-path-to- sender routing info  later upstream forwarding of receiver reservations

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: simple audio conference  H1, H2, H3, H4, H5 both senders and receivers  multicast group m1  no filtering: packets from any sender forwarded  audio rate: b  only one multicast routing tree possible H2 H5 H3 H4 H1 R1 R2R3

Transmisión de Datos Multimedia - Master IC 2006/ in out in out in out RSVP: building up path state  H1, …, H5 all send path messages on m1: (address=m1, Tspec=b, filter-spec=no-filter,refresh=100)  Suppose H1 sends first path message H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7 L5 L7 L6 L1 L2 L6L3 L7 L4 m1:

Transmisión de Datos Multimedia - Master IC 2006/ in out in out in out RSVP: building up path state  next, H5 sends path message, creating more state in routers H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7 L5 L7 L6 L1 L2 L6L3 L7 L4 L5 L6 L1 L6 m1:

Transmisión de Datos Multimedia - Master IC 2006/ in out in out in out RSVP: building up path state  H2, H3, H5 send path msgs, completing path state tables H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7 L5 L7 L6 L1 L2 L6L3 L7 L4 L5 L6 L1 L6 L7 L4 L3 L7 L2 m1:

Transmisión de Datos Multimedia - Master IC 2006/ reservation msgs: receiver-to-network signaling  reservation message contents:  desired bandwidth:  filter type:  no filter: any packets address to multicast group can use reservation  fixed filter: only packets from specific set of senders can use reservation  dynamic filter: senders who’s packets can be forwarded across link will change (by receiver choice) over time.  filter spec  reservations flow upstream from receiver-to-senders, reserving resources, creating additional, receiver-related state at routers

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: receiver reservation example 1 H1 wants to receive audio from all other senders  H1 reservation msg flows uptree to sources  H1 only reserves enough bandwidth for 1 audio stream  reservation is of type “no filter” – any sender can use reserved bandwidth H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7

Transmisión de Datos Multimedia - Master IC 2006/ in out RSVP: receiver reservation example 1  H1 reservation msgs flows uptree to sources  routers, hosts reserve bandwidth b needed on downstream links towards H1 H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7 L1 L2 L6 L1 (b)(b) in out L5 L6 L7 L5 (b)(b) L6 in out L3 L4 L7 L3 (b)(b) L4 L2 b b b b b b b m1:

Transmisión de Datos Multimedia - Master IC 2006/ in out RSVP: receiver reservation example 1 (more)  next, H2 makes no-filter reservation for bandwidth b  H2 forwards to R1, R1 forwards to H1 and R2 (?)  R2 takes no action, since b already reserved on L6 H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7 L1 L2 L6 L1 (b)(b) in out L5 L6 L7 L5 (b)(b) L6 in out L3 L4 L7 L3 (b)(b) L4 L2 b b b b b b b b b (b)(b) m1:

Transmisión de Datos Multimedia - Master IC 2006/ in out RSVP: receiver reservation: issues What if multiple senders (e.g., H3, H4, H5) over link (e.g., L6)?  arbitrary interleaving of packets  L6 flow policed by leaky bucket: if H3+H4+H5 sending rate exceeds b, packet loss will occur H2 H5 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L5 L6 L7 L1 L2 L6 L1 (b)(b) in out L5 L6 L7 L5 (b)(b) L6 in out L3 L4 L7 L3 (b)(b) L4 L2 b b b b b b b b b (b)(b) m1:

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: example 2  H1, H4 are only senders  send path messages as before, indicating filtered reservation  Routers store upstream senders for each upstream link  H2 will want to receive from H4 (only) H2 H3 H4 H1 R1 R2R3 L1 L2 L3 L4 L6 L7 H2 H3 L2 L3

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: example 2  H1, H4 are only senders  send path messages as before, indicating filtered reservation H2 H3 H4 H1 R1 R3 L1 L2 L3 L4 L6 L7 H2 H3 L2 L3 L2(H1-via-H1 ; H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) in out L6(H4-via-R3 ) L7(H1-via-R1 ) in out L1, L6 L6, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-R2 ) L7(H4-via-H4 ) in out L4, L7 R2

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: example 2  receiver H2 sends reservation message for source H4 at bandwidth b  propagated upstream towards H4, reserving b H2 H3 H4 H1 R1 R3 L1 L2 L3 L4 L6 L7 H2 H3 L2 L3 L2(H1-via-H1 ;H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) in out L6(H4-via-R3 ) L7(H1-via-R1 ) in out L1, L6 L6, L7 L3(H4-via-H4 ; H1-via-R2 ) L4(H1-via-62 ) L7(H4-via-H4 ) in out L4, L7 R2 (b) L1 b b b b

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: soft-state  senders periodically resend path msgs to refresh (maintain) state  receivers periodically resend resv msgs to refresh (maintain) state  path and resv msgs have TTL field, specifying refresh interval H2 H3 H4 H1 R1 R3 L1 L2 L3 L4 L6 L7 H2 H3 L2 L3 L2(H1-via-H1 ;H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) in out L6(H4-via-R3 ) L7(H1-via-R1 ) in out L1, L6 L6, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-62 ) L7(H4-via-H4 ) in out L4, L7 R2 (b) L1 b b b b

Transmisión de Datos Multimedia - Master IC 2006/ RSVP: soft-state  suppose H4 (sender) leaves without performing teardown H2 H3 H4 H1 R1 R3 L1 L2 L3 L4 L6 L7 H2 H3 L2 L3 L2(H1-via-H1 ;H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) in out L6(H4-via-R3 ) L7(H1-via-R1 ) in out L1, L6 L6, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-62 ) L7(H4-via-H4 ) in out L4, L7 R2 (b) L1 b b b b  eventually state in routers will timeout and disappear! gone fishing!

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ 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

Transmisión de Datos Multimedia - Master IC 2006/ 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 segmentos de audio pequeños (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.

Transmisión de Datos Multimedia - Master IC 2006/ RTP: Mezcladores y traductores  Mezcladores (Mixers).  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)

Transmisión de Datos Multimedia - Master IC 2006/ 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 RTP: Formato de mensaje (I) VPCCX M PTSequence number Timestamp Synchronization Source (SSRC) ID Contributing Source (CSRC) ID 32 bits

Transmisión de Datos Multimedia - Master IC 2006/ 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) RTP: Formato de mensaje (II) VPCCX M PTSequence number Timestamp Synchronization Source (SSRC) ID Contributing Source (CSRC) ID 32 bits

Transmisión de Datos Multimedia - Master IC 2006/ 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 RTP: Formato de mensaje (III) VPCCX M PTSequence number Timestamp Synchronization Source (SSRC) ID Contributing Source (CSRC) ID 32 bits

Transmisión de Datos Multimedia - Master IC 2006/ RTP header definition /* * RTP data header */ typedef struct { unsigned int version:2; unsigned int p:1; unsigned int x:1; unsigned int cc:4; unsigned int m:1; unsigned int pt:7; u_int16 seq; u_int32 ts; u_int32 ssrc; u_int32 csrc[1]; } rtp_hdr_t; /* * RTP data header */ typedef struct { unsigned int version:2; unsigned int p:1; unsigned int x:1; unsigned int cc:4; unsigned int m:1; unsigned int pt:7; u_int16 seq; u_int32 ts; u_int32 ssrc; u_int32 csrc[1]; } rtp_hdr_t;

Transmisión de Datos Multimedia - Master IC 2006/ 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 ? 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 ? RTP y las aplicaciones  La especificación de RTP para una aplicación particular va acompañada de:  Un perfil (profile) que defina 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 Ej.: RFC 1890 para audio y vídeo 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. 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.

Transmisión de Datos Multimedia - Master IC 2006/ 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.

Transmisión de Datos Multimedia - Master IC 2006/ 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

Transmisión de Datos Multimedia - Master IC 2006/ RTCP (RTP Control Protocol)  Formato de un paquete RTCP:  Existen distintos tipos de paquetes RTCP:  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).

Transmisión de Datos Multimedia - Master IC 2006/ RTCP: Mensajes SR VP RC PT=SR=200 Longitud SSRC del sender 32 bits 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 Retraso del último SR (LSR) Ultimo SR (LSR) Report block 1 Sender info cabecera

Transmisión de Datos Multimedia - Master IC 2006/ RTCP: Cálculo del Jitter  Es una estimación de la variancia del tiempo de inter- llegada de los paquetes RTP  S i  RTP timestamp del paquete i  R i  Instante de llegada del paquete i

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ 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

Transmisión de Datos Multimedia - Master IC 2006/ Terminología RTSP  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 Voz del público Imagen del conferenciante Imagen del público Imagen de las transparencias Voz del conferenciante

Transmisión de Datos Multimedia - Master IC 2006/ RTSP: Ejemplo de una sesión Web server SETUP PLAY PAUSE TEARDOWN HTTP GET descripción de la sesión RTP audio RTP vídeo RTCP Cliente Media server

Transmisión de Datos Multimedia - Master IC 2006/ 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" | "OPTIONS“ | "PAUSE" | "PLAY" | "RECORD" | "REDIRECT" | "SETUP" | "SET_PARAMETER" | "TEARDOWN" | extension-method extension-method = token Request-URI = "*" | absolute_URI RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT

Transmisión de Datos Multimedia - Master IC 2006/ RTSP: Mensajes de respuesta Response = Status-Line ; *(general-header |response-header |entity-header ) CRLF [ message-body ] 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)

Transmisión de Datos Multimedia - Master IC 2006/ RTSP: Una sesión completa (I) C->W: GET /twister.sdp HTTP/1.1 Host: Accept: application/sdp W->C: HTTP/ OK Content-Type: application/sdp 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 C->W: GET /twister.sdp HTTP/1.1 Host: Accept: application/sdp W->C: HTTP/ OK Content-Type: application/sdp 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 web server W cliente C media server A media server V

Transmisión de Datos Multimedia - Master IC 2006/ 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= 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=

Transmisión de Datos Multimedia - Master IC 2006/ 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= 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=

Transmisión de Datos Multimedia - Master IC 2006/ 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 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

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ Voice-over-Data (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.

Transmisión de Datos Multimedia - Master IC 2006/ Sesion Initiation Protocol  SIP is end-to-end, client-server session signaling protocol  SIP’s primarily provides presence and mobility  Protocol primitives: Session setup, termination, changes,...  Arbitrary services built on top of SIP, e.g.:  Redirect calls from unknown callers to secretary  Reply with a webpage if unavailable  Send a JPEG on invitation  Features:  Textual encoding (telnet, tcpdump compatible).  Programmability.  Post-dial delay: 1.5 RTT  Uses either UDP or TCP  Multicast/Unicast comm. support

Transmisión de Datos Multimedia - Master IC 2006/ SIP History  Work began in 1995 in IETF mmusic WG  02/1996: draft-ietf-mmusic-sip-00: 15 ASCII pages, one request type  12/1996: ASCII pages, 2 request types  01/1999: ASCII pages, 6 methods  03/1999: RFC 2543, 153 ASCII pages, 6 methods  11/1999: SIP WG formed  11/2000: draft-ietf-sip-rfc2543bis-02, 171 ASCII pages, 6 methods  12/2000: It was recognized that amount of work at SIP WG was becoming unmanageable; 1 RFC; 18 I-Ds on WG’s agenda; numerous individual submissions  04/2001: Proposal for splitting SIP WG into SIP and SIPPING announced  2001: SIP implementations widely available  

Transmisión de Datos Multimedia - Master IC 2006/ Where’s SIP Application Transport Network Physical/Data Link Ethernet IP TCPUDP RTSP SIP SDPcodecs RTPDNS (SRV)

Transmisión de Datos Multimedia - Master IC 2006/ IP SIP Phones and Adaptors 1 3 Analog phone adaptor Palm control  Are true Internet hosts  Choice of application  Choice of server  IP appliances  Implementations  3Com (3)  Columbia University  MIC WorldCom (2)  Mediatrix (1)  Nortel (4)  Siemens (5)

Transmisión de Datos Multimedia - Master IC 2006/ SIP Components  User Agents  UAC (user agent client): Caller application that initiates and sends SIP requests.  UAS (user agent server): Receives and responds to SIP requests on behalf of clients; accepts, redirects or refuses calls.  Server types  Redirect Server  Accepts SIP requests, maps the address into zero or more new addresses and returns those addresses to the client. Does not initiate SIP requests or accept calls.  Proxy Server  Contacts one or more clients or next-hop servers and passes the call requests further. Contains UAC and UAS.  Registrar Server  A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles.  Location Server  Provides information about a caller's possible locations to redirect and proxy servers. May be co-located with a SIP server.  Gateways  A Sip Gateway service allows you to call 'real' numbers from your software or have a dedicated 'real' telephone number which comes in via VoIP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Trapezoid DNS Server Location Server Terminating User Agent Outgoing Proxy Originating User Agent DNS SIP RTP Registrar Incoming Proxy SIP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Triangle? DNS Server Location Server Terminating User Agent Originating User Agent DNS SIP RTP Registrar Incoming Proxy SIP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Peer to Peer! Terminating User Agent Originating User Agent SIP RTP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Methods  INVITERequests a session  ACKFinal response to the INVITE  OPTIONSAsk for server capabilities  CANCELCancels a pending request  BYETerminates a session  REGISTERSends user’s address to server

Transmisión de Datos Multimedia - Master IC 2006/ SIP Responses  1XXProvisional100 Trying  2XXSuccessful200 OK  3XXRedirection302 Moved Temporarily  4XXClient Error404 Not Found  5XXServer Error504 Server Time-out  6XXGlobal Failure603 Decline

Transmisión de Datos Multimedia - Master IC 2006/ SIP Flows - Basic ACK200 - OK INVITE: sip: “Calls” RingingRings200 - OKAnswersBYEHangs up RTP Talking User A User B

Transmisión de Datos Multimedia - Master IC 2006/ SIP INVITE INVITE sip:e9-airport.mit.edu SIP/2.0 From: "Dennis Baron" ;tag=1c41 To: sip:e9-airport.mit.edu Call-Id: Cseq: 1 INVITE Contact: "Dennis Baron" Content-Type: application/sdp Content-Length: 304 Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Date: Thu, 30 Sep :28:42 GMT Via: SIP/2.0/UDP

Transmisión de Datos Multimedia - Master IC 2006/ Session Description Protocol  IETF RFC 2327  “SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.”  SDP includes:  The type of media (video, audio, etc.)  The transport protocol (RTP/UDP/IP, H.320, etc.)  The format of the media (H.261 video, MPEG video, etc.)  Information to receive those media (addresses, ports, formats and so on)

Transmisión de Datos Multimedia - Master IC 2006/ SDP v=0 o=Pingtel 5 5 IN IP s=phone-call c=IN IP t=0 0 m=audio 8766 RTP/AVP a=rtpmap:96 eg711u/8000/1 a=rtpmap:97 eg711a/8000/1 a=rtpmap:0 pcmu/8000/1 a=rtpmap:8 pcma/8000/1 a=rtpmap:18 g729/8000/1 a=fmtp:18 annexb=no a=rtpmap:98 telephone-event/8000/1

Transmisión de Datos Multimedia - Master IC 2006/ CODECs  GIPS Enhanced G.711  8kHz sampling rate  Voice Activity Detection  Variable bit rate  G.711  8kHz sampling rate  64kbps  G.729  8kHz sampling rate  8kbps  Voice Activity Detection

Transmisión de Datos Multimedia - Master IC 2006/ SIP Flows - Registration OKREGISTER: - Unauthorized User B MIT.EDU Registrar REGISTER: (add credentials) MIT.EDU Location Contact

Transmisión de Datos Multimedia - Master IC 2006/ SIP REGISTER REGISTER sip:mit.edu SIP/2.0 From: "Dennis Baron" ;tag=4561c4561 To: "Dennis Baron" ;tag= Call-Id: 9ce902bd23b070ae0108b225b94ac7fa Cseq: 5 REGISTER Contact: "Dennis Baron" Expires: 3600 Date: Thu, 30 Sep :46:53 GMT Accept-Language: en Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Content-Length: 0 Via: SIP/2.0/UDP

Transmisión de Datos Multimedia - Master IC 2006/ SIP REGISTER – 401 Response SIP/ Unauthorized From: "Dennis Baron" ;tag=4561c4561 To: "Dennis Baron" ;tag= Call-Id: 9ce902bd23b070ae0108b225b94ac7fa Cseq: 5 REGISTER Via: SIP/2.0/UDP Www-Authenticate: Digest realm="mit.edu", nonce="f b8ae841b9b0ae8a92dcf0b ", opaque="reg:change4" Date: Thu, 30 Sep :46:56 GMT Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, REGISTER, NOTIFY, SUBSCRIBE, INFO User-Agent: Pingtel/2.2.0 (Linux) Accept-Language: en Supported: sip-cc-01, timer Content-Length: 0

Transmisión de Datos Multimedia - Master IC 2006/ SIP REGISTER with Credentials REGISTER sip:mit.edu SIP/2.0 From: "Dennis Baron" ;tag=4561c4561 To: "Dennis Baron" ;tag= Call-Id: 9ce902bd23b070ae0108b225b94ac7fa Cseq: 6 REGISTER Contact: "Dennis Baron" Expires: 3600 Date: Thu, 30 Sep :46:53 GMT Accept-Language: en Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Content-Length: 0 Authorization: DIGEST REALM="mit.edu", NONCE="f b8ae841b9b0ae8a92dcf0b ", URI="sip:mit.edu", RESPONSE="ae064221a50668eaad1ff2741fa8df7d", OPAQUE="reg:change4" Via: SIP/2.0/UDP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Flows – Via Proxy INVITE: “Calls” INVITE: - Trying Ringing Rings180 - Ringing200 - OKAnswers OK ACK BYEHangs up200 - OK User A User B MIT.EDU Proxy Talking RTP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Flows – Via Gateway INVITE: “Calls” INVITE: - TryingACK User A MIT.EDU Proxy Gateway Ringing Rings OK Answers BYEHangs up BYE OK Talking RTP

Transmisión de Datos Multimedia - Master IC 2006/ SIP INVITE with Record-Route INVITE SIP/2.0 Record-Route: From: \"Dennis Baron\" ;tag=2c41 To: Call-Id: Cseq: 1 INVITE Contact: \"Dennis Baron\" Content-Type: application/sdp Content-Length: 304 Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Date: Thu, 30 Sep :44:30 GMT Via: SIP/2.0/UDP :5080;branch=z9hG4bK2cf12c563cec06fd1849ff799d069cc0 Via: SIP/2.0/UDP ;branch=z9hG4bKd26e44dfdc d9d32a143a7f4d8 Via: SIP/2.0/UDP Max-Forwards: 17

Transmisión de Datos Multimedia - Master IC 2006/ SIP Standards Just a sampling of IETF standards work… IETF RFCshttp://ietf.org/rfc.htmlhttp://ietf.org/rfc.html  RFC3261Core SIP specification – obsoletes RFC2543  RFC2327SDP – Session Description Protocol  RFC1889RTP - Real-time Transport Protocol  RFC2326RTSP - Real-Time Streaming Protocol  RFC3262SIP PRACK method – reliability for 1XX messages  RFC3263Locating SIP servers – SRV and NAPTR  RFC3264Offer/answer model for SDP use with SIP

Transmisión de Datos Multimedia - Master IC 2006/ SIP Standards (cont.)  RFC3265SIP event notification – SUBSCRIBE and NOTIFY  RFC3266IPv6 support in SDP  RFC3311SIP UPDATE method – eg. changing media  RFC3325Asserted identity in trusted networks  RFC3361Locating outbound SIP proxy with DHCP  RFC3428SIP extensions for Instant Messaging  RFC3515SIP REFER method – eg. call transfer  SIMPLEIM/Presence -  SIP authenticated identity management - 

Transmisión de Datos Multimedia - Master IC 2006/2007 Tema 3: Protocolos de transporte multimedia.  Requisitos de la red  Gestión de los recursos: IntServ vs DiffServ  RSVP  RTP/RTCP: Transporte de flujos multimedia  RTSP: Control de sesión y localización de medios  Protocolos para establecimiento y gestión de sesiones multimedia  SIP  H.323 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com) Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004.

Transmisión de Datos Multimedia - Master IC 2006/ Elements of an H.323 System  Terminals  Multipoint Control Units (MCUs)  Gateways  Gatekeeper  Border Elements Referred to as “endpoints”

Transmisión de Datos Multimedia - Master IC 2006/ Terminals  Telephones  Video phones  IVR devices  Voic Systems  “Soft phones” (e.g., NetMeeting®)

Transmisión de Datos Multimedia - Master IC 2006/ MCUs  Responsible for managing multipoint conferences (two or more endpoints engaged in a conference)  The MCU contains a Multipoint Controller (MC) that manages the call signaling and may optionally have Multipoint Processors (MPs) to handle media mixing, switching, or other media processing

Transmisión de Datos Multimedia - Master IC 2006/ Gateways  The Gateway is composed of a “Media Gateway Controller” (MGC) and a “Media Gateway” (MG), which may co-exist or exist separately  The MGC handles call signaling and other non-media-related functions  The MG handles the media  Gateways interface H.323 to other networks, including the PSTN, H.320 systems, and other H.323 networks (proxy)

Transmisión de Datos Multimedia - Master IC 2006/ Gatekeeper  The Gatekeeper is an optional component in the H.323 system which is primarily used for admission control and address resolution  The gatekeeper may allow calls to be placed directly between endpoints or it may route the call signaling through itself to perform functions such as follow-me/find-me and forward on busy

Transmisión de Datos Multimedia - Master IC 2006/ Border Elements and Peer Elements  Peer Elements, which are often co-located with a Gatekeeper, exchange addressing information and participate in call authorization within and between administrative domains  Peer Elements may aggregate address information to reduce the volume of routing information passed through the network  Border Elements are a special type of Peer Element that exists between two administrative domains  Border Elements may assist in call authorization/authentication directly between two administrative domains or via a clearinghouse

Transmisión de Datos Multimedia - Master IC 2006/ The Protocols (cont)  H.323 is a “framework” document that describes how the various pieces fit together  H defines the call signaling between endpoints and the Gatekeeper  RTP/RTCP (RFC 3550) is used to transmit media such as audio and video over IP networks  H Annex G and H.501 define the procedures and protocol for communication within and between Peer Elements  H.245 is the protocol used to control establishment and closure of media channels within the context of a call and to perform conference control

Transmisión de Datos Multimedia - Master IC 2006/ The Protocols (cont)  H.450.x is a series of supplementary service protocols  H.460.x is a series of version-independent extensions to the base H.323 protocol  T.120 specifies how to do data conferencing  T.38 defines how to relay fax signals  V defines how to relay modem signals  H.235 defines security within H.323 systems  X.680 defines the ASN.1 syntax used by the Recommendations  X.691 defines the Packed Encoding Rules (PER) used to encode messages for transmission on the network

Transmisión de Datos Multimedia - Master IC 2006/ Registration, Admission, and Status - RAS  Defined in H  Allows an endpoint to request authorization to place or accept a call  Allows a Gatekeeper to control access to and from devices under its control  Allows a Gatekeeper to communicate the address of other endpoints  Allows two Gatekeepers to easily exchange addressing information

Transmisión de Datos Multimedia - Master IC 2006/ Registration, Admission, and Status – RAS (cont) TGK RRQ RCF ARQ (endpoint is registered) ACF (endpoint may place call) DRQ DCF (call has terminated) T Terminal GK Gatekeeper GW Gateway Symbol Key:

Transmisión de Datos Multimedia - Master IC 2006/ H Call Signaling  Allows an endpoint to initiate and terminate a call with another endpoint GW Setup Alerting Connect (call is established) Release Complete (call is terminated) H.245 Signaling may take place at any point

Transmisión de Datos Multimedia - Master IC 2006/ Open a channel in each direction H.245 Signaling  H.245 is used to negotiate capabilities and to control aspects of the conference between two or more endpoints GW TCS + MSD TCS + TCS Ack + MSD Ack TCS Ack + MSD Ack + OLC OLC Ack + OLC OLC Ack

Transmisión de Datos Multimedia - Master IC 2006/ Fast Connect and H.245  Some H.323 calls do not utilize the rich capabilities offered by H.245 and simply media channels using the “Fast Connect” procedures  In this mode, a call may be established with as few as two messages (Setup / Connect) GW Setup Connect

Transmisión de Datos Multimedia - Master IC 2006/ An H.323 Stack RAS RTP / RTCP Packet Network H.323 Application H.245 H Call Signaling

Transmisión de Datos Multimedia - Master IC 2006/ H323 stack

Transmisión de Datos Multimedia - Master IC 2006/ Resolving Addresses  A Gatekeeper may resolve addresses in a number of ways  Sending a Location Request (LRQ) message to another Gatekeeper  Accessing a Peer Element  Accessing a back-end database (e.g., LDAP)  Gatekeepers and Peer Elements may query other Gatekeepers and Peer Elements and may exchange address information outside the context of a call  Since a Gatekeeper is not required, endpoints may resolve addresses themselves using, for example, DNS, LDAP, or a local “phonebook” containing static IP addresses

Transmisión de Datos Multimedia - Master IC 2006/ Using LRQs T GK LRQ GK ARQ LRQ  A Gatekeeper may send an LRQ to one ore more Gatekeepers  It may accept any LCF response and utilize that information to satisfy the original ARQ

Transmisión de Datos Multimedia - Master IC 2006/ Using LRQs with Hierarchical Gatekeepers (cont)  A Gatekeeper may forward an LRQ received on to another Gatekeeper in order to resolve the address  The response may be directed back to the originating Gatekeeper or the intermediate Gatekeeper T GK LRQ GK ARQ GK LRQ

Transmisión de Datos Multimedia - Master IC 2006/ Using a Border Element  As with hierarchical Gatekeepers, Border Elements may send AccessRequest messages to other Border Elements and indicate where to send a reply  Border Elements may also reply directly to a request by utilizing address information cached from previous exchanges with other Border Elements T GK LRQ GK/BE ARQ GK/BE AccessRequest

Transmisión de Datos Multimedia - Master IC 2006/ H.323 Features  Advanced Videoconferencing: Supports advanced videoconferencing features, including  Cascading MCUs  MCU control over audio and video mixing  Chair control  Far-end camera control  Standard mechanisms to provide a variety of services, including  Call transfer  Call forward  Call park/pick-up  Call Hold  Call Waiting  Message Waiting Indication  Call Completion on Busy / No-Answer  Call Intrusion  Support for HTTP-based service control (H.323 Annex K)

Transmisión de Datos Multimedia - Master IC 2006/ QoS  H allows an endpoint to report Quality of Service information to the Gatekeeper, aiding in determine how to route calls  H.323 devices may utilize IETF standards for providing quality of service, including DiffServ and RSVP

Transmisión de Datos Multimedia - Master IC 2006/ H323 Clients O.S.ClientPrice WindowsNetMeeting +/- free Unix (Linux)DC-Share nv SunSunforum+/- free … You can find a bigger list at: