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 Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com)

Productividad (Throughput)
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 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 Mensaje listo para recepción

Varianza del retardo (Jitter)
Requisitos de red (II). 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. 1 2 3 D1 D2 = D1 D3 > D1 t Emisor Receptor

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

Slide thanks to Henning Schulzrinne
Internet Protocols Slide thanks to Henning Schulzrinne

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 Computer Networking: A Top Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. Thanks to : RADCOM technologies H. Shulzrinne Paul. E. Jones (from packetizer.com)

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

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

Scheduling Policies: still more
round robin scheduling: multiple classes cyclically scan class queues, serving one from each class (if available)

Scheduling Policies: still more
Weighted Fair Queuing: generalized Round Robin each class gets weighted amount of service in each cycle

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)

Token Bucket: limit input to specified Burst Size and Average Rate.
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).

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

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?

Intserv: QoS guarantee scenario
Resource reservation call setup, signaling (RSVP) traffic, QoS declaration per-element admission control request/ reply QoS-sensitive scheduling (e.g., WFQ)

Arriving session must :
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

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

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

Diffserv Architecture
Edge router: per-flow traffic management marks packets as in-profile and out-profile r b marking scheduling . Core router: per class traffic management buffering and scheduling based on marking at edge preference given to in-profile packets Assured Forwarding

Edge-router Packet Marking
profile: pre-negotiated rate A, bucket size B packet marking at edge based on per-flow profile Rate A B User packets Possible usage of marking: class-based marking: packets of different classes marked differently intra-class marking: conforming portion of flow marked differently than non-conforming one

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

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

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

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

Signaling in the Internet
no network signaling protocols in initial IP design connectionless (stateless) forwarding by IP routers best effort service + = 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]

RSVP Design Goals accommodate heterogeneous receivers (different bandwidth along paths) accommodate different applications with different resource requirements make multicast a first class service, with adaptation to multicast group membership leverage existing multicast/unicast routing, with adaptation to changes in underlying unicast, multicast routes control protocol overhead to grow (at worst) linear in # receivers modular design for heterogeneous underlying technologies

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

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

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

RSVP request (T-Spec) A token bucket specification peak rate, p
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

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.

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

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.

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

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

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 H3 H2 R1 R2 R3 H4 H1 H5

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 in out L1 L2 L6 in out L3 L7 L4 m1: m1: in out L5 L7 L6 m1: H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5

next, H5 sends path message, creating more state in routers in out L1 L2 L6 L6 in out L3 L7 L4 m1: m1: L1 in out L5 L5 L7 L6 m1: L6 H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5

H2, H3, H5 send path msgs, completing path state tables in out L1 L2 L6 L2 L6 in out L3 L7 L4 L3 L4 m1: m1: L1 L7 in out L5 L5 L7 L6 L7 m1: L6 H2 H3 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5

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

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 L3 L2 R1 L6 L7 R2 R3 L4 H4 L1 L5 H1 H5

RSVP: receiver reservation example 1
H1 reservation msgs flows uptree to sources routers, hosts reserve bandwidth b needed on downstream links towards H1 L6 in out L3 L4 L7 in out L1 L2 m1: m1: L1 (b) L2 L6 L3 L4 L7 (b) in out L5 L6 L7 m1: L5 L6 (b) L7 H2 H3 b b L3 L2 b b b b R1 L6 L7 R2 R3 L4 b H4 L1 L5 H1 H5

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 L6 in out L3 L4 L7 in out L1 L2 m1: m1: L1 (b) L2 (b) L6 L3 L4 L7 (b) in out L5 L6 L7 m1: L5 L6 (b) L7 H2 H3 b b b L3 L2 b b b b R1 L6 L7 R2 R3 L4 b b H4 L1 L5 H1 H5

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 L6 in out L3 L4 L7 in out L1 L2 m1: m1: L1 (b) L2 (b) L6 L3 L4 L7 (b) in out L5 L6 L7 m1: L5 L6 (b) L7 H2 H3 b b b L3 L2 b b b b R1 L6 L7 R2 R3 L4 b b H4 L1 L5 H1 H5

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 H2 H3 H3 L3 L3 L2 L2 R1 L6 L7 R2 R3 L4 H4 L1 H1

RSVP: example 2 H1, H4 are only senders
send path messages as before, indicating filtered reservation in out L1, L6 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via-R2 ) L7(H4-via-H4 ) in out L4, L7 L2(H1-via-H1 ; H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) H2 H2 H3 H3 R2 L3 L3 L2 L2 R1 L6 L7 R3 L4 H4 L1 H1 in out L6, L7 L6(H4-via-R3 ) L7(H1-via-R1 )

RSVP: example 2 receiver H2 sends reservation message for source H4 at bandwidth b propagated upstream towards H4, reserving b in out L1, L6 L3(H4-via-H4 ; H1-via-R2 ) L4(H1-via ) L7(H4-via-H4 ) in out L4, L7 L2(H1-via-H1 ;H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) (b) (b) H2 H2 H3 H3 b R2 L3 L3 L2 L2 b b b R1 L6 L7 R3 L4 H4 L1 L1 H1 in out L6, L7 L6(H4-via-R3 ) L7(H1-via-R1 ) (b)

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

RSVP: soft-state gone fishing!
suppose H4 (sender) leaves without performing teardown eventually state in routers will timeout and disappear! in out L1, L6 L3(H4-via-H4 ; H1-via-R3 ) L4(H1-via ) L7(H4-via-H4 ) in out L4, L7 L2(H1-via-H1 ;H4-via-R2 ) L6(H1-via-H1 ) L1(H4-via-R2 ) (b) (b) H2 H2 H3 H3 b R2 L3 L3 L2 L2 b b b R1 L6 L7 gone fishing! R3 L4 H4 L1 L1 H1 in out L6, L7 L6(H4-via-R3 ) L7(H1-via-R1 ) (b)

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

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.

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)

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

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

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

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 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 PT encoding audio/video clock rate channels name (A/V) (Hz) (audio) ______________________________________________ PCMU A A G A GSM A ... 34-71 unassigned ? 72-76 reserved N/A N/A N/A 77-95 unassigned ? dynamic ? PCMU Corresponde a la recomendación CCITT/ITU-T G.711. El audio se codifica con 8 bits por muestra, después de una cuantificación logarítmica. PCMU es la codificación que se utiliza en Internet para un media de tipo audio/basic.

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.

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

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

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 Retraso del último SR (LSR) Ultimo SR (LSR) Report block 1 Sender info cabecera

RTCP: Cálculo del Jitter
Es una estimación de la variancia del tiempo de inter-llegada de los paquetes RTP Si  RTP timestamp del paquete i Ri  Instante de llegada del paquete i

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

Terminología RTSP Conferencia Media stream Presentación:
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

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

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)

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

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

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

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

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

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

Where’s SIP Application Transport Network Physical/Data Link SDP
codecs RTSP SIP RTP DNS(SRV) TCP UDP IP Ethernet

IP SIP Phones and Adaptors
2 1 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) Analog phone adaptor 3 Palm control 4 5 4

SIP Components User Agents Server types Gateways
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

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

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

SIP Peer to Peer! Originating User Agent Terminating User Agent SIP
RTP

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 REGISTER Sends user’s address to server

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 6XX Global Failure 603 Decline

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

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

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)

SDP v=0 o=Pingtel 5 5 IN IP4 18.10.0.79 s=phone-call
c=IN IP t=0 0 m=audio 8766 RTP/AVP a=rtpmap:96 eg711u/8000/1 a=rtpmap:97 eg711a/8000/1 a=rtpmap:0 pcmu/8000/1 a=rtpmap:8 pcma/8000/1 a=rtpmap:18 g729/8000/1 a=fmtp:18 annexb=no a=rtpmap:98 telephone-event/8000/1

CODECs GIPS Enhanced G.711 G.711 G.729 8kHz sampling rate
Voice Activity Detection Variable bit rate G.711 64kbps G.729 8kbps

SIP Flows - Registration
MIT.EDU Registrar MIT.EDU Location User B REGISTER: 401 - Unauthorized REGISTER: (add credentials) Contact 200 - OK

SIP REGISTER REGISTER sip:mit.edu SIP/2.0
From: "Dennis To: "Dennis Call-Id: 9ce902bd23b070ae0108b225b94ac7fa Cseq: 5 REGISTER Contact: "Dennis Expires: 3600 Date: Thu, 30 Sep :46:53 GMT Accept-Language: en Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Content-Length: 0 Via: SIP/2.0/UDP

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

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

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

SIP Flows – Via Gateway RTP MIT.EDU Proxy User A Gateway 30161
INVITE: “Calls” INVITE: 100 - Trying 180 - Ringing Rings 200 - OK Answers ACK Talking RTP BYE Hangs up 200 - OK

SIP INVITE with Record-Route
INVITE SIP/2.0 Record-Route: <sip: :5080;lr;a;t=2c41;s=b07e28aa8f94660e a44b9ed50> From: \"Dennis To: Call-Id: Cseq: 1 INVITE Contact: \"Dennis Content-Type: application/sdp Content-Length: 304 Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Date: Thu, 30 Sep :44:30 GMT Via: SIP/2.0/UDP :5080;branch=z9hG4bK2cf12c563cec06fd1849ff799d069cc0 Via: SIP/2.0/UDP ;branch=z9hG4bKd26e44dfdc d9d32a143a7f4d8 Via: SIP/2.0/UDP Max-Forwards: 17

SIP Standards Just a sampling of IETF standards work…
IETF RFCs 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 RFC3264 Offer/answer model for SDP use with SIP

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 - SIP authenticated identity management -

Referred to as “endpoints”
Elements of an H.323 System Terminals Multipoint Control Units (MCUs) Gateways Gatekeeper Border Elements Referred to as “endpoints”

Terminals Telephones Video phones IVR devices Voicemail Systems
“Soft phones” (e.g., NetMeeting®)

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

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)

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

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

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

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

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

Registration, Admission, and Status – RAS (cont)
RRQ T GK RCF (endpoint is registered) ARQ ACF (endpoint may place call) DRQ T Terminal GK Gatekeeper GW Gateway Symbol Key: (call has terminated) DCF

The H323 stack

You can find a bigger list at:
H323 Clients O.S. Client Price Windows NetMeeting +/- free Unix (Linux) DC-Share nv Sun Sunforum … ... You can find a bigger list at:

IMPLEMENTACIÓN DE TELEFONÍA IP EN UNA ORGANIZACIÓN
INTEGRACIÓN CISCO-ASTERISK

CARACTERISTICAS CISCO CALL MANAGER
Solución de Telefonía IP de Cisco Distribuible Escalable (30000 lineas/servidor) Soporta muchos usuarios Sobre Windows o linux Soporta gran variedad de teléfonos

PROTOCOLOS Sip H323 MGCP (Megaco Protocol)

OBJETIVO FINAL

FUNCIONAMIENTO DE CALL MANAGER

CONFIGURACIÓN CM Interfaz Web

PARTITIONS Dividen el conjunto de route patterns en subconjuntos de destinos alcanzables identificados por un nombre. Una partición contiene una lista de Route Patterns Facilitan el enrutado de llamadas dividiendo el route plan en subconjuntos lógicos que se pueden basar en la organización, localización y tipo de llamada

Partitions

SEARCH SPACES Es una lista ordenada de rutas de partición. Estas rutas se asocian a los dispositivos (teléfonos). Determinan las particiones que los dispositivos que hacen una llamada buscan para que esta llamada se realice

ROUTE PATTERNS String de digitos y un conjunto de acciones
La llamada al destino se hace solo si se marca la secuencia correcta definida en el route pattern Se pueden usan caracteres especiales (x…) para hacer rangos, etc Definir route patterns para diferentes tipos de llamadas: nacionales, sin salida….

ESQUEMA DE NUMERACIÓN 67xxx: Teléfonos IP HW (Vera) 68xxx: SoftPhones
69xxx: Teléfonos SIP 7xxxx: Teléfonos analógicos (fuera del Call Manager) 11xxx: Teléfonos móviles

Route patterns

GATEWAYS Debe haber uno por cada campus
Otro que será el router de salida general. Coste: euros

Gateways

TRUNK CON ASTERISK Es un enlace desde el Call Manager al Asterisk: se enrutan llamadas de uno al otro Se define mediante la IP del Asterisk

TELEFONOS un identificador, el Device Name (3 caracteres más la dirección MAC ) una descripción (ej . la persona asociada) el pool al que corresponde su estado (registrado o no) la dirección IP del teléfono: sólo se muestra si el teléfono está registrado

Teléfonos

Teléfonos II

Teléfonos III Configuración desde el CM http://x.y.z.w:9999/
Teléfono Cisco Teléfono SIP 300 Euros Euros Configuración desde el CM SIP_ADDITIONAL.CONF

Teléfonos IV [69001] <--------- Extensión
username= < Podría ser el login type=friend record_out=Adhoc record_in=Adhoc qualify=no port=5060 nat=never < Su buzón de voz asociado (en el voic .conf) host=dynamic dtmfmode=info context=from-internal canreinvite=no callerid=device <69001> language=es

Teléfonos V Softphone Cisco IP Communicator

ASTERISK funcionalidades similares a Call Manager
Soporta SIP, H.323, MGCP, IAX Se obtiene de : ftp:/ftp.digium.com Integra casi todos los codecs de audio Soporte de Telefonía Tradicional Soporte de Telefonía por Voz IP APIs para desarrollo de nuevos servicios y aplicaciones Integración con Bases de Datos Integración con Aplicaciones ya desarrolladas Código Abierto: sw libre

CONFIGURACIÓN I

CONFIGURACIÓN II Editar directamente ficheros *.conf indications.conf
extensions.conf agents.conf queues.conf sip.conf voic .conf asterisk.conf ……….

Tema 3: Protocolos de transporte multimedia.

Presentaciones similares

Presentación del tema: "Tema 3: Protocolos de transporte multimedia."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Tema 3: Protocolos de transporte multimedia.

Presentaciones similares

Presentación del tema: "Tema 3: Protocolos de transporte multimedia."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback