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.

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/2007 2 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/2007 3  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. 123 123 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/2007 4 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 1889.  RTSP (Real-Time Streaming Protocol) RFC 2326.  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/2007 5 Internet Protocols Slide thanks to Henning Schulzrinne

Transmisión de Datos Multimedia - Master IC 2006/2007 7 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/2007 8 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/2007 9 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/2007 10 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/2007 11 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/2007 12 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/2007 13 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/2007 14 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/2007 15 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/2007 16 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/2007 17 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/2007 18 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/2007 19 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/2007 20 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/2007 21 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/2007 22 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/2007 23 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/2007 24 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 26 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/2007 27 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/2007 28 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/2007 29 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/2007 30 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/2007 31 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/2007 32 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/2007 33 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/2007 34 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/2007 35 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/2007 36 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/2007 37 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/2007 38 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/2007 39 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/2007 40 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/2007 41 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/2007 42 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/2007 43 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/2007 44 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/2007 45 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/2007 46 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/2007 47 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/2007 48 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/2007 49 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/2007 50 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 52 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/2007 53 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/2007 54 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/2007 55 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/2007 56 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/2007 57 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/2007 58 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/2007 59 PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) ______________________________________________ 0 PCMU A 8000 1 1 1016 A 8000 1 2 G721 A 8000 1 3 GSM A 8000 1... 34-71 unassigned ? 72-76 reserved N/A N/A N/A 77-95 unassigned ? 96-127 dynamic ? PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) ______________________________________________ 0 PCMU A 8000 1 1 1016 A 8000 1 2 G721 A 8000 1 3 GSM A 8000 1... 34-71 unassigned ? 72-76 reserved N/A N/A N/A 77-95 unassigned ? 96-127 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/2007 60 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/2007 61 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/2007 62 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, e-mail, 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/2007 63 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/2007 64 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 66 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/2007 67 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/2007 68 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/2007 70 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/2007 71 RTSP: Una sesión completa (I) C->W: GET /twister.sdp HTTP/1.1 Host: www.example.com Accept: application/sdp W->C: HTTP/1.0 200 OK Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 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: www.example.com Accept: application/sdp W->C: HTTP/1.0 200 OK Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 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 1 3 2 4

Transmisión de Datos Multimedia - Master IC 2006/2007 72 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=3056-3057 A->C: RTSP/1.0 200 OK CSeq: 1 Session: 12345678 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 V->C: RTSP/1.0 200 OK CSeq: 1 Session: 23456789 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 A->C: RTSP/1.0 200 OK CSeq: 1 Session: 12345678 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 V->C: RTSP/1.0 200 OK CSeq: 1 Session: 23456789 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003

Transmisión de Datos Multimedia - Master IC 2006/2007 73 RTSP: Una sesión completa (III) C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00- V->C: RTSP/1.0 200 OK CSeq: 2 Session: 23456789 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 2 Session: 12345678 Range: smpte=0:10:00- A->C: RTSP/1.0 200 OK CSeq: 2 Session: 12345678 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=1032181 C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00- V->C: RTSP/1.0 200 OK CSeq: 2 Session: 23456789 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811 C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 2 Session: 12345678 Range: smpte=0:10:00- A->C: RTSP/1.0 200 OK CSeq: 2 Session: 12345678 Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=1032181

Transmisión de Datos Multimedia - Master IC 2006/2007 74 RTSP: Una sesión completa (IV) C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 3 Session: 12345678 A->C: RTSP/1.0 200 OK CSeq: 3 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 3 Session: 23456789 V->C: RTSP/1.0 200 OK CSeq: 3 C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 3 Session: 12345678 A->C: RTSP/1.0 200 OK CSeq: 3 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 3 Session: 23456789 V->C: RTSP/1.0 200 OK CSeq: 3

Transmisión de Datos Multimedia - Master IC 2006/2007 76 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  Voicemail notifications  Stock notifications  Callback notification  Fax over IP  Etc.

Transmisión de Datos Multimedia - Master IC 2006/2007 77 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/2007 78 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: -01 30 ASCII pages, 2 request types  01/1999: -12 149 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  http://www.cs.columbia.edu/~hgs/sip/implementations.html  http://www.pulver.com/sip/products.html

Transmisión de Datos Multimedia - Master IC 2006/2007 79 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/2007 80 4 IP SIP Phones and Adaptors 1 3 Analog phone adaptor Palm control 2 5 4  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/2007 81 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/2007 82 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/2007 83 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/2007 84 SIP Peer to Peer! Terminating User Agent Originating User Agent SIP RTP

Transmisión de Datos Multimedia - Master IC 2006/2007 85 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/2007 86 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/2007 87 SIP Flows - Basic ACK200 - OK INVITE: sip:18.18.2.4 “Calls” 18.18.2.4 180 - RingingRings200 - OKAnswersBYEHangs up RTP Talking User A User B

Transmisión de Datos Multimedia - Master IC 2006/2007 88 SIP INVITE INVITE sip:e9-airport.mit.edu SIP/2.0 From: "Dennis Baron" ;tag=1c41 To: sip:e9-airport.mit.edu Call-Id: call-1096504121-2@18.10.0.79 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/2.1.11 (WinNT) Date: Thu, 30 Sep 2004 00:28:42 GMT Via: SIP/2.0/UDP 18.10.0.79

