Tema 3: Protocolos de transporte multimedia.

(1)

Tema 3:

Protocolos de transporte multimedia.

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 _Asterisk

(2)

T ra n sm is ió n d e D a to s M u lt im e d ia -M a st e r IC 2 0 0 7 /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}

₎

Mensaje listo para envío

Envío del primer

(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.

1 2 3 1 2 3 D₁ D₂= D₁ D₃> D₁ t t Emisor Receptor

(4)

T ra n sm is ió n d e D a to s M u lt im e d ia -M a st e r IC 2 0 0 7

/2

_{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:}

(5)

_{Internet Protocols}

(6)

Tema 3:

Protocolos de transporte multimedia.

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

Computer Networking: A Top Down Approach Featuring the Internet, 3rd _edition.

Jim Kurose, Keith Ross Addison-Wesley, July 2004.

(7)

/2

_{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}

(8)

/2

_{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..

(9)

/2

_{Scheduling Policies: still more}

round robin scheduling:

_{multiple classes}

_{cyclically scan class queues, serving one from each class (if}

(10)

/2

_{Scheduling Policies: still more}

Weighted Fair Queuing:

_{generalized Round Robin}

(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}

(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}

(13)

/2

_{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

(14)

/2

_{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?

(15)

/2

_{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

(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)

(17)

/2 _{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 arriving traffic

(18)

/2

_{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}

(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

Diffserv Architecture

scheduling

..

.

r

b

marking

(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

(21)

/2

_{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

(22)

/2

_{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}

(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

(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}

(25)

Tema 3:

Protocolos de transporte multimedia.

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

(26)

/2

_{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 !

(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

(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}

(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}

(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;

(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}

(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.

(33)

/2

_{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

(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

(35)

/2

_{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}

(36)

/2

_{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

(37)

/2

_{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 H3

H4 H1

(38)

T ra n sm is ió n d e D a to s M u lt im e d ia -M a st e r IC 2 0 0 7 /2 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 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7 L5 L7 L6 L1 L2 L6 L3 L7 L4 m1: m1: m1:

(39)

RSVP: building up path state

_{next, H5 sends path message, creating more state in routers}

H2 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7 L5 L7 L6 L1 L2 L6 L3 L7 L4 L5 L6 L1 L6 m1: m1: m1:

(40)

RSVP: building up path state

_{H2, H3, H5 send path msgs, completing path state tables}

H2 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7 L5 L7 L6 L1 L2 L6 L3 L7 L4 L5 L6 L1 L6 L7 L4 L3 L7 L2 m1: m1: m1:

(41)

/2

_{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}

(42)

/2

_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 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7

(43)

T ra n sm is ió n d e D a to s M u lt im e d ia -M a st e r IC 2 0 0 7 /2 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 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7 L1 L2 L6 L6 L1(b₎ in out L5 L6 L7 L7 L5 (b) L6 in out L3 L4 L7 L7 L3 (b) L4 L2 b b b b b b b m1: m1: m1:

(44)

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 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7 L1 L2 L6 L6 L1(b) in out L5 L6 L7 L7 L5 (b) L6 in out L3 L4 L7 L7 L3 (b) L4 L2 b b b b b b b b b (b₎ m1: m1: m1:

(45)

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 H3 H4 H1 R1 _R2 _R3 L1 L2 L3 L4 L5 L6 L7 L1 L2 L6 L6 L1(b) in out L5 L6 L7 L7 L5 (b) L6 in out L3 L4 L7 L7 L3 (b) L4 L2 b b b b b b b b b (b₎ m1: m1: m1:

(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 _R2 _R3 L1 L2 L3 L4 L6 L7 H2 H3 L2 L3

(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 in L1, L6 L6, L7 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-R2 ) L7(H4-via-H4 ) in out L4, L7 R2

(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 L1, L6 L3(H4-via-H4 ; H1-via-R2 ) L4(H1-via-62 ) L7(H4-via-H4 ) in out L4, L7 R2 (b) (b) L1 b b b b

(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}

(50)

_RSVP:

_soft-state

_{suppose H4 (sender) leaves without performing teardown}

_{eventually state in routers will timeout and disappear!}

gone fishing!

(51)

Tema 3:

Protocolos de transporte multimedia.

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

(52)

/2

_{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.

(53)

/2

_{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}

(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.}

(55)

T ra n sm is ió n d e D a to s M u lt im e d ia -M a st e r IC 2 0 0 7 /2 V: versión; actualmente es la 2

P: si está a 1 el paquete tiene bytes de relleno (padding)

RTP: Formato de mensaje (I)

V PX CC M PT Sequence number

Timestamp

Synchronization Source (SSRC) ID

Contributing Source (CSRC) ID 32 bits

(56)

CC: Identifica el número de CSRC que contribuyen a los datos

RTP: Formato de mensaje (II)

Timestamp

(57)

Sequence number: Establece el orden de los paquetes

Timestamp: Instante de captura del primer octeto del campo de datos

RTP: Formato de mensaje (III)

Timestamp

(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;

(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

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

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

(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)}

(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}

(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}

(63)

_{RTCP: Mensajes SR}

V P 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 Ultimo SR (LSR) Report block 1 Sender info cabecera

(64)

/2

_{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}

)

(

)

(

)

(

)

(

)

,

(

i

j

R

j

R

i

S

j

S

i

R

j

S

j

R

i

S

i

D

=

−

=

−

(

)

(

1 ,

1

)

/

16

1 − −

+

−

=

i i i

J

D

i

J

(65)

Tema 3:

Protocolos de transporte multimedia.

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

(66)

/2

_{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}

(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

Voz del _público

Imagen del conferenciante Imagen del público Imagen de las transparencias Voz del conferenciante

(68)

/2

_{RTSP: Ejemplo de una sesión}

Web server SETUP PLAY PAUSE HTTP GET descripción de la sesión RTP audio RTP vídeo RTCP Cliente Media server

(69)

_{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

(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)

(71)

/2

_{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 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 web server W cliente C media server A media server V 1 3 2 4

(72)

/2

_{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

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;

(73)

/2

_{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 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

(74)

/2

_{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

(75)

Tema 3:

Protocolos de transporte multimedia.

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

(76)

/2

_{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}

(77)

/2

_{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}

(78)

_{Where’s SIP}

Application Transport Network

Physical/Data Link _Ethernet IP

TCP UDP

RTSP SIP

SDP codecs

(79)

4 IP SIP Phones and Adaptors

1

3 Analog phone adaptor

Palm control

2 Are true Internet

hosts

Choice of application Choice of server IP appliances

Implementations

3Com (3) Columbia University MIC WorldCom (2) Mediatrix (1) Nortel (4)

(80)

_{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.}

(81)

_{SIP Trapezoid}

DNS Server Location Server Terminating User Agent Outgoing Proxy Originating User Agent DNS SIP SIP SIP SIP RTP Registrar Incoming Proxy SIP

(82)

_{SIP Triangle?}

DNS Server Location Server Terminating User Agent Originating User Agent DNS SIP SIP SIP RTP Registrar Incoming Proxy SIP

(83)

/2

_{SIP Peer to Peer!}

Terminating User Agent Originating User Agent SIP RTP

(84)

_{SIP Methods}

_INVITE _{Requests a session}

_ACK _{Final response to the INVITE}

_OPTIONS _{Ask for server capabilities}

_CANCEL _{Cancels a pending request}

_BYE _{Terminates a session}

(85)

_{SIP Responses}

_1XX _Provisional _{100 Trying} _2XX _Successful _{200 OK}

_3XX _Redirection _{302 Moved Temporarily}

_4XX _{Client Error} _{404 Not Found}

_5XX _{Server Error} _{504 Server Time-out}

(86)

/2

_{SIP Flows - Basic}

ACK 200 - OK INVITE: sip:18.18.2.4 “Calls” 18.18.2.4 180 - Ringing Rings 200 - OK Answers BYE Hangs up RTP Talking Talking User A User B

(87)

_{SIP INVITE}

INVITE sip:e9-airport.mit.edu SIP/2.0

From: "Dennis Baron"<sip:6172531000@mit.edu>;tag=1c41 To: sip:e9-airport.mit.edu

Call-Id: call-1096504121-2@18.10.0.79 Cseq: 1 INVITE

Contact: "Dennis Baron"<sip:6172531000@18.10.0.79> 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

(88)

/2

_{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)

(89)

_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

(90)

_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

(91)

/2

_{SIP Flows - Registration}

200 - OK REGISTER: sip:dbaron@MIT.EDU 401 - Unauthorized User B _MIT.EDU_MIT.EDU Registrar

REGISTER: (add credentials)

MIT.EDU

Location

sip:dbaron@MIT.EDU Contact 18.18.2.4

(92)

_{SIP REGISTER}

REGISTER sip:mit.edu SIP/2.0

From: "Dennis Baron"<sip:6172531000@mit.edu>;tag=4561c4561 To: "Dennis Baron"<sip:6172531000@mit.edu>;tag=324591026 Call-Id: 9ce902bd23b070ae0108b225b94ac7fa

Cseq: 5 REGISTER

Contact: "Dennis Baron"<sip:6172531000@18.10.0.79;LINEID=05523f7a97b54dfa3f0c0e3746d73a24> 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

(93)

/2

_{SIP REGISTER – 401 Response}

SIP/2.0 401 Unauthorized

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

(94)

/2

_{SIP REGISTER with Credentials}

REGISTER sip:mit.edu SIP/2.0

Contact: "Dennis Baron"<sip:61725231000@18.10.0.79;LINEID=05523f7a97b54dfa3f0c0e3746d73a24> 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

(95)

/2

_{SIP Flows – Via Proxy}

INVITE: sip:dbaron@MIT.EDU “Calls” dbaron @MIT.EDU INVITE: sip:dbaron@18.18.2.4 100 - Trying 180 - Ringing Rings 180 - Ringing 200 - OK Answers 200 - OK ACK BYE Hangs up 200 - OK User A User B MIT.EDU MIT.EDU Proxy Talking RTP Talking

(96)

/2

_{SIP Flows – Via Gateway}

INVITE: sip:joe@MIT.EDU “Calls” joe @MIT.EDU INVITE: sip:38400@18.162.0.25 100 - Trying ACK ACK User A _MIT.EDU_MIT.EDU Proxy 30161 Gateway 180 - Ringing 180 - Ringing Rings 200 - OK 200 - OK Answers BYE Hangs up BYE 200 - OK Talking RTP Talking

(97)

/2

_{SIP INVITE with Record-Route}

INVITE sip:37669@18.162.0.25 SIP/2.0

Record-Route: <sip:18.7.21.118:5080;lr;a;t=2c41;s=b07e28aa8f94660e8545313a44b9ed50> From: \"Dennis Baron\"<sip:6172531000@mit.edu>;tag=2c41

To: sip:37669@mit.edu

Call-Id: call-1096505069-3@18.10.0.79 Cseq: 1 INVITE

Contact: \"Dennis Baron\"<sip:6172531000@18.10.0.79> 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

(98)

_{SIP Standards}

Just a sampling of IETF standards work… IETF RFCs http://ietf.org/rfc.html

_RFC3261 _{Core SIP specification – obsoletes RFC2543} _RFC2327 _{SDP – Session Description Protocol}

_RFC1889 _{RTP - Real-time Transport Protocol} _RFC2326 _{RTSP - Real-Time Streaming Protocol}

_RFC3262 _{SIP PRACK method – reliability for 1XX messages} _RFC3263 _{Locating SIP servers – SRV and NAPTR}

(99)

/2

_{SIP Standards (cont.)}

_RFC3265 _{SIP event notification – SUBSCRIBE and NOTIFY} _RFC3266 _{IPv6 support in SDP}

_RFC3311 _{SIP UPDATE method – eg. changing media} _RFC3325 _{Asserted identity in trusted networks}

_RFC3361 _{Locating outbound SIP proxy with DHCP} _RFC3428 _{SIP extensions for Instant Messaging} _RFC3515 _{SIP REFER method – eg. call transfer}

_SIMPLE _{IM/Presence -} _{http://ietf.org/ids.by.wg/simple.html} _{SIP authenticated identity management}

http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-02.txt

(100)

Tema 3:

Protocolos de transporte multimedia.

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

(101)

_{Elements of an H.323 System}

_Terminals

_{Multipoint Control Units (MCUs)}

_Gateways

_Gatekeeper

_{Border Elements}

Referred to as “endpoints”

(102)

_Terminals

_Telephones _{Video phones} _{IVR devices} _{Voicemail Systems}

(103)

_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

(104)

_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,}

(105)

_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

(106)

/2

_{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}

(107)

/2

_{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

(108)

/2

_{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}