redes de voz - instituto de ingeniería eléctricaiie.fing.edu.uy/ense/asign/ccu/material/docs/voz...

© Dr. Ing. José Joskowicz 2013

Voz y Video en

Redes IP

Dr. Ing. José Joskowicz

[email protected]


Multimedia sobre

Redes de Datos

Voz y Video en

Redes IP

3© Dr. Ing. José Joskowicz 2013

Paquetización de los flujos

multimedia

Para poder transmitir la información codificada de voz o video sobre redes de datos, es necesario armar “paquetes”.

Es necesario “juntar” un conjunto apropiado de información para armar un paquete.

Cada paquete tiene una cantidad mínima de información de control Cabezal del paquete

Origen, destino

Etc.


Flujo multimedia

RTP

UDP

IP

Ethernet

Sobrecarga

Ventana

Transmisión de multimedia sobre

redes de datos

Sobrecarga


RTP – Real Time Protocol

Es un protocolo para transmisión de datos de

tiempo real (audio y video) sobre IP

Está estandarizado en el RFC 3550

Se basa en UDP


RTP - Cabezal

V PX CC M PT Sequence number

Timestamp

synchronization source (SSRC) identifier

contributing source (CSRC) identifiers

…….

32 bits

Version Padding eXtension CSRC count Payload Type


RTP - Cabezal

Payload Type Formato Medio Clock Rate

0 PCM mu-law Audio 8 kHz

3 GSM Audio 8 kHz

4 G.723 Audio 8 kHz

8 PCM A-law Audio 8 kHz

9 G.722 Audio 8 kHz

13 Confort Noise Audio

14 MPEG Audio Audio 90 kHz

15 G.728 Audio 8 kHz

18 G.729 Audio 8 kHz

26 Motion JPEG Video 90 kHz

31 H.261 Video 90 kHz

32 MPEG-1 o 2 Elementary Stream Video 90 kHz

33 MPEG-1 o 2 Transport Stream Video 90 kHz

34 H.263 Video 90 kHz

96 – 127 Dinámico

Payload Type


RTP - Cabezal

Payload type

Identifica el tipo de información que viaja en el

paquete

Indica el tipo de codificación de audio o video, o el

contenido de información “especial”

CN (Comfort Noise)

Tipos dinámicos

RFC 2833 (Tonos DTMF, tonos de Fax, etc.)

…

…


Sequence number ( 16 bits) Número secuencial, generado en el origen. Es usado

por el receptor para detectar paquetes perdidos

Time Stamp (32 bits) Marca horaria, del momento de la generación del

primer byte de la muestra enviada en el paquete

Synchronization Source Identifier (32 bits) Identifica el origen

RTP - Cabezal


Ejemplo RTP: Paquete de audio


RTCP –RTP Control Protocol

El RFC 3550 establece, además del protocolo

RTP, un protocolo de control, RTCP

Encargado de enviar periódicamente paquetes de

control entre los participantes de una sesión

Proveer realimentación acerca de la calidad de los

datos distribuidos (por ejemplo, de la calidad

percibida de VoIP).


RTCP – tipos de datos

SR (Sender Report): Envía estadísticas de los participantes “origen” (sender)

RR (Receiver Report): Envía estadísticas de los participantes “destino” (receivers)

SDES (Source Description): Envía ítems de descripción del origen

BYE: Indica el fin de la participación en el intercambio de mensajes RTCP

APP: Funciones específicas para las aplicaciones participantes


RTCP – Ejemplo de SR y SDES


Voz sobre

Redes de Datos

Voz y Video en

Redes IP


CODECs de banda angosta

Codec NombreBit rate

(kb/s)

Retard

o (ms)Comentarios

G.711PCM: Pulse Code

Modulation64, 56 0.125

Codec “base”, utiliza dos posibles

leyes de compresión: µ-law y A-law

G.723.1Hybrid MPC-MLQ

and ACELP6.3, 5.3 37.5

Desarrollado originalmente para video

conferencias en la PSTN, es

actualmente utilizado en sistemas de

VoIP

G.728

LD-CELP: Low-

Delay code

excited linear

prediction

40, 16,

12.8, 9.61.25

Creado para aplicaciones DCME

(Digital Circuit Multiplex Encoding)

G.729

CS-ACELP:

Conjugate

Structure

Algebraic

Codebook

Excited Linear

Prediction

11.8, 8,

6.415

Ampliamente utilizado en aplicaciones

de VoIP, a 8 kb/s


CODECs de banda ancha


(kb/s)

Retardo

(ms)Comentarios

G.722 Sub-band ADPCM 48,56,64 3

Inicialmente diseñado para audio y

videconferencias, actualmente utilizado

para de telefonía de calidad en VoIP

G.722.1 Transform Coder 24,32 40 Usado en audio y videoconferencias

G.722.2 AMR-WB6.6 a

23.8525.9375

Estandar en común con 3GPP (3GPP

TS 26.171). gran inmunidad a los

ruidos de fondo en ambientes adversos

(por ejemplo celulares)

G.711.1 Wideband G.71164, 80,

9611.875

Amplía el ancho de banda del codec

G.711, optimizando su uso para VoIP

G.729.1 Wideband G.7298 a 32

kb/s<49 ms

Amplía el ancho de banda del codec

G.729, y es “compatible hacia atrás”

con este codec. Optimizado su uso

para VoIP con audio de alta calidad

RtAudio Real Time Audio 8.8, 18 40

Codec propietario de Microsoft,

utilizado en aplicaciones de

comunicaciones unificadas (OCS)


CODECs de banda superancha


(kb/s)

Retardo

(ms)Comentarios

SILK SILK 8 a 24 25 Utilizado por Skype


CODECs de banda completa


(kb/s)

Retardo

(ms)Comentarios

G.719Low-complexity,

full-band32 a 128 40

Es el primer codec “fullband”

estandarizado por ITU


RTP – Paquete de audio


RTP – Ejemplo RFC 2833


RTP – Ejemplo Comfort Noise


Ancho de banda para G.711

Ventana = 20 ms

Bytes de voz/trama = 64 kb/s * 20 ms / 8 = 160 bytes

Bytes de paquete IP = 160 + 40 = 200 bytes

Bytes de Trama Ethernet = 200 + 26 = 226 bytes

Ancho de banda LAN = 226 * 8 / 20 ms = 90.4 kb/s

Este ancho de banda es para la voz en UN sentido. Se debe

duplicar para tener en cuenta ambos sentidos

Ethernet

22 bytes

IP (UDP + RTP)

40 bytes

20 ms de voz

160 bytes

Et

4 bytes


Ancho de banda

Bytes de voz/trama = Velocidad de muestreo *

duración de trama /8

Bytes de paquete IP = Bytes de voz/trama + 40

Bytes de Trama Ethernet = Bytes de paquete IP

+ 26

Ancho de banda LAN = Bytes de Trama

Ethernet * 8 / duración de trama


Tipo de

Codec

Duración

de Trama

(ms)

Bytes de

voz/Trama

Bytes de

paquete IP

Bytes de

trama

Ethernet

Ancho de

Banda en

LAN (kbps)

G.711 10 80 120 146 116,8

(64 kbps) 20 160 200 226 90,4

30 240 280 306 81,6

G.729 10 10 50 76 60,8

(8 kbps) 20 20 60 86 34,4

30 30 70 96 25,6

G.723.1

(6.3 kbps) 30 24 64 90 23,9

G.723.1

5.3 kbps 30 20 60 86 22,9

Ancho de banda de LAN en un

sentido


Video sobre

Redes de Datos

Voz y Video en

Redes IP


Comparación de codecs de videoCaracterística MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4

Part 10/AVC

Tamaño del macro-bloque 16x16 16x16, 16x8 16x16 16x16

Tamaño del bloque 8x8 8x 8 16x16

8x8, 16x8

8x8, 16x8, 8x16,

16x16, 4x8, 8x4,

4x4

Transformada DCT DCT DCT/DWT 4x4 Integer transfor

Tamaño de la muestra para

aplicar la transformada

8x8 8x8 8x8 4x4

Codificación VLC VLC VLC VLC, CAVLC,

CABAC

Estimación y

compensación de

movimiento

Si Si Si Si, con hasta 16 MV

Perfiles No 5 8 3

Tipo de cuadros I,P,B,D I,P,B I,P,B I,P,B,SI,SP

Ancho de banda < 1.5 Mbps 2 a 15 Mbps 64 kbps a 2 Mbps 64 kbps a 150 Mbps

Complejidad del codificador Baja Media Media Alta

Compatibilidad con

estándares previos

Si Si Si No


Formatos de video

Formato Resolución (pixels)

SQCIF 128 × 96

QCIF 176 × 144

CIF 352 × 288

4CIF 704 × 576

16CIF 1408 × 1152

VGA 640 × 480

SD 720 × 576


Transmisión de video sobre

redes de datos

Las secuencias de video (Elementary Streams)

son paquetizadas en unidades llamadas PES

(Packetized Elementary Streams), consistentes

en un cabezal y hasta 8 kbytes de datos de

secuencia.

Estos PES a su vez, son paquetizados en

pequeños paquetes, de 184 bytes, los que, junto

a un cabezal de 4 bytes (totalizando 188 bytes)

conforman el “MPEG Transport Stream” (MTS) y

pueden ser transmitidos por diversos medios.


Transmisión de video sobre

redes de datos

RFC 2250: Establece los procedimientos para transportar video

MPEG-1 y MPEG-2 sobre RTP. Varios paquetes MTS de 188 bytes pueden ser transportados en un único paquete RTP, para mejorar la eficiencia

RFC 3016 y RFC 3640 Establecen los procedimientos para transportar flujos

de audio y video MPEG-4

RFC 3984 Establece los procedimientos para transportar flujos

de video codificados en H.264


MPEG-2 sobre RTP

7 paquetes MTS (MPEG-2 Transport Stream)

dentro de un mismo paquete RTP

Payload Type: MTS

(MPEG-2 Transport

Stream)


MPEG-2 sobre RTP

Cabezal de MTS

(4 bytes)

Payload de MTS

(184 bytes)


H.264 sobre RTP

Payload del tipo

“dinámico”

Payload de H.264

(1430 bytes)


Ancho de Banda de Video

El ancho de banda requerido depende de

Tipo de codificación utilizada (MPEG-1, 2, 4, H264,

etc.)

Resolución (tamaño de los cuadros SD, CIF, QCIF,

etc.)

Tipo de cuantización seleccionado

Movimiento

Textura

La codificación de video es estadística, y

depende de la imagen transmitida


Calidad vs Ancho de Banda

MOS (SD - MPEG-2)

1

1.5

2

2.5

3

3.5

4

4.5

5

0 1 2 3 4 5 6 7 8 9 10 11 12

Bitrate (Mb/s)

MO

S

Serie1

Serie2

Serie3

Serie4

Serie5

Serie6

Serie7

Serie8

Serie9

Serie10

Serie11

Serie12

Serie13

Serie14

Serie15

Serie16


Ancho de banda en LAN para

MPEG-2 con MTS

7 x184 = 1288 bytes de contenido MPEG-2

40 + 4 x 7 = 68 bytes de cabezales a nivel de capa 3 (IP)

26 bytes de cabezales adicionales a nivel de capa 2

184 bytes40 bytes

4 bytes

(MTS Header)

22 bytes

Ethernet IP (UDP+RTP) MTS E



MPEG-2 con MTS

El ancho de banda de MPEG-2 transportado en

RTP

5.3% (68/1288) mayor que el ancho de banda propio

del video en capa 3 (IP)

7.3 % (94/1288) mayor que el ancho de banda propio

del video en capa 2 (Ethernet)



H.264

H.264 encapsulado directamente sobre RTP

(sin utilizar TS)

Se pueden enviar hasta 1430 bytes de “payload” en

un paquete IP/UDP/RTP

El ancho de banda en capa 3 es 2.8% (40/1430)

mayor que el del propio video codificado

En capa 2 es 4.6% (66/1430) mayor que el del propio

video codificado.


Calidad de

Voz y Video

Voz y Video en

Redes IP


Evolución de la calidad percibida

de la voz


Calidad de la voz

La calidad de la voz sobre redes de paquetes se

ve afectada por varios factores

Compresión utilizada

Pérdida de paquetes

Demora

Eco

Jitter



A diferencia de las redes telefónicas, donde para cada conversación se establece sobre un vínculo “estable y seguro”, las redes de datos admiten la pérdida de paquetes.

En aplicaciones de voz y video el audio y video es “encapsulado” en paquetes y enviado, sin confirmación de recepción de cada paquete.

Puede haber un porcentaje de paquetes que no llegan al destino

Se escucha como interrupciones en la voz, o cortes de video


ITU-T G.711 Anexo I – PLC

PLC = Packet Loss Concealment

Técnica que mitiga la pérdida de paquetes, tratando de “reconstruir” los paquetes perdidos


Demora (Delay)

Se deben a:

Codificación

G.711 (64 kb/s) 0,13 – 0,75 ,ms

G.728 (16 kb/s) 2.5 ms

G.729 (8 kb/s) 10 – 15 ms

G.723.1 (5.3 o 6.4 kb/s) 37.5 ms

RTAudio < 40 ms

Red (latencia)

Cantidad de muestras/bytes por paquete

Velocidad de transmisión

Congestión

Demoras de los equipos de red (colas en routers, gateways, etc.)


Demora (Delay)


Jitter

Es la variación en las demoras (latencias). Por ejemplo, si dos puntos comunicados reciben un paquete

cada 20 ms en promedio, pero en determinado momento, un

paquete llega a los 30 ms y luego otro a los 10 ms, el

sistema tiene un “jitter” de 10 ms.

El jitter afecta la percepción de la voz, y puede

evitarse mediante buffers Los buffers agregan una demora adicional al sistema, ya que

deben “retener” paquetes para poder entregarlos a intervalos

constantes. Cuánto más variación de demoras (jitter) exista,

más grandes deberán ser los buffers, y por lo tanto, mayor

demora total tendrá el sistema.


Demora y Jitter


Ejemplo: Softphone


Eco

Tiempo transcurrido desde que se habla hasta

que se percibe el retorno de la propia voz

Si la demora de retorno es menor a 30 ms, o el

nivel del retorno está por debajo de los –25 dB,

el efecto del eco no es percibido.

Dado que las demoras de voz sobre redes de

datos son altas, puede existir eco


Eco


Cancelación de Eco

ITU-T G.168: Digital Network Echo Cancellers


Medida de la calidad de voz en

redes IP

Para que la tecnología de VoIP pueda ser utilizada

corporativamente, es esencial garantizar una calidad de

voz aceptable.

Para ello se han desarrollado métodos para medirla.

Subjetivos

Se basan en conocer directamente la opinión de los usuarios

Objetivos

Miden propiedades físicas de una red para prever o estimar la

performance percibida por los usuarios

Intrusivos

No Intrusivos


Métodos Subjetivos

La calidad de la voz se establece a través de la opinión del usuario

ACR: Absolute Category Rating Se califica el audio con valores entre 1 y 5, siendo 5 “Excelente”

y 1 “Malo”

MOS (Mean Opinión Score) es el promedio de los ACR medidos entre un gran número de usuarios

DCR: Degradation Category Rating Se califica entre 1 y 5, siendo 5 cuando no hay diferencias

apreciables entre el audio de referencia y el medido y 1 cuando la degradación es muy molesta

DMOS (Degradation MOS) el promedio de los valores DCR medidos entre un gran número de usuarios


Métodos Objetivos: ITU-T G.107

E-Model

La ITU ha definido un modelo, llamado “E-

Model” (ITU-T G.107), para estimar la calidad de

la voz sobre redes de paquetes, teniendo en

cuenta factores medibles de la red

El resultado del “E-Model” es un valor escalar

llamado R, que puede ser directamente relacionado

con el MOS (ITU-T P.800)


R versus MOS


Definición de “R”

R = Ro - Is - Id – Ie + A Ro =Fuentes de ruido independientes del sistema

Ruido ambiental, tanto en el origen como en el destino

El máximo teórico es 100

Is = Deterioro simultáneo a la generación de la señal digital Volumen excesivo, distorsión de cuantización

Id = Deterioro casusado por las demoras Demoras, Jitter, Eco

Ie = Deterioro causado por equipos especiales Codec, pérdidas de paquetes

A = Factor de Mejoras de Expectativas


STD Kbps Algoritmo MOS Observaciones Retardo Uso

de 1 a 5 Encoding CPU

Toll Quality 4 a 5 Telefonía analógica - -

G.711 64 PCM 4,4 Telefonía digital 0,75 ms -

G.726/7 40/32/24/16 ADPCM 4,2 Telefonía digital comprimida 1 bajo

G.728 16 LD-CELP 3,6 Low Delay-Code Excited Linear Prediction bajo muy alto

G.729 8 CS-ACELP 4,2 VoIP/FR/ATM Netmeeting 15 ms alto

G.729A 8 CS-ACELP 3,7 VoIP/FR/ATM Netmeeting 15 ms alto

G.723.1 5,3 ACELP 3,5 VoIP/FR/ATM Netmeeting 37,5 ms moderado

G.723.1 6,4 MP-MLQ 3,98 VoIP/FR/ATM Netmeeting 37,5 ms moderado

MOS según el Codec


Efectos del Codec y la Demora


Efecto del Eco y la demora

50

60

70

80

90

100

0 100 200 300 400 500

One-way Delay (ms)

R

TELR = 65 dB

TELR = 60 dB

TELR = 55 dB

TELR = 50 dB

TELR = 45 dB

Exceptional

limiting case

Very

satisfactory

Satisfactory

Some users

dissatisfied

Many users

dissatisfied

User Satisfaction

TELR = Talker Echo Loudness Rating. Cuanto más atenuado el eco percibido (mayor valor en db de TELR), menor efecto tiene el

eco sobre la degradación


Efectos de la Demora y la



Estimación de A

Ejemplo de sistema de comunicación Valor máximo de

A

Convencional (alámbrico) 0

Movilidad mediante redes celulares en un

edificio

5

Movilidad en una zona geográfica o en un

vehículo en movimiento

10

Conexión con lugares de difícil acceso, por

ejemplo, mediante conexiones de múltiples

saltos por satélite

20


Factor R en paquetes RTCP


Calidad de Video

Varios tipos de degradaciones suelen

presentarse en las señales de video

transmitidas sobre redes de paquetes

A su vez, varios tipos de degradaciones

obedecen al método de codificación utilizado

El estudio en esta área es todavía un tema de

investigación.


Degradaciones en video digital

Efecto de bloques (blocking)

Efecto de imagen de base (basis image)

Borrosidad o falta de definición (Blurring)

Color bleeding (Corrimiento del color)

Efecto escalera y Ringing

Patrones de mosaicos (Mosaic Patterns)

Contornos y bordes falsos

Errores de Compensaciones de Movimiento (MC mismatch)

Efecto mosquito

Fluctuaciones en áreas estacionarias

Errores de crominancia


ITU-T G.1070: Opinion Model for

video-telephony applications

Aprobada por ITU-T en abril 2007, sobre la base de

propuestas de NTT

Propone un algoritmo de estimación de la calidad de

video teléfonos en ambientes de redes de datos

Para ser utilizada como herramienta de diseño o

planificación

Estima tres parámetros de calidad

Sq Speech Quality

Vq Video Quality

MMq Multimedia Quality


ITU-T G.1070 Framework


ITU-T G.1070: Coeficientes para

cada Codec


ITU-T G.1070: Sq

Básicamente se reduce al E-Model, simplificado

Q = Ro - Id – Ie,eff

Sq = f(Q), similar al E-Model

Los efectos de la demora se incluyen en el

MMq, y por lo tanto, se excluyen del Sq


ITU-T G.1070: Vq

Se propone

Ic = f (codec, bitrate, frame rate)

DPplV = f (codec, bitrate, frame rate)

Pplv

plv

D

P

cq eIV

1


ITU-T G.1070: MMq

Se propone

Calidad AudioVisual

MMSV = f (Vq, Sq)

Efectos de las demoras

MMT = f (Speech Delay, Video Delay)

4321 mMMMMmMMmMMmMM TSVTSVq


Calidad de Servicio

en Redes de Datos

Voz y Video en

Redes IP


Impacto de las aplicaciones

Multimedia en las Redes IP

La calidad percibida por los usuarios (Calidad de la

Experiencia - QoE) se ve afectada por diversos factores

Ancho de banda


Demoras

Jitter (Variación de la demora)

Es necesario adecuar las redes de datos para soportar

este tipo de aplicaciones, implementado estrategias de

manejo de “calidad de servicio” (QoS Quality of Service)


Calidad de Servicio (QoS)

Técnicas utilizadas

Priorización

A nivel de capa 2, capa 3, capa 4, etc.

Fragmentación

Necesaria en enlaces de baja velocidad

Control de los retardos máximos

Fundamental para la calidad conversacional


LAN

Problemas en enlaces de baja

velocidad

WANRouter Router

1 Mb/s100 Mb/s

La diferencia de

velocidades hace

necesario formar

Colas


ServersLAN

Problemas en enlaces

compartidos

Switch Switch

Up-link100 Mb/s

La concurrencia

sobre un mismo

“uplink” hace

necesario formar

Colas


LAN

Problemas en enlaces

compartidosWAN o

Up-link

Cola


Priorización

Permite “marcar” tramas, paquete o cierto tipo

de tráfico con diferentes prioridades

En los switchs o routers se pueden formar varias

“colas”, según las prioridades de los paquetes


QoS en Capa 2

Las recomendaciones IEEE 802.1q y IEEE

802.1p incorporan 4 bytes adicionales a las

tramas Ethernet, donde se puede incluir

información acerca de VLANs y etiquetas que

identifican la “prioridad” de la trama.


Tramas 802.1q

Preámbulo S

F

D

Dir

Origen

Dir

Destino

L Datos / Relleno FCS

SFD

7 1 6 6 2 2 2 46 – 1500 4

T

P

I

T

C

I

Preámbulo S

F

D

Dir

Origen

Dir

Destino

L Datos / Relleno FCS

SFD

7 1 6 6 2 46 – 1500 4

Trama normal

Trama 802.1q

Tag Protocol Identifier

81 00Tag Control Information


Campo TCI

Tag Control Information

PR VLAN ID

CFI

TCI

3 1 12

PR = Prioridad

CFI = Canonical Format Indication

VLAN ID = Identificador de VLAN (LAN Virtual)


Prioridad en 802.1p

Permite 8 prioridades: 0-7


Prioridad en 802.1p

Colas

Prioridad = 0

Prioridad = 1

Prioridad = 3

Prioridad = 4

Prioridad = 5

Prioridad = 6

Prioridad = 7

Salida (ordenada por prioridad)


Estrategias de encolamiento y

priorización

FIFO (First In, First Out) El primer paquete que haya ingresado en una cola, es el primero

en salir.

PQ (Priority Queuing) La salida de los paquetes se realiza según el orden estricto de

prioridad, y dentro de cada prioridad, según el orden de llegada. Este tipo de encolamiento puede hacer que, si existe siempre tráfico de alta prioridad, el tráfico de baja prioridad nunca sea enviado.

FQ (Fair Queuing) Es un esquema en el que cada cola se accede en forma circular,

asegurando una distribución uniforme de ancho de banda entre todas las colas.


Estrategias de encolamiento y

priorización

WRR (Weighted Round Robin)

Permite asignar diferentes anchos de banda a cada cola.

WFQ (Weighted Fair Queuing)

Es una combinación de PQ y FQ, garantizando que aplicaciones

de alto tráfico no monopolicen el enlace.


VLAN

Muchos switches de datos permiten

implementar cierta priorización del tráfico

basado en VLANs

De esta forma, se puede poner a todos los

dispositivos de VoIP en la misma VLAN, y darle

prioridad frente al tráfico de otras VLANs,

dedicadas a aplicaciones de datos

Adicionalmente, en este caso el tráfico de voz

no se ve afectado por el de datos


QoS en Capa 3

DiffServ (Differentiated Services) es

comúnmente utilizado para gestionar prioridad

en los paquetes

La información de priorización se encuentra en

el cabezal del paquete IP, en un campo llamado

TOS (Type Of Service)


Cabezal IP con TOS

DSCP = Differentiated Services Code Point

ECN = Explicit Congestion Notification

Versión TOS Largo total

4 4 8 16

Largo

del

cabezal

Resto del

cabezal IP

DSCP ECN

6 2


DSCP

Es posible codificar hasta 26 = 64 posibles

prioridades.

De éstas, 32 están reservadas para usos

experimentales

32 pueden ser utilizadas

21 están estandarizadas por el IETF

Las prioridades estandarizadas se dividen en 3

grupos


DE (DEfault) Se asume el comportamiento por defecto, utilizando por tanto

técnicas de encolamiento de “mejor esfuerzo”. El valor típico de DSCP para este tipo de tráfico es 000000.

AF (Assured Forwarding) Estandarizado en el RFC 2597, donde se definen 4 clases de

prioridades dentro de este tipo de priorización.

EF (Expedited Forwarding) Estandarizado en el RFC 3246, establece las máximas

prioridades para el tráfico marcado con este identificador. El valor típico de DSCP utilizado es 101110 (46 decimal).

DSCP


Ejemplo: “Zoiper”


ECN

Permite conocer el estado de congestión del destino.

Es utilizado para que el destino pueda indicarle a la

fuente, aún antes de perder paquetes, que existe cierto

estado de congestión, de manera que la fuente pueda

tomar los recaudos apropiados, por ejemplo,

disminuyendo el ancho de banda utilizado.

ECN = 11 indica que existe congestión

ECN = 10 o 01 indican que no existe congestión.

ECN = 00 indica que el extremo distante no soporta la función

de notificación de congestión.


Otros mecanismos de

priorización en Capa 3

RSVP (Resource Reservation Protocol)

Establece los mecanismos para reservar cierto ancho

de banda en la comunicación entre dispositivos que

pasen a través de routers.

El tráfico también puede ser priorizado en base

a la dirección IP de origen o destino.

Esto puede ser implementado cuando se utilizan

direcciones IP estáticas.


QoS en Capa 4 y superiores

Los paquetes de datos pueden ser priorizados en base a los puertos TCP o UDP. Sin embargo, diferentes aplicaciones podrían utilizar

los mismos puertos, por lo que este tipo de priorizaciones debe ser evaluada en cada caso.

Es posible también tener prioridades según el protocolo de capas superiores. Por ejemplo, puede ser priorizado el tráfico RTP

respecto a otros, y asignarlo a las colas de alta prioridad.


Fragmentación

Enlace de baja velocidad

Varias

Colas Prioridad = 1

Prioridad = 2

Las colas y prioridades no resuelven el

problema de “paquetes largos sobre enlaces de

baja velocidad”

Es necesario “Fragmentar”

Paquete “largo” de

baja prioridad


Fragmentación

64 kb/s

WAN

ColasPaquete

de más de

1500 bytes

1.500 bytes / 64 kb/s =

187 ms


Fragmentación

Ethernet MTU Paq. de Voz

1500 32

Velocidad Tiempo Tiempo

[Kbps] [ms] [ms]

64 187,50 4,00

128 93,75 2,00

256 46,88 1,00

512 23,44 0,50

1024 11,72 0,25

2048 5,86 0,13

34000 0,35 0,01

155000 0,08 0,00

622000 0,02 0,00

Trama [Bytes]

Requiere fragmentación en las tramas de datos


DTE

2 Mb

DTE64 Kb

64 Kb

Ttrans 187.5 / 12.5 ms 6 / 0,4 ms 187.5 / 12.5 ms

Tcola (2 paq) 375 / 25 ms 12 / 0,8 ms 375 / 25 ms

Codec (G.723) 30 ms

Total paquete 1500 bytes (sin colas): 187.5 + 6 +187.5 =381 ms

Total paquete voz 100 bytes G.723 (sin colas): 30 + 12.5 + 0.4 + 12.5 = 30 + 25.24 = 55.4 ms

Paq: 1500/100 bytes

Retardos punta a punta para la

voz


VoWLAN

Voz y Video sobre

Redes Inalámbricas

Voz, Video y Telefonía sobre IP


VoWLAN

Las tecnologías de voz sobre redes de datos inalámbricas se conocen generalmente como VoWLAN (Voice over Wireless LAN) o VoWi-Fi (Voz sobre Wi-Fi)

Está comenzando a incrementarse la demanda de esta tecnología en el mercado corporativo

Sin embargo, este tipo de tecnologías presentan desafíos adicionales para obtener una calidad aceptables


Recomendaciones IEEE 802.11

Resumen histórico

Recomendación Año Descripción

802.11 1997 Hasta 2 Mb/s en la banda de 2.4 GHz

802.11a 1999 Hasta 54 Mb/s en la banda de 5 GHz

802.11b 1999 Hasta 11 Mb/s en la banda de 2.4 GHz

802.11g 2003 Hasta 54 Mb/s en la banda de 2.4 GHz

802.11n 2009

Hasta 600 Mb/s en las bandas de 2.4 GHz y 5 GHz con

tecnología MIMO

802.11ac 2013

Hasta 1300 Mb/s en la banda de 5 GHz con tecnología

MultiUser-MIMO

http://www.google.com.uy/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http%3A%2F%2Fwww.ibersystems.es%2Fblogredesinalambricas%2F802-11-wifi%2F&ei=3iq9VIdxhbWwBLikgtgO&bvm=bv.83829542,d.cWc&psig=AFQjCNE32uXi9Tfb7Xz8RR63ZkurDCTuPg&ust=1421769779745141

http://www.google.com.uy/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http%3A%2F%2Fwww.ibersystems.es%2Fblogredesinalambricas%2F802-11-wifi%2F&ei=3iq9VIdxhbWwBLikgtgO&bvm=bv.83829542,d.cWc&psig=AFQjCNE32uXi9Tfb7Xz8RR63ZkurDCTuPg&ust=1421769779745141


Arquitectura 802.11

AP AP

Distribution

System

Basic Service

Set (Celda)

Access Point


Modelo de capas 802.11

802.11 PHY

802.11 MAC

802.11 PHY

802.11 MAC

802.3 PHY

802.3 MAC

AP

Ethernet

LANWireless

LLC Relay


Capa Física 802.11

802.11

Especificada para 1 y 2 Mb/s, @ 2.4 GHz. Utiliza las

técnicas FHSS (Frequency Hopping Spread Spectrum) o

DSSS (Direct Sequence Spread Spectrum).

802.11b

Es una extensión de 802.11 y trabaja también a 5.5 y

11 Mb/s. Utiliza CCK (Complementary Code Keying) con

modulación QPSK (Quadrature Phase Shift Keying) y

tecnología DSSS (Direct-Sequence Spread Spectrum).

Soporta cambios de velocidad dinámicos

Se conoció como “Wi-Fi”


Capa Física 802.11

802.11a Es una extensión de 802.11b, y trabaja hasta 54 Mb/s

en la banda de los 5 GHz. Utiliza técnicas demultiplexación ortogonal por división de frecuencia(OFDM), en vez de FHSS o DSSS.

802.11g Es una extensión de 802.11b, y trabaja hasta 54 Mb/s

en la misma banda que 802.11b (2.4 GHz). Utilizatécnicas de multiplexación ortogonal por división defrecuencia (OFDM).


Capa Física 802.11

802.11n Incorpora técnicas de antenas MIMO (Multiple Input –

Multiple Output). Trabaja en las bandas de 2.4 GHz y5 GHz, con técnicas de modulación OFDM, llegandohasta 600 Mb/s

802.11ac Agrega la técnica MU-MIMO (Multi User MIMO),

llegando a velocidades de 1.3 Gb/s en la banda de 5GHz


MIMO y MU-MIMO

http://www.google.com.uy/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http%3A%2F%2Felectronicdesign.com%2Fcommunications%2Funderstanding-ieee-80211ac-vht-wireless&ei=2SO9VITND7T7sASG94GADw&bvm=bv.83829542,d.cWc&psig=AFQjCNGtlYiVypcsiygZ7X_58uoNZujzsw&ust=1421767979269453

http://www.google.com.uy/url?sa=i&rct=j&q=&esrc=s&frm=1&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRw&url=http%3A%2F%2Felectronicdesign.com%2Fcommunications%2Funderstanding-ieee-80211ac-vht-wireless&ei=2SO9VITND7T7sASG94GADw&bvm=bv.83829542,d.cWc&psig=AFQjCNGtlYiVypcsiygZ7X_58uoNZujzsw&ust=1421767979269453


Desafíos en VoWLAN

Cobertura

Movilidad

Calidad de Servicio

Capacidad

Seguridad


Cobertura

La cobertura de las redes WLAN muchas veces

se limita a las áreas donde se conectan los

usuarios (salas de reuniones compartidas,

recepción, etc.)

Bajas señales de radio frecuencia son

soportadas por las aplicaciones típicas de datos

(correo electrónico, navegación en Internet,

etc.), aún con tasas de errores elevadas


Cobertura

Las aplicaciones de telefonía móvil requieren una cobertura extendida, en escaleras, pasillos, áreas de descanso, y diversos sectores donde típicamente no eran áreas de trabajo para conexión de laptops

Los AP deben ser ubicados de tal forma que sus áreas de cobertura se solapen lo suficiente para que no se produzcan cortes o interrupciones en la comunicación


Movilidad

El proceso de “Roaming” es lento.

A nivel de cada 2: búsqueda de un nuevo AP

re-asociación

re-autenticación (IEEE 802.11x )

La re-autenticación es el proceso que mas demora (de cientos de milisegundos a varios segundos)

La IEEE 802.11r (de 2008) mejora los tiempos de re-autenticación


Movilidad

A nivel de cada 3:

búsqueda de un nuevo AP

re-asociación

re-autenticación (IEEE 802.11x )

renovación de dirección IP

La renovación de dirección IP puede llevar

varios segundos (DHCP)

Existen mecanismos propietarios para bajar

estos tiempos


Calidad de Servicio

Cuando la red inalámbrica se comparte entre

aplicaciones de voz y de datos, la calidad de la

voz y el video pueden verse fuertemente

afectadas, debido a que los paquetes de datos

pueden ser excesivamente largos, a

velocidades de transmisión relativamente bajas,

generando por tanto demoras y jitter mayores a

lo que se produce en redes cableadas


Calidad de Servicio

IEEE 802.11e (2005) establece dos nuevas

estrategias de acceso al medio, para asegurar

la calidad de servicio

EDCA (Enhanced Distributed Control Access)

Establece 4 categorías de acceso: voz, video, mejor

esfuerzo y “background”

HCCA (Hybrid Controlled Channel Access)

Sistema centralizado de control que permite a las

aplicaciones reservar recursos de red basados en sus

características de tráfico


WMM – Wi-Fi Multi Media

Basado en EDCA, establece 4 categorías de

acceso


WMM – Wi-Fi Multi Media


Capacidad

La cantidad máxima de llamadas en

determinada área será función de la cantidad de

usuarios en dicha área, y de las reglas de tráfico

habituales en telefonía

La capacidad de las redes WLAN está

esencialmente determinada por la cantidad de

canales de RF no solapados y la densidad de

APs instalados


Capacidad

Agregando APs que utilicen canales de RF que no interfieran (que no se “solapen” en la frecuencia) se incrementa la capacidad en un área determinada Si los canales se solapan, agregar más APs genera

interferencia de RF, lo que termina disminuyendo la capacidad.

802.11b/g tienen únicamente 3 canales de RF que no se solapan

802.11a tiene de 8 a 20 canales de RF que no se solapan


Protocolos de VoIP

H.323

Voz y Video en

Redes IP


H.323

Es un estándar “base” para las comunicaciones

de audio, video y datos a través de redes IP que

no proveen calidad de servicio garantizada

La primera versión fue aprobada en 1996 por la

ITU.

La versión 7 fue aprobada en diciembre de 2009

Es parte de las recomendaciones H.32x (como

por ejemplo H.320 para ISDN y H.324 para la

PSTN)


Arquitectura de H.323


Componentes de H.323

Terminales

Gateways (“pasarelas”)

Gatekeepers

Multipoint Control Units (“Unidades de control

multipunto, para conferencias”)


Terminales H.323

Son los “telefonos multimedia IP”

Deben soportar comununicaciones de voz, y

opcionalmente comunicaciones de video y

datos.

Pueden ser equipos “stand alone” conectados

directamente a la LAN, o software de PC.


Alcance de H.323

Control

Audio Codec

G.711, G.722, G.723,

G.728, G.729

Video Codec

H.261, H.263

Intrerfaz de datos

T.120

Canal de control

H.245

Canal de

señalización

H,225.0 (Q.931)

Canal de RAS

H.225.0

RTP

RTCP

UDP

TCP

IP

Micrófono

Parlante

Cámara

Display

Equipos de

datos

Control

Interfaces de

usuario

Terminal H.323


Estándares de Control

H.245 Describe los mensajes y procedimientos para abrir y cerrar

canales lógicos para audio, video y datos, y para realizar el control de las comunicaciones

Q.931 (H.225.0) Protocolo de control de conexiones (similar a ISDN)

RAS Registration/Admission/Status: Protocolo de comunicacion con

el Gatekeeper

RTP / RTCP Real-Time Protocol / Real-Time Control Protocol : Protocolo que

define los procedimientos para manejar datos de tiempo real


Gateways

Realiza funciones de interconexión entre

sistemas H.323 y sistemas de otro tipo (por

ejemplo redes ISDN o PSTN)


Gatekeeper

Actúa como “punto central” de las llamadas de

una determinada zona (como “PBX virtual”).

Funciones de control:

Traducción de “direcciones”

Gerenciamiento del ancho de banda

Ruteo de llamadas H.323


Traducción de direcciones

De números de teléfonos o nombres a direcciones

de red

Control de Admisión

Autorización de uso a los diversos dispositivos

(terminales, gateways, MCUs)

Control de Ancho de banda

Manejo del ancho de banda permitido para cada

servicio y/o terminal

Funciones obligatorias de

Gatekeepers


Funciones opcionales de

Gatekeepers

Autorización de llamadas

Control de llamadas (con fines administrativos -

costos)

Control de la señalización

Otras funciones, de acuerdo a criterios de los

fabricantes


Multipoint Control Units

Soporta conferencias entre 3 o más puntos

Consiste de:

MC: Multipoint Controller

Encargado de la señalización H.245 entre los terminales

MP: Multipoint Processors

Encargado de “mezclar” y procesar audio video y/o datos


Tipos de conferencias

Centralizadas

Utiliza MCU para centralizar el control y contenido de

la conferencia (dispone de MC y MP centralizado). La

comunicación es siempre punto a punto

Descentralizadas

Utilizan la tecnología de “Multicast”, donde el audio y

video es enviado por cada terminal a todos los otros

(utiliza MC y no MP)

Hibridas

Conjuga los modos anteriores


Esquema de un MCU en H.323


H.323 en el modelo OSI


Direct Call


Gatekeeper Routed


Fast Connect

Con este procedimiento el terminal que origina

una llamada pude proponer un conjunto de

canales de medios para su inmediata apertura

en el mensaje de establecimiento (setup) H.225

Se utiliza el campo “fastStart”, lo que permite

encapsular mensajes de apertura de canales de

medios H.245 (openLogicalChannel)


Ejemplo de captura H.323


Protocolos de VoIP

SIP

Voz y Video en

Redes IP


SIP

En marzo de 1999 es aprobado el RFC 2543, por el grupo de estudio MMUSIC (Multiparty Multimedia Session Control ) del IETF, dando origen oficial al protocolo SIP (Session Initiaton Protocol)

SIP tiene sus orígenes a fines de 1996, como un componente del “Mbone” (Multicast Backbone) El Mbone, era una red experimental montada sobre la Internet,

para la distribución de contenido multimedia, incluyendo charlas, seminarios y conferencias de la IETF. Uno de sus componentes esenciales era un mecanismo para invitar a usuarios a escuchar una sesión multimedia, futura o ya establecida. Básicamente un “protocolo de inicio de sesión” (SIP).

En junio de 2002, el RFC 2543 fue reemplazado por un conjunto de nuevas recomendaciones, RFC 3261-3266


“Filosofía” de SIP

Estándar de Internet

Promocionado por IETF - http://www.ietf.org

Reutilizar la tecnología de Internet:

URLs, DNS, proxies

Reutilizar el código HTTP

Textual, sencillo de implementar y depurar


Mensajería SIP

La mensajería SIP está basada en el esquema “Request” – “Response” de HTTP.

A diferencia de H.323, todos los mensajes son de texto plano, y por lo tanto fáciles de interpretar

Para iniciar una sesión se envía un mensaje de “Request” a una contraparte de destino. El destino recibe el “Request”, y lo contesta con el correspondiente “Response”.


RTP Audio G.729

RTP Video MPEG-1

ACK

BYE

180 Ringing

200 OK con SDP

200 OK

100 Tryinig

INVITE con SDP

sip:[email protected] sip:[email protected]

SIP/2.0 100 Trying100 Tryinig

SIP/2.0 180 Ringing180 Ringing

SIP/2.0 200 OK

Medios SDP:G.729MPEG-I Video

200 OK con SDP

INVITE sip:[email protected] SIP/2.0From: sip:[email protected]: sip:[email protected]

Medios SDP:G.729MPEG-I Video

INVITE con SDP

ACK sip:[email protected] SIP/2.0:5060ACK

BYE sip:[email protected] SIP/2.0:5060BYE

SIP/2.0 200 OK200 OK

Establecimiento de la llamada

Flujo de datos

Finalización de la llamada

Ejemplo de una llamada SIP


Los mensajes de “Request” tiene el formato:

<Método> <URL> <SIP-Version>

Ejemplo: INVITE sip:[email protected] SIP/2.0

Método Descripción

INVITE A session is being requested to be setup using a specified media

ACK Message from client to indicate that a successful response to an INVITE

has been received

OPTIONS A Query to a server about its capabilities

BYE A call is being released by either party

CANCEL Cancels any pending requests. Usually sent to a Proxy Server to cancel

searches

REGISTER Used by client to register a particular address with the SIP server

SUBSCRIBE Used to request status or presence updates from the presence server

NOTIFY Used to deliver information to the requestor or presence “watcher.”

SIP Requests


Método Descripción

REFER Used to referring the remote user agent to a web page or another URI

MESSAGE Used to transport instant messages (IM) using SIP

UPDATE Used to modify the state of a session without changing the state of the

dialog

INFO Used by a user agent to send call signaling information to another user

agent with which it has an established media session

PRACK Provisional ACK. Used to acknowledge receipt of reliably transported

provisional responses (1xx)

SIP Requests


Las respuestsa SIP son del estilo HTTP:

<SIP-Version> < Status-Code> <Reason>

Ejemplo: SIP/2.0 404 Not Found

Respuesta Descripción

1xx Informational – Request received, continuing to process request.

(100 Trying 180 Ringing 181 Call is Being Forwarded …)

2xx Success – Action was successfully received, understood and accepted.

(200 OK )

3xx Redirection – Further action needs to be taken in order to complete the

request.

4xx Client Error – Request contains bad syntax or cannot be fulfilled at this

server.

5xx Server Error – Server failed to fulfill an apparently valid request.

6xx Global Failure – Request is invalid at any server.

SIP Responses


Ejemplo: INVITE

INVITE sip:[email protected] SIP/2.0

Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Pepe <sip:[email protected]>

From: Alicia <sip:[email protected]>;tag=1928301774

Call-ID: [email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

v=0

o=AGarcia 2890844526 2890842807 IN IP4 126.16.64.4

s=Phone Call

c=IN IP4 100.101.102.103

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Cabezal


Ejemplo: INVITE

INVITE sip:[email protected] SIP/2.0

Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Pepe <sip:[email protected]>

From: Alicia <sip:[email protected]>;tag=1928301774

Call-ID: [email protected]

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 142

v=0

o=AGarcia 2890844526 2890842807 IN IP4 126.16.64.4

s=Phone Call

c=IN IP4 100.101.102.103

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

Cuerpo SDP


Cabezal

Tienen un formato del tipo Campo: Valor

Via: SIP/<version>/<transporte>

hostname:port;branch=<transaction

numer>Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds

Max-Forwards: <numero>

To: <dirección SIP>

From: <dirección SIP>


Direcciones SIP:

Utiliza el formato de URLs de Internet

Uniform Resource Locators

El formato general es nombre@dominio

Ejemplos:

sip:[email protected]

sip:Jose .M. Perez <[email protected]>

sip:[email protected];user=phone

sip:[email protected]

Cabezal


Cabezal

Call-ID: <numero>@<Host>

CSeq: <numero> <metodo>

Contact: <dirección SIP>

Content-Type: <tipo de contenido y

formato del cuerpo>

Content-Length: <largo del cuerpo>


Cuerpo SDP

El formato de cada renglón de SDP es <tipo>=<valor>

<tipo> es siempre un único carácter, y se

diferencian mayúsculas de minúsculas

El formato de <valor> depende del <tipo> al

que corresponda


Cuerpo SDP

Versión del protocolo (v)

Origen (o)o=<username> <session id> <version> <network type>

<address type> <address>

Nombre de la sesión (s)

Datos de la conexión (c)

c=<network type> <address type> <connection address>

Medios (m)

m=<media> <port> <transport> <fmt list>


SIP Clients and Servers

SIP utiliza una arquitectura cliente / servidor

Elementos:

SIP User Agents (Teléfonos SIP)

SIP Servers

SIP Gateways:

Hacia la PSTN para interconectar el “mundo” SIP al “mundo” TDM

Hacia H.323 para realizar interoperabilidad en el “mundo” IP

Clientes – Origina mensajes

Servidores – Responden a los mensajes o los redireccionan


SIP Clients and Servers - 2

Entidades lógicas SIP:

User Agents

User Agent Client (UAC): Inician requerimientos SIP

User Agent Server (UAS): Retornan respuestas SIP

Network Servers

Registrar: Acepta registraciones de clientes

Proxy: Decide el próximo salto y redirecciona el requerimiento

Redirect: Envía la dirección del próximo salto al cliente

Location: Servidor de búsqueda

Presence: Servidor de presencia


Ejemplos con Proxy Server


server.fing.com

200 OK

BYE

200 OK

INVITE sip:[email protected]

host.fing.com

200 OK

ACK


sip.abc.com

SIPUser Agent

Client

SIPProxyServer

SIPUser

AgentServer

Media Stream

Ejemplos con Proxy Server


Ejemplos con Redirect Server


302 Moved sip:[email protected]

ACK

Media Stream


SIPUser Agent

Client

SIPRedirectServer

180 Ringing

ACK


SIPUser Agent

Server

REGISTER [email protected]

host.fing.com.uy sip.ucla.com

200 OK

server.fing.com.uy

200 OK

C

RS

UAS

1

2

3

Media Stream

Ejemplos con Redirect Server


Comparación H.323 - SIP

H.323 SIP

Standard de ITU RFC de IETF

Primera versión de 1996 Primer RFC de 1999

Originalmente diseñado para

comunicaciones multimedia sobre redes

Originalmente diseñado para establecer

sesiones

Mensajes con representación binaria Mensajes con representación textual

Protocolos complejos Protocolos simples

Basado en Q.931 (ISDN) No basado en protocolos telefónicos

Utiliza RTP y RTCP Utiliza RTP y RTCP

Amplia difusión, pero disminuyendo Amplia difusión, en aumento


Protocolos

Propietarios de VoIP

Voz y Video en

Redes IP


Es un protocolo de señalización propietario de

Cisco, utilizado entre su servidor de telefonía

(“Call Manager”) y los teléfonos.

SCCP (Skinny Call Control

Protocol)


Es un protocolo de señalización propietario de

Asterisk, utilizado para la conexión de varios

servidores Asterisk, y también utilizando entre el

servidor de telefonía Asterisk y los teléfonos.

Está publicado en carácter informativo en el

RFC 5456 de la IETF.

IAX2 (Inter-Asterisk eXchange

protocol)


Unistim

Es un protocolo propietario de Avaya (antes

Nortel).

Originalmente fue diseñado como protocolo

digital, y posteriormente migrada a IP

Es utilizado entre los teléfonos Avaya y el

componente “Signaling Server”, parte del “core”

de los sistemas Communication Server 1000


NOE

Es un protocolo Propietario de Alcatel: New

Office Environment

Se utiliza entre los teléfonos Alcatel y el

procesador central de la PBX Alcatel


Muchas Gracias!

Dr. Ing. José Joskowicz

redes de voz - instituto de ingeniería eléctricaiie.fing.edu.uy/ense/asign/ccu/material/docs/voz...

Documents