Transmisión de Datos Multimedia - Master IC 2006/2007 89 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/2007 90 SDP v=0 o=Pingtel 5 5 IN IP4 18.10.0.79 s=phone-call c=IN IP4 18.10.0.79 t=0 0 m=audio 8766 RTP/AVP 96 97 0 8 18 98 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/2007 91 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/2007 92 SIP Flows - Registration 200 - OKREGISTER: sip:dbaron@MIT.EDU401 - Unauthorized User B MIT.EDU Registrar REGISTER: (add credentials) MIT.EDU Location sip:dbaron@MIT.EDU Contact 18.18.2.4

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

Transmisión de Datos Multimedia - Master IC 2006/2007 94 SIP REGISTER – 401 Response SIP/2.0 401 Unauthorized From: "Dennis Baron" ;tag=4561c4561 To: "Dennis Baron" ;tag=324591026 Call-Id: 9ce902bd23b070ae0108b225b94ac7fa Cseq: 5 REGISTER Via: SIP/2.0/UDP 18.10.0.79 Www-Authenticate: Digest realm="mit.edu", nonce="f83234924b8ae841b9b0ae8a92dcf0b71096505216", opaque="reg:change4" Date: Thu, 30 Sep 2004 00: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/2007 95 SIP REGISTER with Credentials REGISTER sip:mit.edu SIP/2.0 From: "Dennis Baron" ;tag=4561c4561 To: "Dennis Baron" ;tag=324591026 Call-Id: 9ce902bd23b070ae0108b225b94ac7fa Cseq: 6 REGISTER Contact: "Dennis Baron" Expires: 3600 Date: Thu, 30 Sep 2004 00:46:53 GMT Accept-Language: en Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/2.1.11 (WinNT) Content-Length: 0 Authorization: DIGEST USERNAME="6172531000@mit.edu", REALM="mit.edu", NONCE="f83234924b8ae841b9b0ae8a92dcf0b71096505216", URI="sip:mit.edu", RESPONSE="ae064221a50668eaad1ff2741fa8df7d", OPAQUE="reg:change4" Via: SIP/2.0/UDP 18.10.0.79

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

Transmisión de Datos Multimedia - Master IC 2006/2007 97 SIP Flows – Via Gateway INVITE: sip:joe@MIT.EDU “Calls” joe @MIT.EDU INVITE: sip:38400@18.162.0.25100 - TryingACK User A MIT.EDU Proxy 30161 Gateway 180 - Ringing Rings 200 - OK Answers BYEHangs up BYE 200 - OK Talking RTP

Transmisión de Datos Multimedia - Master IC 2006/2007 98 SIP INVITE with Record-Route INVITE sip:37669@18.162.0.25 SIP/2.0 Record-Route: From: \"Dennis Baron\" ;tag=2c41 To: sip:37669@mit.edu Call-Id: call-1096505069-3@18.10.0.79 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/2.1.11 (WinNT) Date: Thu, 30 Sep 2004 00:44:30 GMT Via: SIP/2.0/UDP 18.7.21.118:5080;branch=z9hG4bK2cf12c563cec06fd1849ff799d069cc0 Via: SIP/2.0/UDP 18.7.21.118;branch=z9hG4bKd26e44dfdc2567170d9d32a143a7f4d8 Via: SIP/2.0/UDP 18.10.0.79 Max-Forwards: 17

Transmisión de Datos Multimedia - Master IC 2006/2007 99 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/2007 100 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 - http://ietf.org/ids.by.wg/simple.htmlhttp://ietf.org/ids.by.wg/simple.html  SIP authenticated identity management -  http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-02.txt

Transmisión de Datos Multimedia - Master IC 2006/2007 102 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/2007 103 Terminals  Telephones  Video phones  IVR devices  Voicemail Systems  “Soft phones” (e.g., NetMeeting®)

Transmisión de Datos Multimedia - Master IC 2006/2007 104 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/2007 105 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/2007 106 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/2007 107 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/2007 108 The Protocols (cont)  H.323 is a “framework” document that describes how the various pieces fit together  H.225.0 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.225.0 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/2007 109 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.150.1 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/2007 110 Registration, Admission, and Status - RAS  Defined in H.225.0  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/2007 111 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/2007 112 H.225.0 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/2007 113 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/2007 114 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/2007 115 An H.323 Stack RAS RTP / RTCP Packet Network H.323 Application H.245 H.225.0 Call Signaling

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

Transmisión de Datos Multimedia - Master IC 2006/2007 117 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/2007 118 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/2007 119 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/2007 120 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/2007 121 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/2007 122 QoS  H.460.9 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/2007 123 H323 Clients O.S.ClientPrice WindowsNetMeeting +/- free Unix (Linux)DC-Share nv SunSunforum+/- free …...... You can find a bigger list at: http://www.openh323.org/h323_clients.html

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.

Presentaciones similares

Presentación del tema: "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."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

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.

Presentaciones similares

Presentación del tema: "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."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback