curso telefonia ip

VoIP y Telefonía IP

Ing. José Cotúa

Arquitectura de Protocolos TCP/IP Ing. José Cotúa, Agosto 2007

Capítulo I: Arquitectura de Protocolos TCP/IP

1


Ing. José Cotúa

El Modelo de Referencia OSI

Layer 7: Aplicación

FTP, HTTP, HTTPS, SMTP, POP3, SNMP, BGP, etc.

Layer 6: Presentación Layer 5: Sesión Layer 4: Transporte

TCP, UDP, IPSec, OSPF

Layer 3: Red

IPv4 , IPv6/IPng

Layer 1: Enlace

Ethernet, Frame Relay, ATM, HDLC, X.25,

Layer 1: Física

Ethernet, V.35, RS-232, RS485,

Network


2

1


Ing. José Cotúa

El Modelo de Referencia TCP/IP

Aplicación

FTP, HTTP, HTTPS, SMTP, POP3, SNMP, BGP, etc.

Transporte

TCP, UDP, IPSec, OSPF IPv4 , IPv6/IPng

Red Enlace/Acceso

Ethernet, Frame Relay, ATM, HDLC, X.25, Ethernet, V.35, RS-232, RS485,

Física

Network


3


Ing. José Cotúa

Redes de Conmutació Conmutación de Circuitos Capacidad

Dedicada entre Usuarios.

Sincronización. Mayor confiabilidad y No requiere procedimientos de ReTransmisión. Sistema de Acceso bajo demando ó Secuencial.


4

2


Ing. José Cotúa

Redes de Conmutació Conmutación de Paquetes Paquetes/Datagramas: Entidades de Data que contienen una Cabecera y una Data Asociada.

Red IP

Destino Origen

Origen Destino


5


Ing. José Cotúa

6 bytes

6 bytes

campo de datos

de 46 a 1500 bytes

relleno.

1 byte

campo de tipo

dirección de origen

longitud

7 bytes

dirección de destino

2 bytes

preámbulo

delimitador

Ethernet IEEE 802.3 (Capa de Enlace) frame check sequen ce

4 bytes

Ethernet 10Base5 Ethernet 10Base2 Ethernet 10/100/1000/10000BaseT Ethernet 10Base-FP


6

3


Ing. José Cotúa

Otros Protocolos de Capa de Enlace Token

Ring

ATM Franme Relay IPX/SPX IEEE 802.1Q y IEEE 802.1P


7


Ing. José Cotúa

Direccionamiento IPv4 Protocolo de Internet, Versió Versión 4 Redes Basadas en una Arquitectura de Direccionamiento IPv4 Direcciones IPv4 y Enrutamiento Asignación de Direcciones IPv4 y Familias IPv4


8

4


Ing. José Cotúa

Direccionamiento IPv4 Aspectos Generales • Está Estándar IETF, Documento RFC791 (1981).

• Protocolo Oficial para INTERNET. • Se Fundamenta el Uso de las Direcciones IP. • Es un Protocolo de Red, Capa 3 del Modelo OSI y el Modelo TCP/IP. • Es un Protocolo No Confiable, No Confirmado. • Es un Protocolo No Orientado a Conexió Conexión. • Es un Protocolo Enrutable. Enrutable. • Trabaja bajo el Criterio ‘The Best Effort’ Effort’. • Pró Próxima Generació Generación => IPv6 ó Ipng (IETF, 1996). Capítulo I: Arquitectura de Protocolos TCP/IP

9

El Protocolo de Internet, Versió Versión 4 VoIP y Telefonía IP

Ing. José Cotúa

ESTRUCTURA DE UNA DIRECCIÓN IPv4 32 Bits 8 Bits

31

24 23 Octeto 3

16 15 Octeto 2

8 Bits

8 Bits

8 Bits

8

7

Octeto 1

0 Octeto 0

• Cada Octeto (Byte) en el Rango: 0, …,255. (00H, …,FFh) • Un Total de 232 (4.294.967.296) Direcciones IPv4. • Rango de Direcciones IPv4: En Formato Decimal: desde 0, hasta 4.294.967.295 (232-1). En Formato Hexadecimal: desde 00h, hasta FFFFFFFFh. En Formato Base 256: desde 0.0.0.0, hasta 255.255.255.255.


10

5


Ing. José Cotúa

Formato Base 256 (Formato Decimal por Puntos). Se Expresa cada Octeto en Base 256 y se Separan los Octetos con un Punto. Se tiene entonces el siguiente Rango de Direcciones IPv4 expresado en Formato Base 256, Desde: 0.0.0.0 Hasta:

255.255.255.255, con cada Octeto entre 0 y 255.

Ejemplos, Las siguientes son Direcciones IPv4: IPv4: 10.0.2.36.25

150.25.69.69

100.100.10.25

200.47.151.140

200.36.99.95

10.0.7.254

Las siguientes NO son Direcciones IPv4: IPv4: 10.10.25.300

10.10.10.256

25.130.256.285

1000.200.257.300


11


0.0.0.0

Ing. José Cotúa

Rango Total de Direcciones IPv4 • Se Identifican y Define Bloques que Contienen siempre 2N Direcciones IPv4 Contiguas.

0.0.0.255 0.0.1.0 0.0.0.1.255 0.1.0.0 0.1.255.255

Bloques de 1 (20) Direcciones IPv4. Bloques de 2 (21) Dirección IPv4. Bloques de 4 (22) Direcciones IPv4. Bloques de 8 (23) Direcciones IPv4. Bloques de 16 (24) Direcciones IPv4. Bloques de 32 (25) Dirección IPv4. Bloques de 64 (26) Direcciones IPv4. Bloques de 128 (27) Direcciones IPv4. Bloques de 256 (28) Direcciones IPv4. Y así sucesivamente … Un Bloque de 2N es la Unión de Dos Bloques de 2N-1

255.255.255.255 Capítulo I: Arquitectura de Protocolos TCP/IP

12

6


Ing. José Cotúa

Divisió División de las Direcciones IPv4 por Clases ESTRUCTURA DE UNA DIRECCIÓN IPv4 32 Bits 8 Bits

31

24 23 Octeto 3

Direcciones IPv4 Clase A Bloque Clase A Reservado para Loopback

0

Direcciones IPv4 Clase B

1

0

Direcciones IPv4 Clase C

1

1

0

Direcciones IPv4 Clase D

1

1

1

0

Direcciones IPv4 Clase E

1

1

1

1

8 Bits

8 Bits

8 Bits

16 15

8

Octeto 2

7

Octeto 1

ID-RED (7 Bits) 127

0 Octeto 0

ID-HOST (24 Bits) ID-Dirección LOOPBACK

ID-RED (14 Bits)

ID-HOST (16 Bits)

ID-RED (21 Bits)

ID-HOST (8 Bits)

ID-GRUPO_MULTICAST (28 Bits)

0

ID-RESERVADO USO FUTURO (27 Bits)


13


Ing. José Cotúa

Direcciones IPv4 Clase A Bit7 del Octeto3 en ‘0’. Bit6-Bit0 del Octeto3 Identificador de Red (Máscara /8). Octeto2-Octeto1-Octeto0 Identificador de Host. Familia IPv4 Privada Clase A 10.0.0.0/8.

Octeto3 Octeto2 Octeto1 Octeto0 7 6 5 4 3 3 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 0

7 bits: ID de Red


24 bits: ID de Host

14

7


Ing. José Cotúa

Direcciones IPv4 Clase B Bit7 del Octeto3 en ‘1’ y Bit6 del Octeto3 en ‘0’. 14 Bits de Octeto3 y Octeto2 para ID de Red (Máscara /16). Octeto1-Octeto0 Identificador de Host. Familia IPv4 Privada Clase B 172.16.0.0/12.

Octeto3 Octeto2 Octeto1 Octeto0 7 6 5 4 3 3 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 1 0

14 bits: ID de Red

16 bits: ID de Host


15


Ing. José Cotúa

Direcciones IPv4 Clase C Bit7-Bit6-Bit5 de Octeto3 en ‘110’. 21 Bits de Octeto3, Octeto2 y Octeto1 para ID de Red (Máscara /24). Octeto0 Identificador de Host. Familia IPv4 Privada Clase C 192.168.0.0/24.

Octeto3 Octeto2 Octeto1 Octeto0 7 6 5 4 3 3 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 1 1 0

21 bits: ID de Red


8 bits: ID de Host

16

8


Ing. José Cotúa

Direcciones IPv4 Clase D Para uso como Direcciones IPv4 de Destino en Tráfico Multicast. Familia IPv4 Clase D: 224.0.0.0 239.255.255.255 Octeto3 Octeto2 Octeto1 Octeto0 7 6 5 4 3 3 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 1 1 1 0

28 bits: ID de Grupo Multicast


17


Ing. José Cotúa

Direcciones IPv4 Clase E Reservadas por la IANA para Uso Futuro/Experimental. Familia IPv4 Clase E: 240.0.0.0 247.255.255.255 Octeto3 Octeto2 Octeto1 Octeto0 7 6 5 4 3 3 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 1 1 1 1 0


27 bits: Reservados

18

9


Ing. José Cotúa

Direcciones IPv4 para Interfaces ‘Loopback’ Todo Host que hable IPv4 tiene una Interfaz Virtual, llamada Interfaz de Loopback ‘lo’, con asignación de Direcciones IPv4 de la Familia 127.0.0.0/8. Su uso esta estrictamente reservado para Uso Interno. Interfaz ‘lo’ localhost Familia 127.0.0.0/8: 127.0.0.0 127.255.255.255 No se debe asignar nunca una dirección de esta familia a ninguna Interfaz de ningún Host. Direcciones IPv4 Especiales: 0.0.0.0 y 255.255.255.255 !!! Capítulo I: Arquitectura de Protocolos TCP/IP

19


Ing. José Cotúa

Bloques de Direcciones IPv4 y Familias IPv4 • Se define un Bloque de Direcciones IPv4 como: un conjunto contiguo de Direcciones IPv4 de Tamaño 2N. Es decir, solo hay Bloques de 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 .. Direcciones IPv4. • Un Bloque de Direcciones IPv4 define una Familia IPv4. • El Tamaño de una Familia IPv4 se define a través de una Máscara de Red. Red • Un Bloque IPv4 de Tamaño 2N, SIEMPRE debe comenzar en una Dirección IPv4 Múltiplo de 2N. Máscara de Red. Red • Una Máscara de Red es un Número, con el mismo Formato que una Dirección IPv4, que se utiliza para definir el Tamaño de una Familia IPv4. Formato y Estructura de una Máscara de Red 1 1 1 1 1 1 1 1 1 1 1 . . . 1 1 1 0 . 0 0 0 0 0 0 0 0 0 0 0 0 0

M Bits Consecutivos en '1'


(32-M) Bits Consecutivos en '0' 20

10


Ing. José Cotúa

Bloques de Direcciones IPv4 y Familias IPv4 Formato y Estructura de una Máscara de Red 1 1 1 1 1 1 1 1 1 1 1 . . . 1 1 1 0 . 0 0 0 0 0 0 0 0 0 0 0 0 0

M Bits Consecutivos en '1'

Decimal 255 254 252 248 240 224 192 128 0

(32-M) Bits Consecutivos en '0' Binario 11111111 11111110 11111100 11111000 11110000 11100000 11000000 10000000 00000000


21


Ing. José Cotúa

Bloques de Direcciones IPv4 y Familias IPv4 Si M es el Número de Bits en ‘1’ que tiene la Máscara de Red, entonces 2M es el Tamañ Tamaño de la Familia IPv4 o Bloque IPv4 al que hace Referencia. 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 254 252 248 240 224 192 128 0

Formato . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 254 . 252 . 248 . 240 . 224 . 192 . 128 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0

Base 256 . 255 . 255 . 255 . 254 . . 255 252 . 255 . 248 . . 255 240 . 255 . 224 . 255 . 192 . 255 . 128 . 255 . 0 . . 254 0 . . 252 0 . . 248 0 . 240 . 0 . 224 . 0 . 192 . 0 . 128 . 0 . . 0 0 . . 0 0 . . 0 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . . 0 0 . . 0 0 . . 0 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . . 0 0 . . 0 0 . . 0 0

Formato CIDR (/M) / 32 / 31 / 30 / 29 / 25 / 27 / 26 / 25 / 24 / 23 / 22 / 21 / 20 / 19 / 18 / 17 / 16 / 15 / 14 / 13 / 12 / 11 / 10 / 9 / 8 / 7 / 6 / 5 / 4 / 3 / 2 / 1 / 0

Tamaño de la Familia IPv4 1 2 4 8 128 32 64 128 256 512 1.024 2.048 4.096 8.192 16.384 32.768 65.536 131.072 262.144 524.288 1.048.576 2.097.152 4.194.304 8.388.608 16.777.216 33.554.432 67.108.864 134.217.728 268.435.456 536.870.912 1.073.741.824 2.147.483.648 4.294.967.296

¡¡ 33 Má Máscaras de Red Posibles en IPv4 !! Capítulo I: Arquitectura de Protocolos TCP/IP

22

11


Ing. José Cotúa

Bloques de Direcciones IPv4 y Familias IPv4 Si M es el Número de Bits en ‘1’ que tiene la Máscara de Red, entonces 2M es el Tamañ Tamaño de la Familia IPv4 o Bloque IPv4 al que hace Referencia. Máscara de Red Barra /32

Total Direcciones IP

Decimal 255.255.255.255

Totales

IP Familia

IP Broadcast

IP DGW

Restantes

1

**

**

**

**

**

/31

255.255.255.254

2

**

**

/30

255.255.255.252

4

1

1

**

/29

255.255.255.248

8

1

1

1

5

/28

255.255.255.240

16

1

1

1

13

/27

255.255.255.224

32

1

1

1

29

/26

255.255.255.192

64

1

1

1

61

/25

255.255.255.128

128

1

1

1

125

/24

255.255.255.0

256

1

1

1

253

1

¡¡ 33 Má Máscaras de Red Posibles en IPv4 !! Capítulo I: Arquitectura de Protocolos TCP/IP

23


Ing. José Cotúa

Bloques de Direcciones IPv4 y Fmilias IPv4 En una Familia IPv4 se especifica entonces con una Dirección IPv4 (Identificador IPv4 de la Familia o Dirección IPv4 de la Familia) y una Máscara de Red. • Dada cualquier Dirección IP de una Familia IPv4 (Any-Dir_IPv4), la Máscara de Red (Mask) se puede Calcular el Identificador de la Familia IPv4 (IPv4_Familia) como: IPv4_Familia IPv4_Familia = (Any (Any--Dir_IPv4) Dir_IPv4) And_Bits (Mask) Mask) Ec. Ec. 1 La IPv4_Familia es SIEMPRE la Primera Dirección IPv4 del Bloque. La IPv4_Familia Identifica a la Familia IP y JAMAS debe ser Asignada a NINGÜN Host de la Red. • En Toda Familia IPv4 se Define una Dirección IPv4 Especial llamada Direcció Dirección IP de Broadcast (IPv4_Broadcast) de la Familia IP. Esta, es SIEMPRE la Última Dirección IPv4 del Bloque. Se calcula así, IPv4_ IPv4_Broadcast = (Any (Any--Dir_IPv4) Dir_IPv4) Or_Bits (Mask’ Mask’) Ec. Ec. 2 La IPv4_Broadcast se utiliza cuando un Host quiere Transmitir un Paquete IPv4 a TODOS los demás Host’s de la Red. Al igual que la IPv4_Familia, JAMAS debe ser asignada. Capítulo I: Arquitectura de Protocolos TCP/IP

24

12


Ing. José Cotúa

Bloques de Direcciones IPv4 y Familias IPv4 Ejemplo de una Familia IPv4. IPv4. Familia IPv4: 200.47.50.0 (IPv4_Familia) Máscara de Red: 255.255.255.0 (/24) (Tamaño del Bloque = 256) IPv4_Broadcast = (200 . 47 . 50 . 0) OR_Bits (0.0.0.255) = 200.47.50.255 Rango de Direcciones IPv4 de la Familia, Desde: Desde 200.47.50.0

(Esta Dirección NO se DEBE Asignar)

200.47.50.1

Note que Solo Tengo, en este caso, 254 Direcciones IPv4 para Asignar !!!

… 200.47.50.254

Hasta: Hasta 200.47.50.255 (Esta Dirección IP NO se DEBE Asignar) Se Identifica la Familia IPv4 así: 200.47.50.0 /24 Capítulo I: Arquitectura de Protocolos TCP/IP

25


Ing. José Cotúa

Bloques de Direcciones IPv4 y Familias IPv4 Ejemplo de una Familia IPv4. IPv4. Familia IP: 172.23.12.0 Máscara de Red: 255.255.255.0 Identificador IP de la Familia: 172.23.12.0

¡¡NO Asignable!!

Dirección IP de Multidifusión: 172.23.12.255

¡¡NO Asignable!!

Direcciones IP Asignables: 172.23.12.1, …., 172.23.12.254.

Familia IP 172.23.12.0 /24


26

13


255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 255 254 252 248 240 224 192 128 0

Formato . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 255 . 254 . 252 . 248 . 240 . 224 . 192 . 128 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0

Base 256 . 255 . 255 . 255 . 254 . . 255 252 . 255 . 248 . . 255 240 . 255 . 224 . 255 . 192 . 255 . 128 . 255 . 0 . . 254 0 . . 252 0 . 248 . 0 . 240 . 0 . 224 . 0 . . 192 0 . . 128 0 . . 0 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . 0 . . 0 0 . . 0 0 . . 0 0 . 0 . 0 . 0 . 0 . 0 . 0 . . 0 0 . . 0 0 . . 0 0 . 0 . 0 . 0 . 0 . 0 . 0

Formato CIDR (/M) / 32 / 31 / 30 / 29 / 25 / 27 / 26 / 25 / 24 / 23 / 22 / 21 / 20 / 19 / 18 / 17 / 16 / 15 / 14 / 13 / 12 / 11 / 10 / 9 / 8 / 7 / 6 / 5 / 4 / 3 / 2 / 1 / 0

Tamaño 1 2 4 8 128 32 64 128 256 512 1.024 2.048 4.096 8.192 16.384 32.768 65.536 131.072 262.144 524.288 1.048.576 2.097.152 4.194.304 8.388.608 16.777.216 33.554.432 67.108.864 134.217.728 268.435.456 536.870.912 1.073.741.824 2.147.483.648 4.294.967.296

Ing. José Cotúa IPv4 Asignables N/A N/A 2 6 126 30 62 126 254 510 1.022 2.046 4.094 8.190 16.382 32.766 65.534 131.070 262.142 524.286 1.048.574 2.097.150 4.194.302 8.388.606 16.777.214 33.554.430 67.108.862 134.217.726 268.435.454 536.870.910 1.073.741.822 2.147.483.646 4.294.967.294


27


Ing. José Cotúa

Otros Ejemplos de Familias IPv4 10.0.0.0/8

200.25.25.0.29

200.47.0.0/16

192.168.25.0/27

200.47.151.128/28

10.25.25.64/26

172.16.19.0/30

172.16.19.4/30

200.200.200.192/29

10.0.7.0/29

10.0.7.8/29

10.0.7.16/28


28

14


Ing. José Cotúa

La Familia IPv4 y la Má Máscara de Red 1

1

1

1

1

1

1

1

.

1

1

1

1

1

1

1

1

.

1

0

0

0

0

0

0

0

.

0

0

0

0

0

0

0

0

0

M Bits Consecutivos en '1' (32-M) Bits Consecutivos en '0'

Bits de Red

Bits de Host

232-M, Direcciones IPv4 para la Red /M La Primera Dirección IPv4, La IPv4_Familia => Bits de Host = ’00..00’ 232-M-2, Direcciones IPv4 para los Host’s de la Red La Última Dirección IPv4, la IPv4_Broadcast => Bits de Host en ’11..11’ Los Bits de Red, Permanecen Fijos en Todas las Direcciones del Bloque IPv4 Identifican a la Red/Bloque IPv4

Ejemplo, la Red 10.0.64.0 /22 (Má (Máscara de Red /22, 255.255.252.0) !!! Capítulo I: Arquitectura de Protocolos TCP/IP

29


Ing. José Cotúa

La IANA (http ://www.iana.org www.iana.org)) (http:// Autoridad Internacional que Regula y Establece todo lo Relacionado al Uso de las Direcciones IPv4/IPv6, los Servicios y Protocolos y la Asignación de Puertos/Servicios.

ipv4ipv4-addressaddress-space multicastmulticast-addresses portport-numbers


30

15


Ing. José Cotúa

Clasificació Clasificación de las Direcciones IPv4 segú según la IANA Direcciones IPv4 Privadas • Los Bloques 10.0.0.0 /8, 192.16.0.0 /16 y 172.16.0.0 /12. • Solo para ser usadas en ambiente de Redes LAN a Nivel Privado. • No se admite tráfico en INTERNET con Direcciones IPv4 Privadas. Direcciones IPv4 de Loopback • El Bloque 127.0.0.0/8, se Reserva su Uso Exclusivamente para Interfaces de Loopback (lo). Direcciones IPv4 de Uso Reservado • Clase E: 240.0.0.0 247.255.255.255 Direcciones IPv4 Públicas, Reales, Certificadas • Todas aquellas que no son: Ni Reservadas, Ni Privadas, Ni de uso para Loopback. • Son Asignadas y Enrutadas por Proveedores ISP / WISP’s (Proveedores de Acceso a INTERNET). Y su asignación se negocia de acuerdo a los planes. Capítulo I: Arquitectura de Protocolos TCP/IP

31


Ing. José Cotúa

Asignació Asignación de Direcciones IPv4 A) Asignación de Direcciones IPv4 Estáticamente (Direcciones IPv4 Fijas). Mecanismo mediante el cual, el administrador de una Red IPv4, asigna en forma Manual, estática y de manera Pre-Definida a cada Host una Dirección IPv4. Las Direcciones IPv4 se Asignan a las Interfaces de Red, Ethernet, Frame Relay, Seriales Síncronas, ATM. Se pueden Asignar Varias Direcciones IPv4, de una misma Familia, a un Host dado siempre y cuando se asignen a solo una Interfaz de Red. NO se puede asignar a distintas Interfaces de Red Direcciones IPv4 de una misma Familia IP. Se pueden Asignar Varias Direcciones IPv4, de distintas Familias, a distintas Interfaces de Red. La asignación de una Dirección IPv4 a una Interfaz de Red de un Host; hace pertenecer al Host a la Red LAN de esa Familia IPv4 por esa Interfaz donde se ha configurado la(s) Dirección(es) IPv4. Hay que ser cuidadoso y mirar con detalle las Configuraciones de Direcciones IPv4 en un Host; para evitar Problemas de Inestabilidad. Capítulo I: Arquitectura de Protocolos TCP/IP

32

16


Ing. José Cotúa

Asignació Asignación de Direcciones IPv4 B) Asignación de Direcciones IPv4 Dinámicamente. Protocolo DHCP (Dynamic Host Configuration Protocol). Protocolo BOOTP (Boot Protocol). Con la Asignación estática de Direcciones IPv4 se tienen los siguientes inconvenientes, Pérdida de tiempo por reconfiguración. Por ejemplo, si el Host de mueve de una red a otra hay que reconfigurarlo manualmente. Inconvenientes en situaciones de acceso dinámico de los host’s a las redes IPv4; y en situaciones donde se tienen mas host’s que direcciones IPv4 disponibles. Por ejemplo, el caso del Acceso a INTERNET (hoy poco utilizado) vía ‘Dial-UP’. Serios inconvenientes si se cometen errores a la hora de la configuración. Por ejemplo, que se repitan asignaciones de direcciones IPv4 en una misma Red.


33


Ing. José Cotúa

Escenario de IPv4 en INTERNET para Redes Privadas NAT’s y Enmascaramiento: Paño Caliente El Ideal: Conexiones IP End To End ISP / WISP Internet TCP/IP

Router WAN / LAN

Red LAN Protocolo TCP/IP Familia IP


34

17


Ing. José Cotúa

Conexiones TCP y UDP Aplicación proc. de usuario

• proc. de usuario

proc. de usuario

TCP

UDP

proc. de usuario Transporte Red

ICMP

IP

IGMP

• • •

• ARP

Interfaz

RARP Enlace

Red / Medio

•

TCP – provee confiabilidad; implementa conexión de datos, recuperación de errores por repetición, control de flujo UDP – transporte de datagramas, no orientado a conexión IP – protocolo de enrutamiento ICMP – gestión de errores de la capa IP (implementa, por ejemplo, Ping y Traceroute) IGMP – gestión de grupo (para multicasting) ARP (Address Resolution Protocol) e RARP (Reverse ARP) – para conversión de direcciones IP en direcciones usadas por la interfaz de red y vice-versa


35


Ing. José Cotúa

Protocolo TCP Protocolo Fiable ya que dispone de un Mecanismo de Confirmación (ACK); es decir es Confirmado.

Es un Protocolo de Ventana Deslizante. Es un Protocolo Orientado a Conexión; dispone de mecanismos de Establecimiento y Cierre de Conexión. Multiplexa Servicios y Aplicaciones a través de Puertos; Puertos TCP: 0 – 65.535. Dispone de un mecanismo de recuperación ante errores de transmisión y de re-secuenciamiento de los paquetes. Aplicaciones que usan TCP: HTTP, HTTPS, TELNET, SSH, POP3, SMTP, ETC. Es mas Lento que UDP !!! Capítulo I: Arquitectura de Protocolos TCP/IP

36

18


Ing. José Cotúa

Protocolo UDP Protocolo No Fiable ya que No dispone de un Mecanismo de

Confirmación (ACK); es decir es No Confirmado.

Es un Protocolo No Orientado a Conexión; No dispone de mecanismos de Establecimiento ni Cierre de Conexión. Sin embargo, el Sistema Operativo que lo ejecuta mantiene una Base de Datos (Monitor) de los Procesos UDP. Multiplexa Servicios y Aplicaciones a través de Puertos; Puertos UDP: 0 – 65.535. No Dispone de un mecanismo de recuperación ante errores de transmisión y de re-secuenciamiento de los paquetes. Aplicaciones que usan UDP: DNS, DHCP, Traceroute, NTP, SIP, Multimedia Streaming. Es mas Rápido que TCP; la Cabecera es mas Pequeña y No tiene Confirmación !!! Capítulo I: Arquitectura de Protocolos TCP/IP

37


Ing. José Cotúa

Funciones de NAT y Enrutamiento NAT

por Origen: Src-Nat

NAT por Destino: Dst-nat NAT por Sobrecarga: Masquerading (Enmascaramiento) El Proceso de Enmascaramiento TCP, UDP e ICMP Funciones de NAT e INTERNET


38

19


Ing. José Cotúa

Análisis de la Señal de Voz José Cotúa, Agosto 2007

Capitulo II: Análisis de la Señal de Voz

1


Ing. José Cotúa

Análisis de la Señal de Voz La Señal de Voz: en su forma mas elemental es proviene de una fuente acústica convertida en una señal eléctrica, voltaje v(t) o corriente i(t), a través del uso de un transductor. La Señal de Voz es una Señal Eléctrica, V(t) y/o I(t) → X(t)

t Capitulo II: Análisis de la Señal de Voz

2

1


Ing. José Cotúa

Análisis de la Señal de Voz Transductores (Conversión de Tipos de Señal) De Acústica a Eléctrica: Micrófonos De Eléctrica a Acústica: Cornetas


3


Ing. José Cotúa

Análisis de la Señal de Voz Análisis en Tiempo de la Señal de Voz Señal Analógica: Variación Contínua en Tiempo. Señal No Determiniística (Aleatoria). NO podemos predecir su valor en tiempo, pero podemos entender y explicar su comportamiento. Señal No Periódica (Aperiódica). Señal que padece del Fenómeno de Irreversibilidad. Descrita Técnicamente con: Vprom (Vdc), Vrms, Vmax, Vmin y Vpp t Capitulo II: Análisis de la Señal de Voz

4

2


Ing. José Cotúa

Análisis de la Señal de Voz Análisis en Tiempo de la Señal de Voz La definicón matemática de los parámetros técnicos de análisis en tiempo es la siguiente:

VPICO = VMAX VPICO− PICO = VMAX − VMIN VPROMEDIO = VDC = ∫ X (t )dt T0

VRMS =

∫X

2

(t )dt

T0

t Capitulo II: Análisis de la Señal de Voz

5


Ing. José Cotúa

Análisis de la Señal de Voz Análisis en Frecuencia de la Señal de Voz Toda señal X(t) tiene una representación equivalente en el dominio de la Frecuencia. El Análisis se Fundamenta en las Herramientas de Análisis de Fourier. Para Señales Continuas en Tiempo: Serie de Fourier (Periódicas) y Transformada de Fourier. Para Señales en Tiempo Discreto: Transformada Discreta de Fourier (DFT/FFT) y Transformada Z.


6

3


Ing. José Cotúa

Análisis de la Señal de Voz Análisis en Frecuencia de la Señal de Voz Parametrización en el espacio Frecuencial: Fmax ó Ancho de Banda en Banda Base (BW). Señales de Voz: Fmax = BW = 4KHz; con componentes espectrales entre 200Hz y 4000Hz. Señales de Audio: Fmax = BW = 22kHz; con componentes espectrales entre 200Hz y hasta 22kHz. (!! Música e Instrumentos !!). Fmax para Voz 4KHz Fmax para Audio hasta 22KHz Capitulo II: Análisis de la Señal de Voz

7


Ing. José Cotúa

Análisis de la Señal de Voz Acondicionamiento de la Voz para VoIP Una vez comprendida un poco la naturaleza y definiciones de la señal de voz, enfrentamos nuestro primer desafío: “ La Señal de Voz es una Señal Analógica, con Variación Contínua en el Tiempo, y el Protocolo IP es Estrictamente y 100% Digital: ¿Qué Hacemos? ” ¿Quién debe adaptarse a quién? La Voz debe adaptarse al Protocolo IP. Nuestro Primer Paso: Digitalización. ‘ Digitalización de la Señal de Voz ’ Capitulo II: Análisis de la Señal de Voz

8

4


Ing. José Cotúa

Análisis de la Señal de Voz Acondicionamiento de la Voz para VoIP Digitaliazación de la Señal de Voz Pasos Fundamentales: - Filtrado - Muestreo y Retención - Cuantificación - Codificación Pasos Secundarios: - Consideración de Efectos de Ruido - Errores, Compresión y Encriptamiento Capitulo II: Análisis de la Señal de Voz

9


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Muestreo Este proceso consiste en registrar el valor de la señal de Voz/Audio a intervalos regulares de tiempo. El intervalo de tiempo entre cada 2 instantes de muestreo consecutivos es igual a “TS” segundos y se le denomina PERIODO DE MUESTREO (TS).


10

5


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Muestreo En su análisis se lo puede clasificar en tres tipos: Ideal: El instante de muestreo (T), tiende a cero, es decir se trata de una sucesión de muestras infinitas. Natural: El tren de pulsos posee un período T de cualquier valor distinto de cero. La función muestreada tendrá un número infinito de valores en el período de muestreo.


11


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Muestreo Muestreo y Retención: (Sample and Hold) Es el que se emplea en la práctica, y consiste en tomar la muestra y retener el valor un cierto tiempo hasta que comience el próximo período de muestreo. TEOREMA DEL MUESTREO, NYQUIST:


Toda señal analógica se puede recuperar o reconstruir a partir de sus muestras tomadas a intervalos regulares de tiempo TS segundos, siempre que se cumpla la condición: (1/TS= FS) ≥ 2BW BW: es la máxima frecuencia Espectral, TS es el periodo de muestreo y FS es la frecuencia de muestreo).

12

6


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Cuantificación Proceso que consiste en transformar los niveles de amplitud continuos de la señal de entrada previamente muestreada, en un conjunto de niveles discretos previamente establecidos. En esta etapa sí se pierde información, y mayor será su pérdida cuanto menor sean los niveles determinados, esta pérdida se llama error o ruido de cuantificación.


13


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Cuantificación

Mensaje

Señal cuantificada Con Q=8


14

7


Ing. José Cotúa


Mensaje



15


Ing. José Cotúa


Mensaje



16

8


Ing. José Cotúa


Mensaje



17


Ing. José Cotúa



18

9


Ing. José Cotúa



19


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Cuantificación Niveles de Cuantificación (L) → Número de Bits por Muestra (n).


20

10


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Codificación

Proceso que consiste en convertir los pulsos cuantificados en un grupo equivalente de pulsos binarios de amplitud constante. En la práctica para la transmisión de voz digitalizada se emplean sistemas de ocho bit por muestra, lo que equivale a trabajar con 256 niveles cuánticos.


21


Ing. José Cotúa

Análisis de la Señal de Voz El Proceso de Codificación Es por esta razón que al digitalizar un canal telefónico de voz cuyo ancho de banda es 4.000 Hz, tomando muestras al doble de este ancho de banda, implica 8.000 muestras/segundo, las que al cuantificar en 256 niveles y codificar con 8 bit dan como resultado 8.000 m/s * 8 bit = 64.000 bit /seg, que es el ancho de banda de un canal telefónico digitalizado. Proceso de Codifiicación Típico: Ancho de Banda Considerado: 4 KHz. Niveles de Cuantificación: 256. Bits de Codificación: 8. Frecuencia de Muestreo: 8 KHz. Tiempo de Muestreo: 250 us. Tasa de Bits Mínima: 64.000 Bits por Segundo. (¡Sin Compresión!). ‘ Una señal de Voz necesita de 4KHz de Ancho de Banda, necesita ser Muestreada a una Tasa de 4000 Muestras por Segundo. Esto equivale a la necesidad de enviar 64Kbits por segundo, para poder transmitirla en formato digital ‘ Capitulo II: Análisis de la Señal de Voz

22

11


Ing. José Cotúa

Análisis de la Señal de Voz Algunas Comparaciones Señal

BW

Freq. Nyquist

Freq. Muestreo

N

KBPS

Audio

200-20000

40KHz

48KHz

16

768

Audio CD

200-20000

40KHz

44.1KHz

16

705.6

Telefoní Telefonía (Voz)

200200-4000

8KHz

8KHz

8

64

‘ Generalmente, cuando nos referimos a la Voz en VoIP, hablamos de Voz para Telefonía. Sin embargo, Podemos eventualmente estar hablando de Señales de Audio con mayor Ancho de Banda: Radio sobre IP, Música sobre IP en Tiempo Real, Trunking IP, Multimedios sobre IP, etc. ’


23

12


Ing. José Cotúa

CODEC’s de VoIP Ing. José José G. Cotú Cotúa, Agosto 2007

Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF


1

Ing. José Cotúa

CODEC’s de VoIP Codec: Codec: Codificador - Decodificador

Encargado de los Procesos de: Filtrado Muestreo y Retenció Retención Cuantificació Cuantificación Codificació Codificación Compresió Compresión Encriptamiento Empaquetamiento Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

2

1


Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales La Voz/Audio: Señal Analógica, continua en el Tiempo. Parametrización en el Dominio Temporal: vmax, vmin, vprom, vrms. Parametrización en el Dominio Frecuencial: fmax. Voz: frecuencias entre 200Hz y 4KHz (fmax) Audio: frecuencias entre 200Hz y 22KHz (fmax)

3



Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales El Primer Proceso: Digitalización de la Señal de Voz/Audio (Filtrado + Muestreo/Retención + …). Para la Frecuencia de Muestreo: Teorema de Nyquist FS mayor o igual que 2FMAX El primer procesamiento con el que se encuentra la señal de voz en una red de VoIP es el Codec (Codificación y Decodificación).


4

2


Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales Procesamiento de Voz/Audio: Filtrado, Muestreo y Retención, Cuantificación, Codificación, Compresión, Encriptamiento y Empaquetamiento. En VoIP se añade un componente procesamiento de la Señal de Empaquetamiento.

adicional al Voz/Audio:

Si la comunicación de voz/audio es full-duplex, el proceso de CODEC es bidireccional. Fenómeno de Irreversibilidad de la Voz. 5



Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales Conceptos de Compresión Perceptiva. La Red IP: IPv4 ó IPv4/Ipng; Pérdida de Paquetes, Jitter, Retardo, Multienrutamiento, Desordenamiento (Desincronía de Paquetes), etc. Factor de Compresión: ¿Qué tanto puedo reducir en consumo de Ancho de Banda?; mientras mayor es la Tasa de Compresión, y otras funcionalidades, mayor es el procesamiento y mayor es el Retardo Intrínseco de los Codec’s.


6

3


Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales Los CODEC’s tienen impacto en la Señalización concurrente en canales de VoIP como: DTMF, Tonos de Telefonía, Tonos de Fax, Tonos de Modem, Tonos SubAudibles, etc. Realmente, en la actualizad el CODEC es un proceso que se ejecuta en Software; hay soluciones privativas y no privativas y depende de la arquitectura, del procesador y/o del sistema operativo que lo ejecute. Para desarrollo y diseño hay que seguir al pie de la letra el estándar.

7



Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales Para los Gateway’s, Softswitch’s y IP-PABX’s se tienen varios procesos de CODEC’s de forma concurrente. Es posible integrar en aplicaciones VoIP los Traductores de CODEC’s. Los Anchos de Banda que nos Suministran y Cobran los ISP/WISP y demás Proveedores de Interconexión se miden es a Nivel de Interface; no a nivel de Aplicación/Transporte/Red. Esto es, por ejemplo, un 256kbps (simétrico o no) representa un Ancho de Banda mucho menor a Nivel de Aplicación…..!!!! Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

8

4


Ing. José Cotúa

CODEC’s de VoIP Consideraciones Iniciales y Aspectos Generales Parámetros de un Codec: Frecuencia de Muestreo. Tamaño de la Trama. Retardo Intrínseco. Tasa de Compresión Nativa. Tamaño del Frame y Payload. Factor/Tasa de Compresión. Escala MOS. Otros. 9



Ing. José Cotúa

Digitalización: 64 KBPS

CODEC de VoIP Visualizació Visualización del Proceso

- Filtrado (Filter). - Muestreo y Retención (Sample and Hold).

Voz/Audio

- Cuantificación (Cuantization).

Analógica

- Codificación (Codification).

Compresión

Analog

CODEC Digital

Media Stream

?? KBPS Paquetes UDP/IP/Ethernet

PBN: IP

Packets


10

5


Ing. José Cotúa

Estructura Funcional de un CODEC de VoIP vmin, vmax, vprom, vrms, fmax (BW)

Fs: Frecuencia de Muestreo

N: Número de Bits por Muestra

Ts Fs (8 KHz)

(N = 8)

KBPS _ PCM = f ( FS , N ) = FS * N 2n = N FS ≥ 2 BW Típico : 64 KBPS

PCM DPCM ADPCM

Voz

Filter/Sample/Hold

Cuantificación

Codificación

Codificación PCM KBPS_IN_Algoritmo Interface

ETH

IPv4

UDP

RTP

Compresión Algoritmo

Empaquetamiento

KBPS_OUT_Algoritmo

KBPS_OUT_Interface PPS_OUT_Interface

11000…11100

11000…11100

Frame N

Frame N+1

• Tamaño del Frame, en MS ó en Bytes: Frame • Tamaño del Payload: PAYLOAD. • Requerimientos de PPS: PPS.

Media Stream

• Factor de Compresión: K. • Retardo Intrínseco: RETARDO.

Factor _ Compresión _ A lg oritmo = K = 1 :

KBPS _ PCM KBPS _ Out _ A lg oritmo 11



Ing. José Cotúa

El Algoritmo de Compresió Compresión IN: KBPS_PCM Típico: 64KBPS

Compresión Algoritmo

El

Procesamiento es Algoritmo/Software/DSP.

OUT: KBPS_Out_Algoritmo Típico: << 64KBPS

COMPLETAMENTE

Digital:

El Algoritmo se Fundamenta en Principios de: Redundancia, Predicción, Percepción, Acondicionamiento, Compromiso, etc. El Procesamiento se hace en Tiempo Discreto; con Herramientas y Técnicas de DSP.


12

6


Ing. José Cotúa

Parametrizació Parametrización del Algoritmo (CODEC) de Muestreo (FS): Número de Muestras tomadas de la Señal de Voz/Audio en la Unidad de Tiempo de 1 Segundo. (Típico: 8KHz)

Frecuencia

Frame: El Procesamiento de la Señal de Voz en realidad se hace por Intervalos de duración Pré-Definidos. Se toman Datos Digitalizados equivalentes para cada Intervalo de Duración. Se denomina Frame la Duración del Intervalo en Milisegundos (ms). También se puede especificar el Frame en Bytes. Frame en Bytes: Bytes: Frame(ms) * FS(KHZ).

13



Ing. José Cotúa

Parametrizació Parametrización del Algoritmo (CODEC) Payload: Número de Bytes de Data de Voz/Audio enviados por cada Paquete RTP/UDP. Se puede Expresar también en ms. K_Frame: K_Frame: Número de Frames por Payload. PPS: Paquetes por Segundo. Número de Paquetes que necesita el Algoritmo enviar en la unidad de tiempo de 1 Segundo para garantizar la reconstrucción de la señal de voz/audio en el receptor. Este parámetro es el que en realidad fija los requerimientos de ancho de banda, a nivel de interface (KBPS UP/DOWN Stream), que necesita el algoritmo. ¡¡ PPS: Requerimiento de Ancho de Banda Real !!.


14

7


Ing. José Cotúa

Parametrizació Parametrización del Algoritmo (CODEC) Delay: Retardo Introducido por el Algoritmo desde que se Muestrea la Señal de Voz hasta que se dispone del ‘Stream Media Audio’ a nivel de UDP. ¡¡ Ojo, recuerde la Bidireccionalidad del Proceso !!. Típico: < 40 ms. Factor de Compresión: KPBS_PCM y KBPS_Algoritmo. Fijo para cada algoritmo en particular. ¡¡ El Sacrificio: La Calidad de la Señ Señal de Voz Recuperada !!

15



Ing. José Cotúa

El Proceso de Empaquetamiento IN: KBPS_Algoritmo Típico: << 64KBPS

RTP

UDP

IPv4

ETH

OUT: KBPS_Out_Interface Típico: < 64KBPS

Empaquetamiento

> 64 KBPS !!

Ahora,

el Stream de Data comprimida por el Algoritmo hay que empaquetarlo y enviarlo a través de la red. Hay tres empaquetamientos: UDP, IP y Enlace (ETH). Los Datos NECESITAN ser transportados a su destino: se pasan al protocolo RTP, luego a UDP (Capa 4: Transporte), este utiliza los protocolos de red disponibles (en este caso IPv4) y finalmente los protocolos de enlace de datos y capa física (Interface) disponibles (Ethernet por Excelencia). Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

16

8


Ing. José Cotúa

El Proceso de Empaquetamiento IN: KBPS_Algoritmo

RTP

Típico: << 64KBPS

UDP

IPv4

ETH


Empaquetamiento

> 64 KBPS !!

En cada capa, los protocolos añaden datos de cabecera ‘Header’ los cuales se constituyen en mas Bits/Bytes que hay que Transmitir: >> Bits por Segundo.

De

esta forma los KBPS_Out_Algoritmo, se convierten en unos KBPS_Out_Interface; el cual es el Ancho de Banda (UP/DOWN Stream) requerido por el algoritmo para UN CANAL de VOZ sobre IP. !! KBPS_Interface >> KBPS_Algoritmo ¡¡ !! Los Protocolos Añ Añaden Control, pero Cobran KBPS ¡¡ 17



Ing. José Cotúa

El Proceso de Empaquetamiento IN: KBPS_Algoritmo Típico: << 64KBPS

RTP

UDP

IPv4

ETH


Empaquetamiento

> 64 KBPS !!

Comúnmente, si no consideramos casos especiales como: Frame Relay (VoFR), ATM (VoATM); se tienen valores como: Cabecera RTP: 12 Bytes. Bytes.

¡¡ Requerimientos de Real Time Protocol… Protocol…

Cabecera UDP: 8 Bytes. Bytes.

¡¡ Requerimientos de Transporte… Transporte…

Cabecera IPv4: 20 Bytes. Bytes.

¡¡ Requerimientos de Red… Red…

Ethernet Capa 2: 26 Bytes. Bytes.

¡¡ Requerimientos de Enlace e Interface… Interface…

De forma que,

Algoritmo de Compresión

Total_Header(RTP+UDP+IPv4+ETH) Total_Header(RTP+UDP+IPv4+ETH) = 66 Bytes. Bytes. Total_Packet_Bytes = Voice_Payload + Total_Header(RTP+UDP+IPv4+ETH) Total_Header(RTP+UDP+IPv4+ETH)

Donde, Voice_Payload= K*Frame(Bytes). Típico: K: 1, 2 ó 3. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

OSI Protocolos

18

9


Ing. José Cotúa

El Proceso de Empaquetamiento IN: KBPS_Algoritmo

RTP

Típico: << 64KBPS

UDP

IPv4

OUT: KBPS_Out_Interface

ETH

Típico: < 64KBPS Empaquetamiento

> 64 KBPS !!

Total_Header(RTP+UDP+IPv4+ETH) = 68 Bytes. Total_Packet_Bytes = Voice_Payload + Total_Header(RTP+UDP+IPv4+ETH) KBPS_Interface = PPS * Total_Packets_Bytes !!!!! ‘ Esta Formula nos da el Verdadero Consumo en KBPS del Algoritmo…’ ‘ Esto SOLO Incluye el Canal Stream de Audio UDP/IP/RTP sobre Etnernet…’ ‘ Recuerde además: Canales SIP, H.323, Control, otros Medios, etc. Ejemplo, para el CODEC G.729: FS: 8KHz, N:8, KBPS_PCM: 64KBPS, FRAME: 10ms (80 bytes), PAYLOAD: 20 bytes (20ms), PPS: 50 Total_Packet_Bytes = 20 + 66 = 86 Bytes, KBPS_Interface = (50PPS) * (86Bytes/Paquete) = 4300Bytes/Seg. KBPS_Interface = (50PPS) * (86Bytes/Paquete) = 34400BPS = 34.4KBPS. 19



Ing. José Cotúa

Protocolo RTP Formato de la Cabecera RTP Bits / Bytes de Información 0

1

V=2

2

3 4 1 Byte

P

X

5

6

7

CC

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte 1 Byte 1 Byte PT

M

Seq Timestamp

Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers

…

Contributing Source (CSRC) Identifiers Multimedia Data

Cabecera de Extensión RTP 0

1

2

3 4 1 Byte

5

6

7

8

9

User Defined

Bits / Bytes de Información 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte 1 Byte 1 Byte Length Header Extension (Longitud Variable)

Cabecera RTP (normalmente): 12 Bytes Payload del CODEC: X Bytes Tamañ Tamaño del Paquete RTP: (12 + X) Bytes Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

20

10


Ing. José Cotúa

Protocolo UDP Formato de la Cabecera UDP 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Puerto Origen (0 - 65535) (SAP-Origen) Puerto Destino (0 - 65535) (SAP Destino) Longitud en Bytes del Datagrama UDP (>=8) Checksum Payload UDP = Paquete RTP

Cabecera UDP: 8 Bytes Paquete RTP: (12 + X) Bytes Tamañ Tamaño del Paquete UDP: (20 + X) Bytes

21



Ing. José Cotúa

Protocolo IPv4 Fo rmato de la Cabec era IPv4 0

1

2

Version

3

4

5

6

7

8

9

IHL (x32 Bits)

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 TOS

Longitud Total de Header y Data (en Bytes)

Identificacion TTL

Indicadores

Protocolo (ICMP=1, TCP, UDP, etc.)

Offset del Segmento Header Checksum (Solo Aplicado a Header IPv4)

IPv4 Origen IPv4 Destino ((Opciones) + (Relleno (Multiplo de 32 Bits))) Payload IPv4 = Paquete UDP

Cabecera IPv4 (normalmente): 20 Bytes Paquete UDP: (20 + X) Bytes Tamañ Tamaño del Paquete IPv4: IPv4: (40 + X) Bytes


22

11


Ing. José Cotúa

Protocolo Ethernet

preámbulo

dirección de destino

dirección de origen

campo de tipo

8 bytes

6 bytes

6 bytes

2 bytes

Formato de la Trama Ethernet Paquete IPv4

frame check sequen ce

de 46 a 1500 bytes

4 bytes

Campos Cabecera Ethernet: Ethernet: 26 Bytes Paquete IPv4: IPv4: (40 + X) Bytes Tamañ Tamaño del Paquete IPv4: IPv4: (66 + X) Bytes Entonces, Ancho de Banda del Algoritmo (Interface (Interface)) = (PPS * (66 + X) * 8) bps

23



Ing. José Cotúa

El Proceso de Empaquetamiento En realidad pareciera que la Compresión en los CODEC’s es necesaria en parte para compensar el ‘Overhead’ de los Protocolos RTP, UDP, IP y ETH.

Hay otras opciones para evitar el efecto del ‘Overhead’. Por ejemplo, existe un Protocolo de RTP Comprimido (cRTP), que Encapsula los Header’s de RTP/UDP/IPv4 en 2-4 Bytes. PERO, NO corre sobre Ethernet; sino sobre enlaces PtP.


24

12


Ing. José Cotúa

El Proceso de Empaquetamiento Para IPv6, hay un ‘Overhead’ adicional; dado que la cabecera IPv6 contiene mas Bytes que la Cabecera IPv4.

En aplicaciones con WiFI, ZigBEE, WiMAX, Pre-WiMAX, Bridge’s-ETH, Redes VPN y otros procesos de encapsulamiento extras; hay un ‘Overhead’ Adicional que hay que considerar y que aumenta el Ancho de Banda Real que consume SOLAMENTE el Codec.

25



Ing. José Cotúa

Tipos de Codec’ Codec’s Existen, al menos, Tres (03) Tipos de Codec’ Codec’s: Algoritmos de Forma de Onda (Codec (Codec’’s) Algoritmos de Paramé Paramétricos (Vocodec’ Vocodec’s) Algoritmos Pará Parámetricos de Aná Análisis y Sistesis en en TX


26

13


Ing. José Cotúa

Tipos de Codec’ Codec’s Algoritmos de Forma de Onda La codificación de la señal de voz/audio se basa directamente en los valores provenientes del proceso de filtrado, muestreo y retención.

La reproducción se basa en el cumplimiento del Teorema de Nyquist. Complejidad reducida Procesos PCM y ADPCM. Son los que mas consumen ancho de banda. No usan criterios de compresión perceptual ni de modelamiento de la voz humana. ITU G.711a/u y G.726. Fuerte impacto en la calidad de voz en pérdida de paquetes y de ancho de banda.

27



Ing. José Cotúa

Tipos de Codec’ Codec’s Utiliza

Algoritmos de Fuente Vocal

modelo del tracto vocal y utiliza las características de la voz humana y de percepción. Se basan en modelos matemáticos complejos de la generación de la voz humana.

Lo que se transmite al receptor son parámetros de filtros digitales (coeficientes) que permiten reconstruir la señal de voz/audio. Permiten optimizar y reducir el uso de ancho de banda. Requieren DSP y niveles importantes de procesamiento Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

28

14


Ing. José Cotúa

El Proceso de Compresió Compresión Procesamiento Digital de la Señ Señal de Voz/Audio La Señ Señal de Voz/Audio

11000…11100

11000…11100

Frame N+1

Frame N

Aná Análisis Ruido Blanco

Filtro Digital

Tren de Pulsos

+ -

+

Error

Switch

Síntesis Filtro Digital: ‘Set de Coeficientes’ Coeficientes’ 29



Ing. José Cotúa

Tipos de Codificació Codificación Con respecto a la Codificació Codificación, se usan los siguientes esquemas: 1) Codificació Codificación PCM. 2) Codificació Codificación DPCM. 3) Codificació Codificación ADPCM. 4) Codificació Codificación CELP. 5) Codificació Codificación CSCS-ACELP. Codificació Codificación PCM Se codifica cada muestra de la señal de voz/audio con M bits (generalmente M = 8). Es el esquema de codificación que mas requiere ancho de banda. De hecho, para esta codicicación no hay compresión. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

30

15


Ing. José Cotúa

Tipos de Codificació Codificación Con respecto a la Codificació Codificación, se usan los siguientes esquemas: 1) Codificació Codificación PCM. 2) Codificació Codificación DPCM. 3) Codificació Codificación ADPCM. 4) Codificació Codificación CELP. 5) Codificació Codificación CSCS-ACELP. Codificació Codificación DPCM Se aprovecha Nyquist y la Correlación de

Muestras Adjuntas y se Muestrea siempre la diferencia de una Muestra con la anterior. No se obtienen ahorros significativos de Ancho de Banda. 31



Ing. José Cotúa

Tipos de Codificació Codificación Con respecto a la Codificació Codificación, se usan los siguientes esquemas: 1) Codificació Codificación PCM. 2) Codificació Codificación DPCM. 3) Codificació Codificación ADPCM. 4) Codificació Codificación CELP. 5) Codificació Codificación CSCS-ACELP. Codificació Codificación ADPCM Se codifica es la Diferencia entre la Muestra Original y la Predicción de esta; es decir, el Error de la Predicción.

Con un buen predictor, basado en la Correlación de Muestras cercanas, se pueden lograr ahorros significativos de Ancho de Banda. Se pueden obtener Tasas de 32KBPS (G.721 y G.726) y entre 24 y 40KBPS (G.723). Poco robusto ante pérdida de paquetes; pués está basado en Predicción. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

32

16


Ing. José Cotúa

Tipos de Codificació Codificación Con respecto a la Codificació Codificación, se usan los siguientes esquemas: 1) Codificació Codificación PCM. 2) Codificació Codificación DPCM. 3) Codificació Codificación ADPCM. 4) Codificació Codificación CELP. 5) Codificació Codificación CSCS-ACELP. Codificació Codificación CELP (Predicció (Predicción Lineal con Excitació Excitación de Có Códigos) Es una forma híbrida de codificación que usa codificación por forma de onda y

codificación de fuente vocal. Tratando de explotar las ventajas de ambas técnicas de codificación. Se obtienen Anchos de Banda entre 4.8 y 16KBPS. Lo que se transmite al receptor son códigos asociados a filtros digitales que mejor reproducen la señal original. 33



Ing. José Cotúa

Tipos de Codificació Codificación Con respecto a la Codificació Codificación, se usan los siguientes esquemas: 1) Codificació Codificación PCM. 2) Codificació Codificación DPCM. 3) Codificació Codificación ADPCM. 4) Codificació Codificación CELP. 5) Codificació Codificación CSCS-ACELP y LDLD-CELP. Predicció Predicción por Excitació Excitación Lineal de Có Código Algebraico de Estructura Conjugada (CS(CS-ACELP) Es la Codificación que usa ITU G.729. G.729 usa 8KBPS (en Algoritmo). Utiliza muestras de 10ms y Payload’s de 20 Bytes @ 50PPS. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

34

17


Ing. José Cotúa

Compromiso entre el Ancho de Banda y la Calidad de la Voz

35



Ing. José Cotúa

Medida Subjetiva de la Calidad de Voz Media Opinió Opinión Scope (Mé (Método MOS) Es un método subjetivo, basado en opiniones expertas de personan que escuchan una señal de voz/audio procesada y recuperada, que se utiliza para medir la Calidad de la Voz/audio en sesiones de VoIP. De una manera subjetiva y empírica se mide la calidad de una señal de voz/audio en una sesión de VoIP, dado un Codec específico utilizado en la sesión. La medición se hace consultando la opinión de personas que escuchan muestran de la voz/audio y los resustados se registran en una escala de 1 a 5. El MOS es el resultado de una prueba de escala de categoría absoluta, ACR (Absolutly Categorie Rate). La prueba consiste en una serie de personas que escuchan un conjunto de muestras de voz/audio pregrabadas con diversos escenarios de algoritmos de compresión.


36

18


Ing. José Cotúa

Medida Subjetiva de la Calidad de Voz Medida del MOS 5 Excelente 4 Buena

Respuesta y Esfuerzo Relajación completa, no requiere esfuerzo

3

Media

Se requiere un primer nivel de esfuerzo moderado

2 1

Pobre Mala

Se requiere esfuerzo adicional considerable

Atención necesaria, muy poco esfuerzo

No se entiende nada

37



Ing. José Cotúa

Los CODEC’s de VoIP mas Utilizados


38

19


Ing. José Cotúa

Codec ITUITU-T G.711 G.711a y G.711u Frecuencia de Muestreo de 8KHz ± 50ppm; @ 8 Bits por Muestra. El Algoritmo NO Comprime y requiere un Ancho de Banda de 64KBPS. Se utilizan Leyes de Codificación PCM Ley µ (G.711µ) y PCM Ley A (G.711a). Procesa Frame’s de 10ms (80 Muestras/Bytes @ 8000Muestras/seg). Utiliza un Payload de 160 Muestras/Bytes (20ms) y requiere de 50PPS. Es el que consume mas ancho de Banda y tiene la Mejor Calidad de Voz (MOS = 4.1). Ancho de Banda Real = 90.4 KBPS (RTP+UDP+IPv4+ETH). Soporte nativo en TODAS las Aplicaciones y Protocolos de VoIP. 39



Ing. José Cotúa

Codec ITUITU-T G.729 Codec de Voz a 8kbps mediante Predicció Predicción Lineal con Excitació Excitación por Có Código Algebraico de Estructura Conjugada (CS(CS-ACELP) Recibe PCM de G.711, convertido a PCM de 16 bits por Muestra. Procesa Frame’s de 10ms (80 Muestras/Bytes @ 8000 Muestras/seg). Por cada Frame genera 10 Bytes comprimidos. Utiliza un Payload de 20 Bytes (equivalentes a 20ms de audio comprimido); y requiere 50 PPS. Es uno de los de Mejor Calidad de Voz luego de G.711, MOS = 3.92. Pero, requiere un nivel importante de procesamiento. Ancho de Banda Real = 34.4KBPS (RTP+UDP+IPv4+ETH). Ya viene incluido el soporte nativo de G.729 en la mayoría de los Sistemas de VoIP. Sin embargo, para algunos fabricantes y arquitecturas podría requerirse instalación y compilación especializada. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

40

20


Ing. José Cotúa

Codec ITUITU-T G.723.1 Codec de Voz de Doble Velocidad para la Transmisió Transmisión en Comunicaciones Multimedia a 5.3 y 6.3 kbps (MP(MP-MLQ) Recibe PCM de G.711, convertido a PCM de 16 bits por Muestra. Procesa Frame’s de 30ms (240 Muestras/Bytes @ 8000 Muestras/seg). Se incluye un sub-frame de pré-análisis de 7.5ms; por lo que el retardo intrínseco de este Codec es de al menos 37.5ms. Puede operar en dos velocidades, 5.3kbps y 6.3kbps, la de 6.3kbps tiene mejor calidad de voz. Calidad de Voz Aceptable (Buena), MOS = 3.9. Es posible Conmutar entre las Velocidades en las Fronteras de Trama; logrando veocidades entre 5.3kbps y 6.3kbps. Utiliza codificación predictiva lineal de análisis por síntesis. Para G.723.1 @ 5.3kbps MOS = 3.8, Payload = 20 Bytes @ 34 PPS (23.4kbps) Para G.723.1 @ 6.3kbps MOS = 3.9, Payload = 24 Bytes @ 34 PPS (24.4kbps) Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF


41

Ing. José Cotúa

Otros Codec’ Codec’s de VoIP ITUITU-T: G.726 (24kbps), G.726 (32kbps), G.728, entre otros. iLBC (internet Low Bitrate Codec) Codec): creado originalmente por Global IP Sound; pero actualmente es de Código Libre FREE (http http:// ://www.ilbcfreeware.org www.ilbcfreeware.org/). Puede trabajar con Frames de 20ms (iLBC de 13.33kbps, payload de 50 bytes) y de 30ms (iLBC de 15.2kbps, payload de 38 bytes). Está especialmente ideado para ambientes de Internet; muy robusto ante Pérdida de Paquetes. Complejidad Computacional no despreciable. La IETF ya ha aprobado la estandarización de este Codec. LPC10 (Linear Predictive Coding with 10 Predicment Coefficients Calculations) Calculations): Usado en condiciones de bajo Ancho de Banda disponible. La Voz se escucha Robotizada; pero se entiende.


42

21


Ing. José Cotúa

Otros Codec’ Codec’s de VoIP SPEEX (http ://www.speex.org www.speex.org//): Codec Open Open Source/Free Software, (http:// parte del Proyecto GNU. Consume mucho recurso de procesamiento, mas que G.726, G.729 y GSM. El Frame y el Payload es Configurable. Creado para Speech. Hay dos versiones_ Speex-NB y Speex-WB. Comúnmente, Anchos de Banda de 8, 16 y 32kbps. Pero, se pueden Configurar Anchos de Banda desde 2.15 hasta 44.2kbps GSM: GSM Estándar ETSI. Es el Codec utilizado en Telefonía Celular GSM. Trabaja con Frames de 22.5ms y su Ancho de Banda es de 13kbps. Otros Codec’ Codec’s usados en VoIP: VoIP Siren (muy poca información), DVI4 (ADPCM), GIPS, DoD CELP, etc.



43

Ing. José Cotúa

¿Cuá Cuál Codec de VoIP utilizar? Resp. Resp. Depende. Si

el Ancho de Banda no es Limitado; puede ser que no sea necesario utilizar un Codec distinto a G.711. En ambientes de Internet: G.729, GSM y iLBC funcionan bastante bien. iLBC es muy bueno para condiciones de Pérdida de Paquetes. Hay que considerar compatibilidad, requerimientos de procesamiento, requerimientos de traducción de codec’s, calidad de voz mínima aceptable (MOS), etc. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

44

22


Ing. José Cotúa

¿Cuá Cuál Codec de VoIP utilizar? Resp. Resp. Depende. Si hay ‘Codec Translator’; se introduce un Retardo Adicional; ademán de la sobrecarga de procesamiento. Lo mas recomendable, siempre y cuando se pueda, es que el Codec sea uniforme en toda la solución de VoIP.

Si las condiciones de Ancho de Banda son críticas, piense en usar LPC10. Si la solución de VoIP está con otras soluciones como VPN, WiFI, WiMAX, Pre-WiMAX, Bridge’s, Protocolos de Encapsulamiento, etc. Piense en usar Codec’s con Poco Payload. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF


45

Ing. José Cotúa

¿Cuá Cuál Codec de VoIP utilizar? Resp. Resp. Depende. Si

su solución de VoIP está basada en GNU/Linux; piense en que Speex puede ser completamente compatible y configurable; adaptándolo a sus requerimientos. En todo caso; siempre que sea posible trate siempre de usar un solo Codec en su Plataforma de VoIP. Haga Pruebas…!!! Monitoree la Tecnología: Cada vez hay nuevos y mejores Codec’s. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

46

23


Ing. José Cotúa

Conclusiones y Comentarios Los procesos claves de un Codec de VoIP son: a) Conversión de

Analógica a Digital, b) Compresión y c) Encriptamiento.

No hay una relación lineal entre el ancho de banda requerido por un codec y la calidad de voz percibida; se asocian conceptos complejos como ‘compresión perceptual’. Se puede comprimir y usar menor ancho de banda y mantener significativamente la calidad de la voz, el precio: costo en procesamiento y algoritmos complejos. La escogencia del es un balance entre Calidad, Costo y desempeño de la Red IP. Hay Tres Tipos de Codec’s: a) Algoritmos de Forma de Onda (PCM y ADPCM), b) Algoritmos de Fuente (Vocoder’s), y c) Híbridos. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF


47

Ing. José Cotúa

Conclusiones y Comentarios La

frecuencia de Muestreo de la Voz/audio y los Bits por Muestra tienen un Impacto tremendo en el Ancho de Banda Requerido por el Codec. Si FS = 8KHz (TS = 125us) , @8 Bits por Muestra 64000 Bits/Seg = 64KBPS. Fmax = 4KHz, Nyquist FSMin = 8KHz.


48

24


Ing. José Cotúa

Conclusiones y Comentarios El capítulo de los Codec’s en VoIP todavía está abierto y en estudio. El desafío es fuerte. Actualmente, se está investigando con nuevas técnicas de análisis y procesamiento inspiradas en nuevos paradigmas como: inteligencia artificial, transformada ondícula, codificación perceptual, etc.

Los Codec’s pueden estar acompañados de soluciones adicionales como: FAX, Cancelación/Supresión de Eco, VAD (Voice Activity Detection). Estas opciones son generalmente configurable por ‘Umbrales’; hay que ser cuidadosos con estas configuraciones porque introducen procesamiento adicional y pueden causar la impresión de que el sistema no funcione adecuadamente. 49



Ing. José Cotúa

Comentarios Finales Nuevos Paradigmas y Desafíos: Inteligencia Artificial, Compresión en Dominio Frecuencial, Transformada Ondícula, etc. En GNU/Linux: Un Codec Un Archivo *.so (Librería) Codificación Redundante ante Escenarios de Alta Pérdida de paquetes. Codec’s para Audio Mayor FS. En Redes de muy Alta Velocidad (Paradigma Ancho de Banda Infinito!!); piense: ¿Realmente, se necesita un Codec?. Pruebe, Mida y Cambie de ser Necesario…!!! Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

50

25


Ing. José Cotúa

Transport Protocol for RealReal-Time Applications Protocolo RTP Estándar de la IETF Documento RFC1889 (Jun 1996)

51



Ing. José Cotúa

Descripció Descripción General de RTP RTP

es el protocolo que da soporte al transporte end-toend de data multimedia en tiempo real, como: voz, audio ó video. Para ello, RTP puede utilizar los servicios de red de tráfico Unicast ó Multicast.

RTP no incluye funciones de garantía de calidad de servicio (QoS), entrega fiable, ni de reserva de recursos para el tráfico de multimedia en tiempo real. RTP confía en que los protocolos ‘underlaying’ se ocuparán de estos aspectos.


52

26


Ing. José Cotúa

Descripció Descripción General de RTP El transporte de data en RTP está soportado por un protocolo adicional de control, llamado RTCP (Real Time Control Protocol), el cual permite supervisar la entrega de la data, unicast ó multicast, y proveer funciones de identificación y control de tráfico multimedia. RTP y RTCP son protocolos independientes de los protocolos de transporte (TCP/UDP) y de los protocolos de red (IPv4/IPv6).

53



Ing. José Cotúa

Descripció Descripción General de RTP RTP y RTCP se definen dentro del mismo estándar. Por defecto usa UDP, el cual soporta multiplexación de procesos y detección de error (checksum). RTP está pensado para transporte de data multimedia en aplicaciones con necesidades de tiempo real. Pensado especialmente para ser transportado por UDP e IP.


54

27


Ing. José Cotúa

Descripció Descripción General de RTP RTP

no dispone de soporte para garantías de:

Entrega efectiva (delivery). Entrega a tiempo (timely delivery). Calidad de servicio (quality-of-service). Entrega en orden (in order delivery); sin embargo, se dispone de soporte para reconstrucción temporal del ‘streaming’ (a través del uso de números de secuencia).

55



Ing. José Cotúa

Servicios Soportados por RTP Identificación

de

tipo

de

contenido

(payload

type

identification).

Secuenciamiento (sequence numbering and timestamping). Supervisión de entrega de la data multimedia (monitoring). RTP soporta transferencia de data multimedia a multiples destinos, vía multicast; el cual es un servicio que es soportado por los protocolos de red IPv4 ó IPv6.


56

28


Ing. José Cotúa

Aplicació Aplicación de RTP: Conferencia de Audio Multicast RTP se soporta en los servicios de IP Multicast para permitir distribuir información de audio en conferencia.

El protocolo IP dispone de direcciones IP especialmente asignadas, por la IANA, para el tráfico multicast. Se crean y referencian grupos de recepción de audio multicast. Un canal para el audio y un canal para el RTCP. Puede o no usarse encriptamiento. Se empaqueta la voz/audio en tramas de 20ms y se emplean esquemas de codificación PCM, ADPCM ó LPC.

57



Ing. José Cotúa

Aplicació Aplicación de RTP: Conferencia de Audio y Video Multicast Un

par de canales RTP y RTCP para cada tipo de media.

Se utiliza una dirección IP multicast para cada tipo de media. No hay acople entre los canales de ‘streaming’ de voz/audio y video. Se maneja cada canal para cada tipo de media, en forma independiente. Todos los destinatarios reciben cada canal de media, en el mismo formato de codificación.


58

29


Ing. José Cotúa

Aplicació Aplicación de RTP: Mixers and Translators Útil cuando se quiere desplegar data multimedia, vía multicast, en diferentes formatos de codificación. Por ejemplo, en redes IP con capacidades no uniformes de ancho de banda. Esto es, algunos enlaces con baja capacidad de tasa de bits y otros con alta capacidad de tasa de bits. RTP-Level Relay (Mixer): sincroniza envío de data multimedia a través de múltiples enlaces con diferentes capacidades de tasas de bits; ó enviando la misma data multimedia con distintos formatos de codificación a través de múltiples enlaces con distintas capacidades de tasas de bits.

59



Ing. José Cotúa

RTP y los Protocolos de Transporte y de Red que Utiliza RTP usa, y lo necesita, del soporte de multiplexación de flujos de data multimedia y de flujo de ‘streming’ de control RTCP. Para UDP, y para protocolos de transporte simulares a UDP, RTP usa puertos pares para el flujo de data multimedia; y el correspondiente RTCP stream usa el próximo puerto superior impar. Los paquetes RTP, eviados comúnmente sobre UDP/IPv4, no contienen un campo que especifique su longitud. La longitud se calcula a partir de los protocolos ‘underlaying’. De hecho, la máxima longitud de un paquete RTP es limitado justamente por las capacidades máximas de ‘payload’ de los protocolos ‘underlaying’. RTP puede, incluso, transportar data multimedia sobre redes no basadas en conmutación de paquetes. En estos casos, RTP requiere un método adicional (no definido dentro del estándar) para el ‘framing’ o encapsulamiento de la data RTP. Hay que recordar, que RTP está pensado para transporte de data multimedia sobre redes basadas en conmutación de paquetes. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

60

30

VoIP y Telefonía IP Supervició Supervición

Multimedia

Control

Streaming

RTCP

Señ Señalizació alización

Megaco

RTP

UDP / UDP Lite

Ing. José Cotúa

SIP

H.323

TCP / SCTP

IGMP

ICMPv4 IPv4

ICMPv6

IPv6

ARP

RARP

Ethernet / IEEE 802.3, 802.1Q, 802.1P Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF


61

Ing. José Cotúa

Definiciones en RTP y RTCP RTP Payload (Carga (Carga Útil RTP): RTP) data multimedia transportada dentro de un paquete RTP. Por ejemplo, muestras de audio, voz o video comprimido. Su formato o interpretación no está definido dentro del estándar RTP. RTP Packet (Paquete (Paquete RTP): RTP) entidad RTP contentiva de una Cabecera RTP (de longitud fija) y una Data Payload. RTCP packet (Paquete RTCP): RTCP) entidad RTCP contentiva de una Cabecera RTCP, seguida de una serie de elementos estructurales del paquete RTCP; que dependen del tipo de paquete RTCP. RTCP no transporta payload. Varios paquetes RTCP pueden ser transportados dentro de un mismo paquete UDP. La cabecera RTCP si dispone de un especificador de longitud del paquete RTCP. Esto no sucede en RTP. Port (Puerto): (Puerto) Puerto UDP/TCP asociado en la capa de transporte. RTP Session (Sesi ón RTP): (Sesió RTP) Conexión a nivel de transporte entre dos entidades, que se comunican a través de UDP/TCP. La sesión RTP queda identificada por el Socket UDP/TCP establecido a nivel de la capa 4 (Capa de transporte). En sesiones RTP, cada Media es transmitido con un canal RTP propio; con su respectivo canal RTCP cada uno. RTP session Multiple Streams Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

62

31


Ing. José Cotúa

Definiciones en RTP y RTCP Source (SSRC): Identificador de 32 Bits (4 Octetos) que identifica la fuente de los ‘stream RTP packets’. Este identificador es parte de la cabecera RTP. Es independiente del Identificador de Red (Dirección IP) utilizado a nivel 3. Este identificador referencia paquetes con el mismo timing y secuenciamiento. Se escoge aleatoriamente. Es único para una sesión RTP. Los receptores agrupan los paquetes por SSRC para reproducir la información.

Synchronization



63

Ing. José Cotúa

Definiciones en RTP y RTCP Contributing Source (CSRC): Fuente de un flujo de paquetes RTP que ha contribuido al flujo combinado producido por un mezclador. El mezclador incluye la lista de identificadores SSRC. Esta lista es llamada CSRC. Por ejemplo, en una Conferencia de Audio; el mezclador indica todos los hablantes, permitiendo al receptor referenciar al actual hablante, aunque todos los paquetes de audio tengan el mismo SSRC. CSRC Lista de Identificadores SSRC que dan origen a un flujo combinado, producido por un mezclador. End System (Sistema Final): Final) Aplicación asociada al tráfico de data multimedia. La que origina y/o recibe los datos RTP. Mixer (Mezclador): (Mezclador) Sistema intermedio que recibe paquetes RTP, de una o mas fuentes, y que posiblemente cambia los formatos de la data RTP, y combina estos dando como resultado un solo y nuevo paquete RTP. Dado que no hay sincronización entre las diferentes fuentes de paquetes RTP; el Mixer debe ajustar esta sincronización origen dispersa en una única sincronización del trafico resultante combinado. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

64

32


Ing. José Cotúa

Definiciones en RTP y RTCP Translator (Traductor): Sistema intermedio que reenvío paquetes RTP sin alterar la fuente de sincronización. Por ejemplo: traductores de codificación sin Mezclado, replicadores de multicast a unicast, enrutadores, filtros y firewalls. Monitor: Monitor Sistema que recibe paquetes desde los participantes de una sesión RTP. El objetivo, es hacer reportes de desempeño, estimados de calidad de servicio, supervisión de entregas, debug’s, diagnosticos de falla, estadísticas. Puede ser o no parte de la sesión. Protocolos NoNo-RTP: RTP En una sesión multimedia concurren una serie de protocolos de señalización, de calidad de servicio, de encriptamiento, de control de conferencia, de enrutamiento, y por supuesto de streaming.

65



Ing. José Cotúa

Formatos, Alineació Alineación y Tiempos Para nú números enteros, se utiliza el formato ‘bigbig-endian’ endian’: Bytes, MSB LSB. Para las constantes decimales, se utiliza el sistema decimal (Base (Base 10). Sistema de numeració numeración de octetos: comienzo en ‘0’. Formato y Estructura de un Paquete RTP Bits / Bytes de Información 0

1

2

3

4

5

6

7

8

1 Byte V=2

P

X

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

CC

M

1 Byte

PT

1 Byte Seq

Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers

… Contributing Source (CSRC) Identifiers Multimedia Data


66

33


Ing. José Cotúa

Formato y Estructura de un Paquete RTP Bits / Bytes de Información 0

1

2

3

4

5

6

7

8

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

1 Byte V=2

P

1 Byte CC

X

1 Byte

PT

M

1 Byte Seq



V, Versió Versión (2 bits): bits) especifica la versión del protocolo RTP implementado. Actualmente, se utiliza la versión 2 (10B). P, Padding (1 bit) bit): bit de relleno. Si P=1, indica que el paquete contiene uno o mas octetos de relleno; los cuales deberían ser ignorados. Se utilizan bits de relleno cuando, por ejemplo, se emplean algoritmos de encriptamiento que utilizan tamaños de bloques fijos. 67



Ing. José Cotúa


1

2

3

4

5

6

7

8

9

1 Byte V=2

P

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

CC

X

1 Byte

PT

M

1 Byte Seq



X, Extension (1 bit) bit): bit de extensión. Si E=1, indica que luego de la cabecera RTP se incluye una cabecera de extensión con el siguiente formato: Cabecera de Extensión RTP 0

1

2

3 4 1 Byte

5

6

7

8

9

User Defined

Bits / Bytes de Información 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte 1 Byte 1 Byte Length Header Extension (Longitud Variable)


68

34


Ing. José Cotúa


1

2

3

4

5

6

7

8

9

1 Byte V=2

P

1 Byte CC

X

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

PT

M

1 Byte Seq



CC, CSRC Count (4 bits): bits) especifica el número de identificadores CSRC. M, Marker (1 bit) bit): marcador especial del paquete RTP. Su significado lo asigna el usuario. Por ejemplo, se puede activar este marcador para ‘frame boundaries’, ó para asociar eventos al tráfico de ‘streaming’.

69



Ing. José Cotúa


1

2

3

4

5

6

7

8

1 Byte V=2

P

X

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

CC

M

1 Byte

PT

1 Byte Seq



PT, Payload Type (7 bits): bits) identifica el formato del payload RTP. Los que no estén definidos, se referencian vía Non-RTP Protocols y tienen el valor de ‘unassigned’.


70

35


Ing. José Cotúa

Formato y Estructura de un Paquete RTP PT, Payload Type (7 bits): bits) identifica el formato del payload RTP. PT Payload PT Payload 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

PCMU audio 1016 audio G721 audio GSM audio Unassigned audio DV14 audio(8Khz) DV14 audio(16Khz) LPC audio PCMA audio G722 audio L16 audio(stereo) L16 audio(mono) TPS0 audio VSC audio MPA audio G728 audio

16-22 23 24 25 26 27 28 29 30 31 32 33 34-71 72-76 77-95 96-127

unassigned audio RGB8 video HDCC video CelB video JPEG video CUSM video nv video PicW video CPV video H261 video MPV video MP2T video unassigned video reserved unassigned dynamic 71



Ing. José Cotúa


1

2

3

4

5

6

7

8

1 Byte V=2

P

X

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

CC

M

1 Byte

PT

1 Byte Seq



Seq, Seq, Sequence Number (16 bits): bits) se incrementa en ‘1’ por cada paquete RTP enviado. Lo utiliza el receptor para determinar las estadísticas de pérdida de paquetes y/o la reconstrucción temporal de paquetes. El número inicial de la secuencia se asigna aleatoriamente. aleatoriamente


72

36


Ing. José Cotúa


1

2

3

4

5

6

7

8

9

1 Byte V=2

P

1 Byte CC

X

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

PT

M

1 Byte Seq



Timestamp, Timestamp, Marcador de Tiempo (32 bits): bits) especifica de manera precisa el instante de tiempo en que fue muestreado el primer octeto de la Data RTP contenida en el payload. Al igual que Seq, el valor inicial de Timestamp se especifica aleatoriamente. aleatoriamente Puede estar asociado al clock del sistema ó al clock del muestreo de la señal de media (voz, audio ó video).

73



Ing. José Cotúa


1

2

3

4

5

6

7

8

1 Byte V=2

P

X

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

CC

M

1 Byte

PT

1 Byte Seq



SSRC, Sinchronization Source (32 bits): bits) identifica la fuente de sincronización. Este identificador se establece aleatoriamente, aleatoriamente bajo la premisa de que dos o mas fuentes de sincronización, dentro de una misma sesión RTP, no tengan el mismo valor (en cuyo caso ocurriría lo que se conoce como ‘SSRC collision’; y el algoritmo debe ser capaz de detectar si esto sucede). El mismo protocolo especifica mecanismos y algoritmos de generación de números aleatorios. Nuevas asignaciones de transporte a nivel 4 (cambio de puerto); debería implicar asignar un nuevo SSRC. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

74

37


Ing. José Cotúa


1

2

3

4

5

6

7

8

1 Byte V=2

P

X

9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 Byte

CC

M

1 Byte

PT

1 Byte Seq



CSRC, Contributing Source (0 to 15 items, items, 32 bits c/u): c/u) lista de SSRC que identifica a las distintas fuentes que han contribuido en la data contenida en el payload RTP. El número de contribuyentes se especifica en el campo CC. Pueden haber mas de 15 contribuyentes; pero solo 15 pueden ser identificados. ¡¡¡ MIXER !!!



75

Ing. José Cotúa

Multiplexado de Sesiones RTP Para un procesamiento eficiente del protocolo RTP; el número de puntos de multiplexación debería ser minimizado. La multiplexación de canales RTP se define con el soporte de los protocolos de transporte (UDP/TCP) y de red (IPv4/IPv6). Por ejemplo, en una videoconferencia conmpuesta con audio y video codificados por separado, cada media (el audio y el video) debería ser transportada en una sesión RTP (cada una con su propia asignación de direcciones a nivel 4). RTP no está ideado para que audio y video sean transportados dentro de una misma sesión RTP; y demultiplexadas en el receptor basándose el el Tipo de Media contenida en el payload; ó por el valor del campo SSRC. Se utiliza un identificador SSRC para cada tipo de media que se desea transmitir.


76

38


Ing. José Cotúa

RTP Control Protocol (RTCP) Se fundamenta en el envío periódico de paquetes de control a todos los participantes de una sesión RTP; utilizando el mismo mecanismo de distribución utilizado para los paquetes de streaming RTP. Se utiliza un canal separado para estos paquetes de control; un canal distinto al de cada canal RTP de la sesión (se utiliza otro puerto UDP).

RTCP RTP Señ Señalizació alización

¡¡ RTCP está está pensado para trabajar en conjunto con RTP !! Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF


77

Ing. José Cotúa

Funciones de RTCP Obtener información acerca de la Calidad de Entrega de los Datos (feedback on the quality of the data distribution) en la distribución de contenido multimedia en la sesión. Útil para protocolos de codificación adaptativa, en tráfico Unicast. Monitorizació Monitorización de la QoS y control de congestió congestión (SR (SR y RR) RR) Transmitir unos identificadores asociados a las fuentes RTP, identificadores conocidos como CNAME (Canonical Name), com o una identificación antelnativa al SSRC; por si este varía. Identificació ). Identificación de Fuente (SDES (SDES). Obtener información acerca del número de participantes de una sesión y recalcular dinámicamente la tasa de envío de paquetes RTCP. Sincronizació Sincronización InterInter-Media. Control de los participantes dentro de una sesión. Escalado de la informació información de control. Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

78

39


Ing. José Cotúa

Tipos de Paquetes RTCP SR, Sender Report. Report.

0 V P

31 RC

PT=200 (SR)

Longitud

Sender NTP Timestamp (MSW) NTP Timestamp (ISW) RTP Timestamp Contador de Paquetes del Emisor Contador de Octetos del Emisor SSRC 1 … datos adicionales RR … SSRC n … datos adicionales RR … 79



Ing. José Cotúa

Tipos de Paquetes RTCP SR, Sender Report. Report.

0 V P

31 RC

PT=200 (SR)

Longitud

Sender NTP Timestamp (MSW) NTP Timestamp (ISW) RTP Timestamp Contador de Paquetes del Emisor Contador de Octetos del Emisor SSRC 1 … datos adicionales RR … SSRC n … datos adicionales RR … Capitulo 03: Codec’s de VoIP, RTP/RTCP y Señalización DTMF

80

40


Ing. José Cotúa

Tipos de Paquetes RTCP SR, Receiver Report. Report.

31

0 V P

RC

Longitud

PT=201 (RR)

SSRC Lost fraction

Paquetes perdidos

Número de secuencia recibido más alto Jitter entre llegadas Último SR TimeStamp (LSR) Retardo desde último SR (DLSR)



81

Ing. José Cotúa

Tipos de Paquetes RTCP Otros Paquetes RTCP. • SDES Source Description RTCP Packet CNAME, NAME, E-MAIL, PHONE, LOC. • BYE Indica que una o más fuentes dejan de estar activas • APP Paquetes específicos de aplicaciones • Algunos no se utilizan en H.323


82

41


Ing. José G. Cotúa

Protocolo de Señalización ITU-T H.323 Ing. José G. Cotúa, Agosto 2007

Capítulo IV – La Suite de Protocolos ITU-T H.323



ITU – La Unión Internacional de Telecomunicaciones La ITU es el Organismo de las Naciones Unidas

para el campo de las Telecomunicaciones a nivel mundial (http://www.itu.int/)

Está constituida por Tres (03) sectores: a) Sector de Normalizació Normalización (ITU(ITU-T) b) Sector de Radiocomunicaciones (ITU(ITU-R) c) Sector de Desarrollo de las Telecomunicaciones (ITU(ITU-D) Capítulo IV – La Suite de Protocolos ITU-T H.323

1



ITU-T – Sector de Normalización de la Unión Internacional de Telecomunicaciones ITU-T es un órgano permanente de la ITU que estudia los aspectos técnicos, de explotación y tarifarios de las telecomunicaciones y publica Recomendaciones sobre los mismos con miras a la normalización de las telecomunicaciones a nivel mundial.

La




Protocolo H.323 ITU-T H.323 Recomendación Nro. 323 de la Serie H (Sistemas Audiovisuales y Multimedios) de las recomendaciones del sector de estandarización y normalización de la ITU (ITU-T), denominada: “ Sistemas de Comunicació Comunicación Multimedios basados en Paquetes ”


2



Protocolo H.323 Serie H, de las Recomendaciones ITU-T “ Sistemas Audiovisuales y Multimedios ” Infraestructura de los servicios audiovisuales, sistemas y equipos terminales para los servicios audiovisuales




Versiones de ITU-T H.323 Rec. ITU-T H.323, Nov-1996 (H.323v1) Rec. ITU-T H.323, Feb-1998 (H.323v2) Rec. ITU-T H.323, Sep-1999 (H.323v3) Rec. ITU-T H.323, Jul-2003 (H.323v4)


3



Ámbito de la Rec ITU-T H.323 La

Rec ITU-T H.323 describe terminales y otras entidades H.323 que proporcionan servicios de comunicaciones multimedios, voz, video y data, a través de redes de conmutación de paquetes (PBN, Packet Based Network) que pueden no proporcionar una calidad de servicio garantizada.




Redes de Conmutación de Paquetes Redes PBN LAN/WAN/MAN

IEEE 802.15 Token Ring ATM, Frame Relay IPv4/IPv6 sobre Ethernet 10/100/1000/10000BaseTX

(IEEE

802.3)


4



Entidades H.323 PE, Punto Extremo H.323 GW, Gateway H.323 GK, Gatekeeper H.323 MC, Controlador Multipunto MP, Procesador Multipunto MCU, Unidad de Control Multipunto




H.323: Una Suite de Protocolos Rec ITU-T H.225.0 (2003): “Protocolos de señalización de llamadas y paquetización de trenes de medios para sistemas de comunicaciones multimedios basados en paquetes” Rec ITU-T H.245 (2003): “Protocolo de control para comunicaciones multimedios” Codec’s de Audio: G.711 (1988), G.722 (1988), G.723.1 (1996), G.728 (1992), G.729 (1996), etc. Codec’s de Video: H.261(1993), H.263 (1998), H.264 (2003), etc. Datos en Multimedia: T.120 (1996). Otros: Q.931 (1998), Q.932 (1998), E.164 (1997), etc.


5



Rec H.323 - Definiciones Llamada: Comunicación multimedios entre dos puntos extremos H.323. La

llamada empieza con el procedimiento de establecimiento de la comunicació comunicación y termina con el procedimiento de terminació terminación de la llamada. La llamada está formada por el conjunto de canales fiables (TCP) y no fiables (UDP) entre los puntos extremos. Una llamada puede producirse directamente entre dos puntos extremos o puede implicar a otras entidades H.323 tales como un controlador de acceso o un MC. En caso de interfuncionamiento con algunos puntos extremos de redes con conmutación de circuitos (RCC) a través de una pasarela, todos los canales terminan en la pasarela donde se convierten en la representación apropiada para el sistema de extremo de la RCC. Normalmente una llamada se efectúa entre dos usuarios con fines de comunicación, pero puede haber llamadas que sólo sean de señalización. Un punto extremo puede ser capaz de soportar varias llamadas simultáneas.




Rec H.323 - Definiciones Canal de Señalización de Llamada: Canal fiable (TCP) utilizado para llevar los mensajes de establecimiento de la comunicación y de liberación de la llamada, empleando mensajes H.225.0, entre dos entidades H.323. Canal de Datos: Tren de comunicación distinto a audio, video y control/señalización, transportado por un canal llamado Canal de Datos Lógicos. Canal de Control H.245: canal fiable (TCP) que transporte mensajes H.245 entre puntos extremos H.323 para control de la llamada. Tren de Información: Flujo de información, paquetizada, de un tipo específico de medio, voz, data, video, señalización o control, de una sola fuente a uno o mas destinatarios.


6



Rec H.323 - Definiciones Canal Lógico: Canal utilizado para transportar trenes de información entre puntos extremos H.323. Estos canales se establecen siguiendo los procedimientos de Apertura de Canal Lógico, definido en la Rec H.323. Se utiliza un canal no fiable para trenes de audio, control de audio, video y control de video. Se utiliza canales fiables para trenes de data y de información de control H.245. Canal de Registro, Admisión y Situación: Canal no fiable utilizado para transportar mensajes H.225.0 de registro, admisión, cambios de ancho de banda y situación entre entidades H.323. Identificador de Transporte TSAP : Dirección de la capa de transporte de una entidad H.323. En VoIP el identificador TSAP es el Puerto TCP/UDP del canal asociado.




Rec H.323 - Definiciones Canal Fiable (TCP): orientado a conexión, secuenciado, confirmado y con control de flujo. Canal No Fiable (UDP): no orientado a conexión, criterio ‘the best effort’, no confirmado, sin control de flujo. Zona: Conjunto de puntos extremos (PE) y gateway’s (GW) y unidades de control multipunto (MCU’s) gestionados por un mismo gatekeeper (GK). Una zona incluye al menos un punto extremo, puede tener o no gateway’s o MCU’s y tiene solo un GK.


7



Protocolo de Señalización ITU-T H.323 Entidades H.323




Punto Extremo H.323 Terminal End Point


8



Punto Extremo H.323 Los

componentes estructurales de un PE H.323 son:

a) Codec de Audio y Video b) Canal de Datos, basado en T.120 c) Módulo de Señalización y Control de Llamada y Control RAS: H.225.0 y H.245 d) Módulo de Sincronización y Retardo Audio/Video e) Aplicación e Interfaz de Datos (T.120) f) Transductores/Mezcladores de Audio/Video g) Interfaz de Red h) Interfaz Usuario Capítulo IV – La Suite de Protocolos ITU-T H.323



Punto Extremo H.323 Estructura y Elementos de un PE H.323

IN/OUT Audio

Codec de Audio

Módulo de Sincronización

Codec de Video

IN/OUT Data

Capa Control H.245

Interfaz Usuario

y Retardo

Señalización H.225.0

H.225.0

Interfaz de Red

IN/OUT Video

Control RAS H.225.0 Alcance Rec. ITU-T H.323 Capítulo IV – La Suite de Protocolos ITU-T H.323

9



Punto Extremo H.323 Son

Puntos Extremos H.323

Teléfonos IP H.323 (H.323 IP-Phone) Teléfonos IP H.323 en Software (H.323 SoftPhone) Gateway H.323, con puertos E1/T1-FXS/FXO Gateway H.323, con Puertos BRI/PRI de ISDN Aplicaciones Multimedia en Sistemas Operativos. IP-PABX H.323 Todo aquel que Inicie y/o Termine Llamadas en H.323




Gateway H.323 Pasarela Puerta de Acceso


10



Gateway H.323 Su

función principal es la conversión adecuada entre formatos, procedimientos y protocolos entre redes no compatibles H.225.0 a/de H.221 H.245 a/de H.242 (Rec. H.246) Interoperabilidad entre la RCC y la PBN a nivel de canales de voz y telefoní telefonía; reflejar del lado de la PBN la realidad RCC (y viceversa) en modo transparente Conversión de formatos de video, audio y datos Transferir datos desde la RCC a la PBN y viceversa; usando T.120 Capítulo IV – La Suite de Protocolos ITU-T H.323



Gateway H.323 Un GW tiene características de un PE ó de una MCU del lado de la PBN; y de un PE ó de una MCU del lado de la RCC

Un GK sabe si un PE es o no un GW; esto lo sabe al momento que el PE/GW se registra en el GK Un GW disponen de soporte para el procesamiento de Señalización DTMF entre la RCC y la PBN La conversión de señalización de la PBN (H.225.0) a la RCC está definida en el estándar Q.931 (Q.2931 también)


11



Gateway H.323 Un

GW puede conectarse con otro GW a través de la RCC para facilitar la comunicación de PE H.323 que no estén en la misma red Red A (Protocolo A)

Gateway H.323

Red B (Protocolo B)




Gatekeeper H.323 Controladores de Acceso Guardián de Puerta


12



Gatekeeper H.323 También llamado Controlador de Acceso H.323 El Gatekeeper (GK) es un elemento Opcional en una Red H.323 El Gatekeeper H.323 proporciona servicios de control de llamada entre Endpoint’s H.323 y Gateway’s H.323 El controlador de acceso está separado lógicamente de los Endpoint’s. Sin embargo, su implementación física puede estar dentro de un Endpoint, un GW, un MC, un MCU o incluso en un dispositivo que no es H.323 (una PC con Linux por ejemplo)




Gatekeeper H.323 Servicios

del Controlador de Acceso

Conversión de Direcciones y Plan de Llamadas Control de Admisiones (Mensajes ARQ/ACF/ARJ H.225.0) Control de Ancho de Banda (Mensajes BRQ/BRJ/BCF H.225.0) Gestión de Zonificación Registración


13



Gatekeeper H.323 Servicios

del Controlador de Acceso

Autorización de Llamada Gestión y Monitoreo de Llamadas en Curso Compatibilidad con E.164: conversión de digitos a números de red Soporte para Conferencias Multipunto; reenviando el Canal H.245 al MC




Procesador Multipunto H.323 MP


© Ing. José G. Cotúa

14



Entidad H.323 Procesador Multipunto MP El

MP tiene la función de recibir, procesar y reenviar los trenes multimedia (voz, video y datos) de/hacia los PE que participan en una conferencia multipunto centralizada o híbrida. El MP proporciona servicios de conmutación y/o mezcla de video. El MP proporciona servicios de conmutación y/o mezcla de audio con opciones de atenuación de señales de audio para mejoramiento de la calidad




Entidad H.323 Procesador Multipunto MP El

MP proporciona soporte para conversión de algoritmos y formatos de video y audio (Codec Translation)

El MP no es llamable; la MCU que forma parte de él si que lo es. El MP termina y origina los trenes/canales de medio (voz, video y data)


15



Controlador Multipunto MC





Entidad H.323 Controlador Multipunto MC El

MC proporciona funciones de control para sustentar conferencias entre tres o mas PE de una conferencia multipunto.

El MC lleva a cabo el intercambio de capacidades con cada PE de la conferencia multipunto y envía el conjunto de las capacidades a los demás PE El MC determina el Modo de Comunicación Seleccionado (SCM, Selected Commnunication Mode) para la conferencia; el cual puede ser común para todos los PE ó diferente para cada PE


16



Entidad H.323 Controlador Multipunto MC

En una conferencia multipunto, cada PE queda conectado a un MC en su canal de control H.245; a través de una de las siguientes vías: a) Conexión explícita a la MCU b) Conexión implícita a un MC dentro de un GK c) Conexión implícita a un MC dentro de otro PE o GW d) Conexión implícita a una MCU a través de un GK





La elección del Modo de Conferencia (descentralizada o centralizada) se produce después de la conexión del PE con el MC utilizando mensajes H.245

El MC puede estar situado en: a) Dentro de un GK b) Dentro de un GW c) Dentro de un PE d) Dentro de una MCU


17




Si el MC está dentro de un PE; entonces no es llamable; aunque puede asumir el papel de los mensajes H.245 del PE

Si el MC está dentro de un GK; entonces puede ser llamable. Una MCU contiene siempre un MC. La MCU es llamable y el MC procesa el canal de contro H.245 proveniente de los demás PE





Cuando dos o mas PE participan en una conferencia, utilizan el procedimiento H.245 de determinación principalsubordinado para determinar el MC que controla la conferencia


18



Unidad de Control Multipunto MCU




Entidad H.323 Unidad de Control Multipunto MCU La MCU es un punto extremo que da soporte a las conferencias

multipunto

Está formada por un MC y opcionalmente por una o más MP. de audio, video y datos Un GW puede ser una MCU del lado de la PBN Un GK puede incluir una MCU La MCU es llamable por puntos extremos


19



Protocolo de Señalización ITU-T H.323 Aspectos Generales y Lineamientos Capítulo IV – La Suite de Protocolos ITU-T H.323



Codec’s de Audio en Puntos Extremos H.323

Todo PE H.323 DEBE tener un codec de audio. Deberá, al menos, codificar y decodificar el formato G.711 con Ley µ y Ley A.

Las capacidades de otros codec’s, como G.722, G.728, G.729, G.723.1, serán opcionales. El codec empleado por el PE se obtendrá durante el intercambio de capacidades enviando/recibiendo mensajes H.245. Un PE deberá poder operar con codec’s asimétricos (transcoding) para todos los codec’s declarados. Por ejemplo enviar G.711 y recibir G.728. Capítulo IV – La Suite de Protocolos ITU-T H.323

20



Mezcla de Audio en H.323 Un punto extremo H.323 puede recibir mas de un canal de audio; por ejemplo en llamadas de conferencias multipunto. El PE puede mezclar las señales de audio entrantes y producir una señal de audio compuesta.

El número máximo de trenes de audio simultáneos que un PE es capaz de mezclar es parte de las capacidades que negocia un punto extremo al ingresar a una llamada de conferencia multipunto.




Númeración de Canales Lógicos Cana

canal lógico se identifica de manera única con un identificador (LCN, Logical Channel Number); el cual es un valor númerico entero entre 0 y 65.535 (16 bits).

Este identificador sirve para asociar canales lógicos con conexiones de transporte (TCP/UDP). Los identificadores de canales lógicos se eligen aleatoriamente por el TX; exepto el 0 que se usa para el Canal de Control H.245. Capítulo IV – La Suite de Protocolos ITU-T H.323

21



Identificación de Entidades H.323 Toda

entidad H.323 queda identificada al menos con los siguientes parámetros: a) Dirección de Red b) Identificador TSAP (Puerto TCP/UDP) c) Alias




Identificación de Entidades H.323 Direcciones de Red (IPv4/IPv6) Cada entidad H.323 tiene al menos una dirección IP que lo identifica

Varias entidades H.323 coubicadas pueden compartir una dirección IP; por ejemplo un punto extremo y un MC Un punto extremo puede utilizar direcciones IP diferentes para canales diferentes dentro de una misma llamada IPv4 ó IPv6/IPng


22



Identificación de Entidades H.323 Direcciones TSAP Se denominan de forma genérica Identificadores TSAP (Transport Service Access Point) Identificador TSAP Puerto TCP/UDP Los identificadores TSAP permiten la multiplexación de canales que comparten la misma dirección IP Identificadores TSAP: TSAP de Canal RAS, con dirección de Multidifusión IP para el ‘Gatekeeper Discovery’ TSAP con dirección IP de multidifusión TSAP Dinámicos para los Canales Multimedia TSAP Dinámicos para Señalización de Llamada en los Gatekeeper Capítulo IV – La Suite de Protocolos ITU-T H.323



Identificación de Entidades H.323 Direcciones de Alias Un Alias es una Cadena Alfanumérica que se asocia a un Punto Extremo: una dirección E.164, ID H.323, Número de Teléfono, una Dirección e-mail, etc. Un Endpoint puede tener uno o varios Alias asociados Las direcciones de alias proporcionan un método alternativo de direccionemiento H.323 Las direcciones de Alias deben ser únicas dentro de una Zona Los MC y los MP no tienen Alias


23



Identificación de Llamadas en H.323 En H.323 se definen los siguientes identificadores para los procesos de llamadas: ID de Llamada (Call-ID) ID de Conferencia (CID) Cometido de Conferencia (conferenceGoal) Valor de Referencia de Llamada (CRV)




Identificación de Llamadas en H.323 ID de Llamada (Call-ID) Valor distinto de cero globalmente único creado por el PE llamante y pasado en varios mensajes H.225.0. Identifica la llamada con la que está asociado el mensaje. Se utiliza para asociar todos los mensajes RAS y de señalización de llamada relacionados con una misma llamada. No cambia dentro de una llamada. Su codificación y formato se especifica cen la Rec H.225.0. Asocia TODOS los mensajes entre todas las entidades H.323 dentro de una misma llamada. Capítulo IV – La Suite de Protocolos ITU-T H.323

24



Identificación de Llamadas en H.323 ID de Conferencia (CID) Valor único distinto de cero creado por PE llamante y transferido en diversos mensajes H.225.0. Identifica la conferencia a la que está asociado un mensaje. Los mensajes procedentes de todos los PE de una conferencia multipunto tendrán el mismo CID. Su codificación y formato se especifica cen la Rec H.225.0. El CID asocia TODOS los mensajes entre todos las entidades H.323 de todas las llamadas en la misma conferencia.




Identificación de Llamadas en H.323 Cometido de Conferencia (conferenceGoal) Se utiliza para especificar el propósito de la llamada, las opciones son las siguientes: a) Creación b) Incorporación c) Invitación d) Negociación e) Servicio Suplementario Independiente de la Llamada


25



Identificación de Llamadas en H.323 Valor de Referencia de Llamada (CRV) Todos los mensajes de señalización de llamada y RAS contienen un valor de referencia de llamada, llamado CRV (Call Reference Value).

Hay un CRV para el canal de señalización y otro independiente para el canal RAS. Cada llamada ascoaia un nuevo CRV para la señalización de llamada y para el RAS. El CRV solo asocia los mensajes de señalización de llamada y RAS a una llamada. Capítulo IV – La Suite de Protocolos ITU-T H.323



Canal de Datos en H.323 Ing. José G. Cotúa, Junio 2007


26



Canal de Datos en H.323 Los canales de datos son opcionales en PE H.323.

Un PE puede tener uno o varios canales de datos. Los canales de datos pueden ser unidireccionales o bidireccionales. Por defecto, los canales de datos en H.323 se manejan con en estándar T.120 de la ITU-T. Después del establecimiento de la llamada, el intercambio de capacidades; se abre un Canal Lógico para la conexión T.120 de acuerdo con los procedimientos de H.245.




Canal de Datos en H.323 Apertura de Canal Lógico para T.120 Cualquiera de las entidades de una llamada envía un Mensaje

de Apertura de Canal Lógico y se siguen después los procedimientos de Canal Lógico Bidireccional de la Rec H.245. El iniciador del canal lógico especifica que se trata de un canal T.120 y además especifica las direcciones de transporte necesarias para el establecimiento del canal. Los canales lógicos T.120 se pueden cerrar en cualquier momento y puede seguir activa la llamada H.323. Si se termina la llamada H.323, por supuesto, se cierra todo canal lógico T.120 asociado.


27



Canal de Datos en H.323 Apertura de Canal Lógico para T.120 Entidad 1 (llamante)

Entidad 2 (llamado)

H.245(openLogicalChannel, T.120) H.245(openLogicalChannelAck, T.120)

Flujo de Datos T.120

H.245(Señalización de Cierre de Canal Lógico)




El Proceso de Llamadas en H.323 Ing. José G. Cotúa, Junio 2007


28



El Proceso de Llamadas en H.323 El Proceso Típico de las Llamadas en H.323 sigue la siguiente secuencia: Pre-Llamada, Canal RAS: Registración y GK Discovery (H.225.0) Pre-Llamada, Canal RAS: Localización y Admisión (H.225.0) Señalización de Llamada: Establecimiento y Conexión (H.225.0) Comunicación Inicial e Intercambio de Capacidades (H.245) Establecimiento de Canales Multimedia: Audio/Video (RTP/RTCP) Establecimiento de Canales Multimedia: Datos (T.120/TCP) Servicios de Llamada Terminación de la Llamada




El Proceso de Llamadas en H.323 Pre-Llamada, Canal RAS GK Discovery y Registración Los Procesos Inciales Claves de Pre-Llamada son: a) GK Discovery b) Registració Registración de PE y/o GW en GK Canal RAS, Canal No Fiable (UDP) Basado en Mensajes H.225.0 Identificadores TSAP (Puertos UDP) Bien Conocidos y Estáticos


29



Canal RAS Gatekeeper Discovery




Gatekeeper Discovery Es el proceso empleado por los puntos extremos para determinar el gatekeeper en el que pueden registrarse El proceso puede ser, a) Manual b) Automático Si el punto extremo ya dispone, por configuración previa, de las direcciones del Puerto UDP y la Dirección IP del gatekeeper asociado; se dice que el proceso es Manual.


30



Gatekeeper Discovery (cont.) El proceso automático permite que un punto extremo se registre a un gatekeeper en forma dinámica. Es decir, que el punto extremo pueda determinar en todo momento un gatekeeper en el que pueda iniciar un proceso de registración. El proceso dinámico también permite que un punto extremo identifique a otro gatekeeper, en caso de que uno haya fallado. En un proceso dinámico, el punto extremo no conoce a priori al gatekeeper en el que puede asociarse. El proceso automático permite cambiar un gatekeeper sin necesidad de reconfigurar a los puntos extremos afectados.




Gatekeeper Discovery (cont.) Procedimiento GRQ, Gatekeeper Request: El punto extremo envía un mensaje de multidifusión (dirección IP destino de multidifusión ó IP broadcast y dirección MAC destino de multidifusión FF:FF:FF:FF:FF:FF) de Petición de Gatekeeper. GCF, Gatekeeper Confirmation: Uno o mas gatekeeper’s responden con un mensaje de confirmación y especifica la dirección de transporte del Canal RAS del gatekeeper (identificador del puerto UDP para el canal RAS). Si responde mas de un gatekeeper, el punto extremo puede elegir que gatekeeper utilizar.


31



Gatekeeper Discovery (cont.) Procedimiento GRF, Gatekeeper Reject: Si un gatekeeper no desea que un punto extremo sea registrado en él, devuelve un mensaje de rechazo. Unidifusión GRQ: Si el punto extremo conoce a priori la localización (la dirección IP y los puertos del canal RAS), puede elegir Unidifundir la GRQ al gatekeeper para efector de intercambio criptológico H.225.0. Inicio del Proceso de Registro: Usando el canal RAS. Ya el punto extremo conoce un gatekeeper donde se puede registrar.




Gatekeeper Discovery (cont.) Procedimiento Punto Extremo H.323

Gatekeeper H.323 Multidifusión/Unidifusión GRQ

Unidifusión GCF/GRJ

Automatic Gatekeeper Discovery (Fuente: Autor)


32



Gatekeeper Discovery (cont.) Otros Aspectos Redundancia de Gatekeeper: Un gatekeeper puede especificar, en el mensaje GCF, una lista alternativa de gatekeeper’s que pueden utilizarse en caso de fallo del gatekeeper primario. Reintentos de GRQ: Si no responde ningún gatekeeper, en un lapso de tiempo determinado (mayor de 5 seg.), el punto extremo puede reintentar enviando de nuevo un GRQ. El número de reintentos es configurable. Rediscovery: Si un punto extremo determina que tiene un registro no válido en su gatekeeper, deberá hacer un Rediscovery. Un registro no válido puede ser detectado cuando se recibe un Mensaje RRJ en respuesta a una Petición RRQ ó al no recibir respuesta alguna a un RRQ trascurido el tiempo máximo de espera de registro. Capítulo IV – La Suite de Protocolos ITU-T H.323


Canal RAS Registración de Puntos Extremos en Gatekeeper’s


33



Registro de Puntos Extremos en Gatekeeper El registro es el proceso mediante el cual un punto extremo se incorpora a una zona y le indica al gatekeeper su dirección de transporte (puertos TCP/UDP) y sus direcciones de Alias. Es registro es necesario para iniciar cualquier llamada y podrá producirse periódicamente. Un gateway o una MCU puede registrar una sola dirección de transporte ó multiples direcciones de transporte. El uso de múltiples direcciones de transporte facilita el enrutamiento de llamadas hacias los puertos de un gateway.




Registro de Puntos Extremos en Gatekeeper La Registración Aceptación ó Rechazo RRQ, Registration Request: Un punto extremo envía una petición RRQ a la dirección de transporte (puerto UDP) del canal RAS, y a la dirección IP, del gatekeeper. RCF, Registration Confirmation: El gatekeeper responde con un mensaje de confirmación a la solicitud de registro; esto si la solicitud de registro es aceptada. RRJ, Registration Reject: Si el gatekeeper rechaza la solicitud de registro, enviará entonces un mensaje de rechazo a la solicitud.


34



Registro de Puntos Extremos en Gatekeeper Procedimiento La Registración Aceptación ó Rechazo Punto Extremo H.323

Gatekeeper H.323 Petición de Registro, RRQ

Aceptación/Rechazo de Registro, RCF/RRJ

Registration Process (Fuente: Autor)




Registro de Puntos Extremos en Gatekeeper Aspectos Generales del Proceso de Registro Un punto extremo deberá registrarse en un único gatekeeper. Los mensajes RRQ pueden enviarse periódicamente para: a) actualizar registro, b) actualizar direcciones de transporte, ó c) actualización de alias. Los registros pueden expirar, los puntos extremos pueden especificar un ‘Time to Live’ (expresado en segundos) en los mensajes RRQ. Los puntos extremos pueden renovar la registración, antes de que expire, enviando mensajes RRQ con el bit de ‘Keepalive’ activado. Los puntos extremos pueden especificar direcciones de transporte alternativas, de reserva o redundante. Si el punto extremo no especifica un Alias en el mensaje RRQ, el gatekeeper puede asignarle uno y se lo indica en el mensaje RCF. Capítulo IV – La Suite de Protocolos ITU-T H.323

35



Registro de Puntos Extremos en Gatekeeper Procedimiento de Desregistración La Desregistración URQ, Unregister Request: Un punto extremo puede Cancelar su registro, enviando un Mensaje URQ (Unregister Request) al gatekeeper. UCF, Unregister Confirmation: El gatekeeper responde con un mensaje de confirmación a la solicitud de desregistro. URJ, Unregister Reject: Si el punto extremo no está registrado en el gatekeeper, este devolverá un mensaje de rechazo a la solicitud de desregistro. Mensajes URQ a Puntos Extremos: UN gatekeeper puede cancelar el registro de un punto extremo, enviándole un mensaje URQ al punto extremo y este responderá con una confirmación a la solicitud de desregistro (UCF).




Registro de Puntos Extremos en Gatekeeper Procedimiento de Desregistración Punto Extremo H.323

Gatekeeper H.323 Petición de Desregistro, URQ

Aceptación/Rechazo de Desregistro, UCF/URJ

Unregistration Process (Fuente: Autor)


36



Registro de Puntos Extremos en Gatekeeper Procedimiento de Desregistración Punto Extremo H.323

Gatekeeper H.323 Petición de Desregistro, URQ

Aceptación de Desregistro, UCF

Unregistration Process (Fuente: Autor)




El Proceso de Llamadas en H.323 Pre-Llamada, Canal RAS Localización y Admisión Otros Procesos Inciales Claves de Pre-Llamada son: a) Localización de PE (Alias Direcciones del Canal de Señalización de Llamada y del Canal RAS que han de usarse para alcanzar el PE deseado) b) Admisión c) Cambios de Ancho de Banda d) Situación e) Desligamiento Capítulo IV – La Suite de Protocolos ITU-T H.323

37



Canal RAS Localización de Puntos Extremos




Localizació Localización de Puntos Extremos Defínición: Es el proceso mediante el cual un punto extremo o un gatekeeper tiene la información de Alias de un punto extremo y desea conocer su información de contacto (su dirección IP y los puertos TCP/UDP). Procedimiento LRQ, Location request: El punto extremo o el gatekeeper envía un mensaje LRQ al identificador TSAP del canal RAS del gatekeeper asociado ó por multidifusión como se envían los mensajes GRQ del proceso de gatekeeper discovery. LCF, Location Confirmation: El gatekeeper con el que está registrado el punto extremo solicitado responderá con un mensaje de confirmación a la solicitud de localización. Este mensaje especifica entonces la información de contacto del punto extremo solicitado. La Dirección de Contacto: direcciones del canal de señalización y del canal RAS mas información adicional. Capítulo IV – La Suite de Protocolos ITU-T H.323

38



Localizació Localización de Puntos Extremos Aspectos Generales de Funcionamiento LRJ, Location Reject: Todos los gatekeeper en los que no está registrado el punto extremo solicitado, devolverán un mensaje de rechazo de localización; si han recibido mensajes LRQ Unidifusión por el canal RAS. Si reciben mensajes LSQ Multidifusión, no responderán con el LRJ. LQR asociados a Puntos Extremos de la RCC: Un gatekeeper puede conocer el Alias y la información de conexión de los puntos extremos de la RCC; este gatekeeper podría responder a un LRQ, que solicita información sobre un punto extremo de la RCC, suministrando la información de conexión necesaria para alcanzar a ese punto extremo (alcanzable a través de un Gateway).




El Proceso de Llamadas en H.323 Pre-Llamada, Canal RAS Localización y Admisión Admisió Admisión, Cambios de Ancho de Banda, Situació Situación y Desligamiento Mensajes H.225.0 de Canal RAS entre PE y GK.

Toda llamada de PE a través de un GK se inicia con un Proceso de Admisión ARQ/ACF/ARJ; con esto el PE Llamante obtiene del GK la Dirección TSAP del Canal de Señalización de Llamada, H.225.0 también, del PE Llamado.

El PE Llamado también hace un Proceso de Admisión en su GK. Capítulo IV – La Suite de Protocolos ITU-T H.323

39


Canal RAS Admisiones, Cambios de Ancho de Banda, Situación y Desligamiento




Canal RAS Admisiones, Cambios de Ancho de Banda, Situació Situación y Desligamiento El Canal RAS se emplea también para admisiones, cambios de ancho de banda, situación y desligamiento. Estos mensajes se producen entre puntos extremos y gatekeeper’s. ARQ, Admission Request: Este mensaje especifica el ancho de banda de la llamada solicitada. Es decir, la tasa de bits agregada de todos los canales de audio y video a ser enviados y recibidos; excluidos los encabezamientos RTP, UDP, IP y ETH. ACF, Admission Confirmation: El gatekeeper responde afirmativamente a la solicitud; y puede incluso reducir el ancho de banda pedido para la llamada. BRQ, Bandwidth Change Request: Un punto extremo ó un gatekeeper puede intentar modificar el ancho de banda, con la llamada en curso, utilizando este tipo de mensajes. Capítulo IV – La Suite de Protocolos ITU-T H.323

40



Canal RAS Testigos de Acceso

Un testigo de acceso es una cadena que se pasa en algunos mensajes RAS y en el mensaje de establecimiento de llamada, para:

a) Dar privacidad a la información de las direcciones de transporte y a las direcciones de Alias de un punto extremo contra la parte llamante. b) Asegurar que las llamadas se encaminen correctamente a través de las entidades H.323.




Escenarios de Llamadas en H.323


41



Escenarios de Llamadas en H.323 Llamadas PE – PE sin Registración Red IPv4/IPv6

H.225.0 H.245 PE (Llamante)

Multimedia/Data

PE (Llamado)




Escenarios de Llamadas en H.323 Llamadas PE-PE Co-Registrados en GK Gatekeeper

PE (Llamante)

o

Red IPv4/IPv6

d ra

Re g

ist

is t ra

g Re

do

GK

PE (Llamado)


42



Escenarios de Llamadas en H.323 Llamadas PE-PE donde solo un PE (Llamante) tiene GK Gatekeeper

Re g

is t ra

do

GK

Red IPv4/IPv6

PE (Llamante)

PE (Llamado)




Escenarios de Llamadas en H.323 Llamadas PE-PE donde solo un PE (Llamado) tiene GK Gatekeeper

GK g Re ist o

PE (Llamante)

d ra

Red IPv4/IPv6

PE (Llamado)


43



Escenarios de Llamadas en H.323 Llamadas PE-PE cada uno con su GK Gatekeeper

Gatekeeper

GK Registrado

Registrado

GK

Red IPv4/IPv6

PE (Llamante)

PE (Llamado)




Señalización de Llamada Protocolo H.323

Ing. José G. Cotúa Junio, 2007


44



Señ Señalizació alización de Llamada en H.323

Definició Definición La señalización de llamada en H.323 está referida al conjunto de mensajes, procedimientos y protocolos para: Establecimiento de la llamada Comunicación inicial e intercambio de capacidades Establecimiento de la comunicación de multimedia Servicios de llamada Terminación de la llamada La señalización de llamada en H.323 utiliza mensajes H.225.0 y H.245





Canal de Señalización de Llamada


45



Canal de Señ Señalizació alización de Llamada El Canal de Señalización de Llamada transporta mensajes H.225.0 para: Señalización de Llamadas entre puntos extremos en redes H.323 que no tienen gatekeeper. Señalización de Llamadas entre puntos extremos gatekeeper’s en redes H.323 que tienen gatekeeper.

y

Características del Canal de Señalización de Llamada Es un Canal Fiable (TCP) Basado en Mensajes H.225.0




Canal de Señ Señalizació alización de Llamada El Canal de Señalización en el Contexto de una Llamada 1.) Gatekeeper Discovery 2.) Canal RAS, Registración 3.) Canal RAS, Mensajes de Admisión (ARQ, ACF/ARJ) 4.) Canal H.225.0, de Señ Señalizació alización de Llamada 5.) Canal de Control H.245 6.) Canales de Multimedia y Datos


46



Canal de Señ Señalizació alización de Llamada Modelos de Señalización de Llamadas Señalización Enrutada por Gatekeeper’s Nube de Gatekeeper’s

Punto Extremo A

Punto Extremo B

Primer Modelo de Señalización de Llamadas Capítulo IV – La Suite de Protocolos ITU-T H.323



Canal de Señ Señalizació alización de Llamada Modelos de Señalización de Llamadas Señalización Enrutada entre Puntos Extremos Nube de Gatekeeper’s

Punto Extremo A

Punto Extremo B

Segundo Modelo de Señalización de Llamadas Capítulo IV – La Suite de Protocolos ITU-T H.323

47



Canal de Señ Señalizació alización de Llamada Valor de Referencia de Llamada (CRV) Todos los mensajes de señalización de llamada y RAS contienen un valor de referencia llamado ‘CVR, Call Reference Value’; definido en la Rec. H.225.0 Hay un CRV para el canal de señalización de llamada y un CRV distinto para el canal RAS. Los CRV son únicos para una misma llamada; se utilizan nuevos CRV para nuevas llamadas. No es lo mismo que el ID de Llamada (Call ID) ó el ID de Conferencia (CID, Conference ID). En resumen el CRV asocia mensajes de señaliación de llamada o RAS entre entidades H.323 dentro de la misma llamada. Su formato está definido en la Rec. H.225.0 Capítulo IV – La Suite de Protocolos ITU-T H.323



Canal de Señ Señalizació alización de Llamada ID de Llamada (Call ID) Asocia todos los mensajes entre todas las entidades H.323 de una misma llamada. Es un valor único, distinto de Cero, creado por el punto extremo llamante y pasado en varios mensajes H.225.0. El Call ID identifica la llamada a la que está asociado el mensaje. A diferencia del CRV, el Call ID no cambia dentro de una misma llamada. Su formato está definido en la Rec. H.225.0


48



Canal de Señ Señalizació alización de Llamada ID de Conferencia (CID) y Cometido de Conferencia Es un valor único distinto de Cero creado por el punto extremo llamante y transferido en diversos mensajes H.225.0. El CID identifica la conferencia con la cual está asociado un mensaje. Los mensajes procedentes de tosos los puntos extremos de una conferencia tendrán asociado un único CID. Su formato está definido en la Rec. H.225.0 El Cometido de Conferencia (ConferenceGoal) especifica el propósito de la llamada: a) Creación, b) Incorporación, c) Invitación, d) Negociación de Capacidad, y e) Servicio Suplementario Independiente de la Llamada.




Procedimientos de Señalización de Llamada


49



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada El establecimiento de las llamadas en H.323 se efectúa utilizando mensajes H.225.0 El procedimiento de establecimiento de llamadas en H.323 es completamente asíncrono; cada punto extremo puede iniciar llamadas en forma independiente y en cualquier momento El intercambio de capacidades se establece mediante mensajes H.245




Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 1.-) Llamadas entre Puntos Extremos sin Gatekeeper Punto Extremo 1

Punto Extremo 2 (1) Establecimiento

(2) Llamada en Curso (3) Aviso

(4) Conexión



50



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 1.-) Llamadas entre Puntos Extremos sin Gatekeeper Establecimiento/Petición: El Punto Extremo 1 (llamante) envía un Mensaje de Establecimiento (1) identificador TSAP del canal de señalización de llamada conocido del Punto Extremo 2 (H.225.0). Respuesta/Conexión: El Punto Extremo 2 responde con el Mensaje Conexión (4) y le pasa al Punto Extremo 1 la dirección TSAP del Canal de Control H.245 (H.225.0). El Punto Extremo 2 puede responder con mensajes: a) Aviso, b) Conexión, c) Llamada en Curso, y d) Liberación Un Mensaje de Aviso (del llamado al llamante solamente) especifica que el llamado tiene una llamada entrante en establecimiento.





Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 2.-) Llamadas entre Puntos Extremos con Gatekeeper Común H.323 define dos modos de señalización para este caso: 1) Señalización de Llamada Directa 2) Señalización de Llamada con Gatekeeper como Intermediario (GK/Proxy)


51



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 2.-) Llamadas entre Puntos Extremos con Gatekeeper Común 2.1.-) Señalización de Llamada Directa Punto Extremo 1 (llamante)

Punto Extremo 2 (llamado)

Gatekeeper ARQ (1) ACF/ARJ (2) Establecimiento (3)

Llamada en Curso (4) ARQ (5) ACF/ARJ (6) Aviso (7) Conexión (8)




Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada Llamadas entre Puntos Extremos con Gatekeeper Común 2.1.-) Señalización de Llamada Directa El PE1 (llamante) inicia el intercambio ARQ(1)/ACF(2) con el GK; este devuelve las direcciones TSAP H.225.0 del PE2 (llamado) en el ACF. El PE1 envía el Mensaje de Establecimiento (3) al PE2 utilizando el TSAP de H.225.0 del PE2. Si el PE2 acepta la llamada, inicia entonces el intercambio ARQ(5)/ACF(6) con el gatekeeper. Si el PE2 recibe un ARJ(6) del gatekeeper envía entonces un Mensaje de Liberación al PE1. El PE2 responde con un Mensaje de Conexión al especificandole la dirección TSAP del canal de control H.245.

PE1,


52



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 2.-) Llamadas entre Puntos Extremos con Gatekeeper Común 2.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario

Punto Extremo 1 (llamante)

Punto Extremo 2 (llamado)

Gatekeeper ARQ (1) ACF/ARJ (2) Establecimiento (3)

Establecimiento (4)

Llamada en Curso (5)

Llamada en Curso (5) ARQ (6) ACF/ARJ(7)

Aviso (8)

Aviso (8)

Conexión (9)

Conexión (9)




Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 2.-) Llamadas entre Puntos Extremos con Gatekeeper Común 2.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario El PE1 (llamante) inicia el intercambio ARQ(1)/ACF(2) con el gatekeeper, el gatekeeper devuelve las direcciones TSAP H.225.0 de él mismo en el ACF. El PE1 envía el Mensaje de Establecimiento (3) al GK utilizando el TSAP del canal H.225.0 recibido en el ACF anterior. El GK envía al PE2 el Mensaje de Establecimiento. Si el PE2 acepta la llamada, inicia entonces el intercambio ARQ(6)/ACF(7) con el GK. Si el PE2 recibe un ARJ(6) del GK envía entonces un Mensaje de Liberación al GK.


53



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 2.-) Llamadas entre Puntos Extremos con Gatekeeper Común 2.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario (Cont.) El PE2 responde con el Mensaje de Conexión (9) que contiene los identificadores TSAP del canal de control H.245; esto es reenviado al PE1. El GK le puede enviar al PE1 los identificadores TSAP del canal de control H.245 del PE1 ó del GK (MC); en este último caso el GK encamina también el canal de control H.245.




Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 3.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamante) 3.1.-) Señalización de Llamada Directa Punto Extremo 1 (llamante/registrado)

Gatekeeper

Punto Extremo 2 (llamado/no registrado)

ARQ (1) ACF/ARJ (2) Establecimiento (3) Llamada en Curso (4)

Aviso (5) Conexión (6)


54



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 3.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamante) 3.1.-) Señalización de Llamada Directa Solo el PE1 (llamante) está registrado en el GK; el PE2 (lamado) no está registrado en el GK. El PE1 (llamante) inicia el intercambio ARQ(1)/ACF(2) con el GK. El PE1 envía en Mensaje de establecimiento (3) al PE2 utilizando el identificador TSAP H.225.0 que ya lo conoce. Si el PE2 decide aceptar la llamada, responde con un Mensaje de Conexión (6) que contiene su identificación TSAP del canal de control H.245. Capítulo IV – La Suite de Protocolos ITU-T H.323



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 3.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamante) 3.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario

Punto Extremo 1 (llamante/registrado)

Punto Extremo 2 (llamado/no registrado)

Gatekeeper ARQ (1) ACF/ARJ (2)

Establecimiento (3)

Establecimiento (4)



Aviso (6)

Aviso (6)

Conexión (7)

Conexión (7)


55



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 3.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamante) 3.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario Solo el PE1 (llamante) está registrado en el GK; el PE2 (lamado) no está registrado en el GK. El PE1 (llamante) inicia el intercambio de mensajes ARQ (1)/ACF (2) con el GK. El GK devuelve sus identificadores TSAP del canal de señalización H.225.0. El PE1 envía el Mansaje de Establecimiento (3) utilizando esas direcciones de transporte; el GK a continuación envía el Mensaje de Establecimiento (4) al PE2 a las direcciones de transporte H.225.0 conocidas del PE2. Capítulo IV – La Suite de Protocolos ITU-T H.323



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 3.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamante) 3.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario (Cont.) Si el PE2 acepta la llamada responde con un Mansaje de Conexión (7), el cual contiene la dirección de transporte del canal de contro H.245. El GK envía el Mensaje de Conexión (7) al PE1 que contiene: a) la dirección de transporte del canal de control H.245 del PE2, ó b) la dirección de transporte del canal de control H.245 del GK (MC) en caso de que el GK encamine también el canal de control H.245 Capítulo IV – La Suite de Protocolos ITU-T H.323

56



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 4.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamado) 4.1.-) Señalización de Llamada Directa 4.2.-) Señalización de Llamada con Gatekeeper Común como Intermediario

Procedimiento Análogo…!!!




Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 5.-) Llamada entre Puntos Extremos registrados en Gatekeeper’s Diferentes 4.1.-) Ambos PE registrados, señalización de llamada directa de ambos GK 4.2.-) Ambos PE registrados, directa/encaminada

señalización

de

llamada

4.3.-) Ambos PE registrados, encaminada/directa

señalización

de

llamada

4.4.-) Ambos PE registrados, embos GK encaminan la señalización de llamada


57



Procedimientos de Señ Señalizació alización de Llamada Fase 1 – Establecimiento de la Llamada 5.-) Otros procedimientos de señalización 5.1.-) Señalización Opcional de PE llamado 5.2.-) Procedimiento de Conexión Rápida




Procedimientos de Señ Señalizació alización de Llamada Fase 2 – Comunicación Inicial e Intercambio de Capacidad Luego del establecimiento de la señalización H.225.0, los PE establecen el canal de control H.245 para (en este orden): a) Intercambio de capacidaddes b) Determinación principal-subordinado c) Apertura de canales de medios (voz, video y data) (Opcional) Los mensajes H.245 pueden ser encapsulados dentro de mensajes Q.931; a esto se le llama proceso de encapsulado o tunelación H.245


58



Procedimientos de Señ Señalizació alización de Llamada Fase 3 – Establecimiento de Comunicación Multimedia Apertura de Canales Lógicos para los trenes de medio (voz, video y

data)

La apertura de canales lógicos es regido según H.245 Canales lógicos asociados a identificadores TSAP dinámicos Caneles lógicos Canales no fiables (UDP), para Voz y Video y fiable (TCP) para Data




Procedimientos de Señ Señalizació alización de Llamada Fase 4 – Servicios de Llamada Gestión de cambios de ancho de banda (aumento/disminución) Situación Ampliación de una conferencia ad hoc Servicios suplementarios Puesta en cascada multipunto Pausa y reencaminamiento iniciados por terceras partes


59



Procedimientos de Señ Señalizació alización de Llamada Fase 5 – Terminación de la Llamada Terminación de una llamada enviando un Mensaje H.245 de finalización de llamada (endSessionCommand) Terminación de una llamada enviando un Mensaje H.225.0 de Liberación Completa H.323 define varios mecanismos para Terminación de Llamadas; basados estos en Mensajes H.245 y/o H.225.0




Señalización de Control H.245 en H.323 Protocolo de Control para Comunicaciones Multimedia (Resumen)


60



Señalización de Control H.245 en H.323 Luego de los procesos de Pre-Llamada (RAS) y de Establecimiento de Llamada (Admisión, establecimiento y Conexión) los PE establecen un Canal de Control H.245. La Función Principal del Canal de Control H.245 es: a) Intercambio de Capacidades. b) Apertura de Canales de Medios. Opcionalmente, para fines de disminución de tiempo de establecimiento de llamada, se pueden transmitir mensajes H.245 dentro del Canal de Señalización Q.931. A este proceso se le llama: ‘Tunelizació Tunelización H.245’ H.245’.




Señalización de Control H.245 en H.323 Tunelización H.245, Continuación: La Opción de Tunelización H.245 la define el PE Llamante en el Mensaje de ESTABLECIMIENTO (h245Tunneling: TRUE) y en TODOS los Mensajes Q.931 sugsiguientes. Sin embargo, durante el curso de la llamada; cualquier PE puede elegir efectuar un cambio y pasar a una Conexión H.245 separada en cualquier momento. Básicamente, uno de los PE le envía, en Mensajes Q.931, la dirección ‘h245Address’ al otro PE para iniciar el Canal H.245.


61



Señalización de Control H.245 en H.323 La señalización H.245 se establece entre:

a) PE y MC b) PE y GK c) PE y PE Se establece exactamente un Canal de Control H.245 en cada sentido de cada llamada, en la que participe la entidad H.323. El Canal de Control H.245 se identifica como el Canal Lógico ‘0’. Los procedimientos normales de apertura/cierre de canales lógicos no se aplican al canal de control H.245.




Señalización de Control H.245 en H.323 Los Mensajes de Control H.245 se clasifican en: a)) de Petició Petición, requieren una acción específica y una respuesta inmediata. b) de Respuesta, Respuesta respondetn a peticiones. c) de Instrucció Instrucción, requieren acción específica; pero no una respuesta d) de Indicació Indicación, informativos y no requieren respuesta


62



Señalización de Control H.245 en H.323 Mensajes de control extremo-extremo para:

a) Determinación principal-subordinado b) Intercambio de capacidades c) Señalización de canal lógico d) Señalización de canal lógico bidireccional e) Señalización de cierre de canal lógico f) Petición de modo g) Determinación de retardo de ida y vuelta h) Señalización de bucle de mantenimiento




Señalización de Control H.245 en H.323 Determinación Principal-Subordinado Se utiliza para resolver conflictos entre dos PE que están intentando establecer un canal multimedia bidireccional. Lo que sucede es que ambos PE intercambian Números Aleatorios, enciados en Mensajes H.245, con el objeto de determinar cual PE es el Principal y cual es el Subordinado.


63



Señalización de Control H.245 en H.323 Intercambio de Capacidades Se utiliza para que cada PE anuncie sus capacidades de recepción y transmisión de trenes de medio; así como los modos de funcionamiento en que un PE puede funcionar. Por ejemplo: ejemplo los Codec’s de Audio y Video que el PE puede utilizar. Los PE pueden añadir capacidades dinámicamente durante una sesión.




Señalización de Control H.245 en H.323 Señalización de Canal Lógico Canal Lógico Información de un Transmisor a uno o mas Receptores. Los Canales Lógicos se identifican con un Número de Canal Lógico; único en cada sentido de la dirección. Los Canales Lógicos se Abren y Cierran usando Mensajes de Control H.245. Puede existir Bidireccionales.

Canales

Unidireccionales

(Asimétricos)

ó

Canales Lógicos para Voz y Video: UDP, RTP/RTCP. Canales Lógicos para Data: TCP. Capítulo IV – La Suite de Protocolos ITU-T H.323

64


Ing. José Cotúa

Media Gateway Control Protocol MGCP v1.0 Ing. José José Cotú Cotúa, Agosto 2007

1

Capitulo V: Protocolos de Señalización MGCP y MEGACO


Ing. José Cotúa

Descripció Descripción General de MGCP IETF

RFC3435 (2003)

Es un protocolo ideado para intercambio de señalización entre: - Agentes de Llamada (Call Agent ó Media Gateway Controllers). - Pasarelas (Media Gateway).


2

1


Ing. José Cotúa

Descripció Descripción General de MGCP • • •

•

Agentes de Llamada Es donde reside el control y la inteligencia del tráfico telefónico. Control del plan de enrutamiento de llamadas y de señalización. Origen de instrucciones y comandos a las pasarelas y teléfonos IP. Supervisión de eventos en las pasarelas.

• • • • • •

Pasarelas Interconexión PSTN a VoIP. Puertos FXS, FXO, TDM, etc. Funciones de Media. Señalización final hacia/desde la PSTN. Envía eventos a los Agentes de Llamada. Recibe y ejecuta comandos e instrucciones de los Agentes de Llamada.

3



Ing. José Cotúa

Descripció Descripción General de MGCP MGCP es un protocolo de tipo Maestro/Esclavo (Gestión Centralizada). - Maestro: Los Agentes de Llamada. - Esclavo: Las Pasarelas. Maestro

FXO FXS TDM

s do s n to ma en o Ev C

s s to do en v an E om C

Agente de LLamada

Pasarela

Pasarela

Esclavo

Esclavo


FXO FXS TDM

4

2


Ing. José Cotúa

Gestió Gestión Centralizada MGCP Son los intermediarios de interconexión entre la PSTN y la VoIP. Contienen en uno de sus extremos los ‘Endpoints’ sobre los cuales los Agentes de Llamada pueden crear, modificar o finalizar conexiones de VoIP asociadas a sesiones de media con otros ‘Endpoints’. En los Media Gateway se generan eventos y señalización de cambio de status de los Endpoints, colgado y descolgado por ejemplo, que son reportados a los Agentes de Llamada. Los Media Gateway reciben instrucciones y comandos directamente de los Agentes de Llamada para la gestión de cada sesión de VoIP. Los Media Gateway pueden ser ‘Auditados’: se audita a los Endpoints y a sus conexiones.

5



Ing. José Cotúa

Detalles de Funcionamiento MGCP Media Gateway. Gateway. El Media Gateway tiene la funció función principal de conversió conversión de protocolos de la Red de Conmutació Conmutación de Circuitos (RCC(RCC-PSTN) a la Red de Conmutació Conmutación de Paquetes (PBN). El

Red de Conmutació Conmutación de Paquetes

Media Gateway

Red de Conmutació Conmutación de Circuitos

IP

ETH, ATM, xDSL, WiFI, WiMAX, Fibra, PLC


E1/T1, FXS, FXO, E&M

6

3


Ing. José Cotúa

Detalles de Funcionamiento MGCP Call Agent (Media Gateway Controller). Centro de la Inteligencia y Control de Llamadas desde y hacia los Media Gateway. Tienen la función principal de intercambiar Comandos, Instrucciones y Respuestas con los Media Gateway’s que están bajo su control. MGCP asume que TODO el control de las llamadas, originadas y destinadas en los Media Gateway’s, están controladas y sincronizadas el los Call Agent’s. El proceso es completamente centralizado. Los Media Gateway no ejecutan acciones o comandos que no sean provenientes de los Call Agent’s. El proceso es de tipo Maestro/Esclavo. Esto, es uno de los aspectos mas claves y resaltantes de MGCP.

7



Ing. José Cotúa

Detalles de Funcionamiento MGCP Desde el punto de vista de los Media Gateway’s, en MGCP se definen Dos (02) tipos de estructuras: Los Endpoints: Endpoints: fuentes/origen de data multimedia, pueden ser físicos o virtuales. Son todos y cada una de las interfaces de los Media Gateway. Las Conexiones: Conexiones: pueden ser de tipo punto a punto ó multipunto. Está asociada a tráfico de VoIP sobre RTP/RTCP/UDP. Una llamada es un contenedor de Conexiones.


8

4


Ing. José Cotúa

Detalles de Funcionamiento MGCP Conexiones y Llamadas. Las Conexiones se agrupan en Llamadas. Una o mas conexiones pueden pertenecer a una llamada. El establecimiento de las Conexiones y las Llamadas en MGCP es un proceso controlado completamente por los Call Agent’s. Las Conexiones se crean desde los Call Agent’s a cada Endpoint. Es decir; una llamada Punto a Punto son Dos Conexiones. Cada Conexión se referencia, de manera única a través de un Identificador de Conexión. Cada Conexión tiene asociada una serie de Atributos.

9



Ing. José Cotúa

Detalles de Funcionamiento MGCP Relació Relación de MGCP con H.323: Un Call Agent en MGCP es equivalente a un Gatekeeper H.323 y un Media Gateway es equivalente a un Endpoint H.323. Identificació Identificación de los Endpoint’ Endpoint’s. De la forma, Media_Gateway_Local_Name@Media_Gateway_Domain Media_Gateway_Local_Name@Media_Gateway_IPv4 Media_Gateway_Local_Name@Media_Gateway_IPv6


10

5


Ing. José Cotúa

Llamada entre Dos Endpoints, cada uno asociado a un Media Gateway, a travé través de un Call Agent El Call Agent envía el comando ‘Create a Connection’ al primer Media Gateway. El Media Gateway reserva los recursos para la conexión. El Media Gateway responde al comando con ‘Session Description’; donde se especifican básicamente los puertos UDP, el codec a utilizar y las direcciones Ip de localización.

El Call Agent envía el comando ‘Create a Connection’ al segundo Media Gateway; y le incluye la información de ‘Session Description` del primero. Igualmente, el Media Gateway reserva los recursos para la conexión y le envía también la respuesta con el ‘Session Description’ al Call Agent.

11



Ing. José Cotúa

Llamada entre Dos Endpoints, cada uno asociado a un Media Gateway, a travé través de un Call Agent El Call Agent usa el comando ‘Modify Connection’ para pasarle al primer Media Gateway la información ‘Session Description’ del segundo Media Gateway.

La comunicación de media se establece entre los Endpoint’s de los Media Gateway’s.


12

6


Ing. José Cotúa

Llamada entre Dos Endpoints, cada uno asociado a un Media Gateway, a travé través de distintos Call Agent’ Agent’s Cuando los Media Gateway’s se encuentran en Call Agent’s distintos, lo que sucede es que los Call Agent’s intercambian información utilizando un Protocolo de Señalización adicional; como SIP por ejemplo, con el objeto de sincronizar la creación de las conexiones necesarias para comunicar a los Endpoint’s que están en los Media Gateway’s. “ Una vez establecidas las conexiones entre los Endpoint’ Endpoint’s, el Call Agent puede en cualquier momento; utilizando Comandos ‘Modify Connections’ Connections’, modificar los pará parámetros de tales conexiones. Por ejemplo, cambiar los Codec’ Codec’s, modificar las Direcciones IP’ IP’s, cambiar los Puertos UDP, etc. ”

13



Ing. José Cotúa

Gestió Gestión de Conexiones por parte de los Call Agent’ Agent’s “ Una vez establecidas las conexiones entre los Endpoint’ Endpoint’s, el Call Agent puede en cualquier momento; utilizando Comandos ‘Modify Connections’ Connections’, modificar los pará parámetros de tales conexiones. Por ejemplo, cambiar los Codec’ Codec’s, modificar las Direcciones IP’ IP’s, cambiar los Puertos UDP, etc. ”

“ Los Call Agent’ Agent’s pueden eliminar Conexiones enviando Comandos de tipo ‘Delete Connections” Connections” a los Media Gateway. Los Media Gateway podrá podrán responder, ante tal solicitud, de forma afirmativa o negativa” negativa”


14

7


Ing. José Cotúa

Protocolo MEGACO Versión 1 Ing. José José Cotú Cotúa, Junio 2007

15



Ing. José Cotúa

Protocolo MEGACO Recomendación

ITU-T H.248

Documento IETF RFC3015. Basado en MGCP. Getión Centralizada de la Señalización. SIP y/o H.323 como protocolos complementarios de señalización. Señalización entre MGC y los MG con MEGACO y entre MGC’s usando H.323 ó SIP. La misma Estructura Funcional que MGCP. Capitulo V: Protocolos de Señalización MGCP y MEGACO

16

8


Ing. José Cotúa

Protocolo de Señalización SIP Session Initiation Protocol Ing. José José G. Cotú Cotúa Agosto, 2007

1

Capítulo VI – Protocolo de Señalización SIP


Ing. José Cotúa

Protocolo de Señalización SIP Introducción y Descripción General


2

1


Ing. José Cotúa

Origenes de SIP SIP

es un Estándar IETF y es parte fundamental de la Arquitectura de Protocolos Multimedia de la IETF.

SIP versión 1 (SIPv1), Documento RFC2543 (1999). SIP versión 2 (SIPv2), Documento RFC3261 (2002). Primer protocolo de VoIP basado en HTTP y pensado especialmente para aprovechar flexibilidad de Redes en INTERNET.

3



Ing. José Cotúa

Definiciones de SIP SIP

es un protocolo de señalización de control, a nivel de aplicación, que se emplea para el Establecimiento, la Modificación y la Finalización de Sesiones Multimedia (Llamadas) entre dos o mas participantes.

SIP es un protocolo de intercambio de Mensajes, de Petición y Respuesta, que está basado el el Modelo de Conexión Cliente/Servidor (TCP/UDP). SIP es un protocolo de señalización que utiliza mensajes en formato de Texto Plano, basado en el protololo HTTPv1.1. !!! Sesió Sesión Multimedia = Voz + Video + Data !!!


4

2


Ing. José Cotúa

Aspectos Generales de SIP SIP realmente no define, limita, establece o circunscribe las sesiones multimedia a tráfico de video y voz solamente; puede ser cualquier otro tipo de sesión como juegos por ejemplo.

Como protocolo de aplicación SIP utiliza por defecto el protocolo de transporte UDP (Puerto: 5060); aunque el estándar no limita SIP a usar solo UDP; puede también usar TCP. SIP utiliza un protocolo llamado SDP (Session Description Protocol) en el proceso de establecimiento de sesiones. Para sesiones estrictamente de VoIP; SIP utiliza solo Dos Canales: a) Canal de Señalización (SIP), y b) Canal de ‘Stream’ de VoIP. Desde este punto de vista es mas eficiente que H.323. 5



Ing. José Cotúa

Aspectos Generales de SIP SIP se fundamenta en un esquema de envío de mensajes, de petición y respuesta, similares en su sintaxis y semántica a los definidos en el estándar HTTP (Hypertext Transfer Protocol). Por supuesto, las conexiones SIP se establecen conforme al Modelo de Conexión Cliente/Servidor. El intercambio de mensajes de tipo Petición/Respuesta recibe el nombre de Transacciones SIP entre el Cliente y el Servidor SIP. Todos los Mensajes en SIP se codifican en Texto (no en Binario como en H.323); por tanto la Señalización SIP es completamente transparente a lo largo de la red IP. Es decir, cualquier ‘Sniffer’ puede hacer tracking directo de dicha señalización. ¿Ventaja o Desventaja?


6

3


Ing. José Cotúa

Aspectos Generales de SIP Basado en el Uso de URL (Uniform Resource Locators).

El los Mensajes SIP, especifica: - Especifica el Originador (From) - Destinatario (Request-URI) - Destinatario Final (To) - Dirección de Redireccionamiento (Contact) La Sintáxis de los SIP-URL está definida en el documento IETF RFC2396.

7



Ing. José Cotúa


Sintáxis: sip:user:password@host:port;transport= sip:user:password@host:port;transport=tcp/ tcp/udp; udp;… Donde, host: Dirección de Host ó Dirección IPv4/IPv6 También el SIP-URL puede especificar Parámetros como: - Valor de TTL para SIP. - Direcciones Físicas ó Número Telefónico del Usuario. Ejemplo: sip:[email protected];maddr=239.255.255.1; ttl=15 =15 sip:[email protected];maddr=239.255.255.1;ttl


8

4


Ing. José Cotúa


Ejemplos de SIP-URL’s:

sip:[email protected] sip:j.doe:[email protected];transport=tcp sip:[email protected]?subject=project sip:+1-212-555-1212:[email protected];user=phone sip:[email protected] sip:[email protected] sip:[email protected] sip:alice%[email protected] sip:[email protected];method=REGISTER

Los SIP-URL’s son ‘Case-Insentitive’.

9



Ing. José Cotúa


En la Señalización SIP, la Localización de los UAS está basada en Servidores DNS. En H.323 la Localización de los Usuarios está basada en el Gatekeeper; el cual puede (opcionalmente) usar Servidores DNS.


10

5


Ing. José Cotúa

Objetivos de SIP Lograr una mayor integración con las aplicaciones y servicios en ambiente de INTERNET.

Mayor flexibilidad para adaptarse rápidamente a nuevos requerimientos y funcionalidades. Implementación Funcionalidades.

Simplificada,

conservando

Robustez

y

Solventar Rápidamente Inconvenientes de Firewall’s y NAT’s. Hacer uso efectivo de la Arquitectura de Protocolos TCP/IP. 11



Ing. José Cotúa

Arquitectura Multimedia de la IETF Distribuida y No Centralizada.

Basada en un conjunto de protocolos independientes e intercambiables. Flexible, Escalable y con Ingeniería Abierta. Compatible con la Suite H.323. Funciones de Establecimiento, Modificación y Finalización de Sesiones Multimedia: SIP.


12

6


Ing. José Cotúa

SIP y la Arquitectura de Protocolos Aplicación

SIP

Transporte Red

SDP TCP

IPv4

Enlace

RTP/RTCP UDP

IPv6/IPng

Aplicación Transporte

ICMP

IEEE 802.3/802.11

Física

Red Enlace Física

Red IP

13



Ing. José Cotúa

Protocolo de Señalización SIP Detalles de Funcionamiento


14

7


Ing. José Cotúa

Detalles de Funcionamiento del Protocolo SIP En

SIP la señalización, para el establecimiento, modificación y terminación de sesiones multimedia, se maneja por un canal separado al canal de ‘Streaming de Voz y Video’. ¡¡ Protocolo SIP => Canal_de_Señ Canal_de_Señalizació alización_SIP + Canal_de_Streaming_Voz/Video Canal_de_Streaming_Voz/Video !! Servidor SIP

Canal de Señalización SIP

(Servidor)

UDP/TCP

Red IP

Canal de ‘Streaming’ (Voz/Video) RTP/RTCP/UDP Agente SIP (Cliente)

15



Ing. José Cotúa

SIP es un Protocolo basado en HTTP =>> Fá Fácil ‘Debug’ Debug’ el Tiempo Real Es

común encontrar en la literatura que SIP es un protocolo basado en Texto. Y de hecho es así, porque como está basado en HTTP y en una arquitectura de intercambio de mensajes de petición y respuesta; estos mensajes se transmiten en Texto Plano, directamente con formato de caracteres ASCII. En consecuencia, SIP es un protocolo al que se le puede hacer ‘DEBUG’ en tiempo real simplemente ‘Leyendo’ directamente el contenido de los mensajes SIP. (‘Sniffer’ Sniffer’)…


16

8


Ing. José Cotúa

SIP es un Protocolo basado en HTTP =>> Fá Fácil ‘Debug’ Debug’ el Tiempo Real Por ejemplo, con un simple ‘Sniffer’ (como Ethereal, por ejemplo) se puede hacer ‘Debug’ de transacciones SIP; simplemente analizando las tramas Ethernet y sus contenidos. Esta es una de las grandes diferencias de SIP con respecto a H.323. En H.323 la señalización es Binaria y Codificada, más rápida, segura y eficiente (mas no es flexible), pero; no es posible el ‘Debug’ en tiempo real. Por eso, suele decirse que H.323 es un protocolo de ‘debug’ especializado. 17



Ing. José Cotúa

Servicios que Soporta el Protocolo SIP Servicio de Localizació Localización de Usuarios: Usuarios determinación de las direcciones de localización de los usuarios finales que participarán en las sesiones multimedia.

•

• Servicio de Establecimiento de Llamada: repique, Llamada negociación de parámetros entre los participantes de una sesión. • Servicio de Disponibilidad de Usuario: Usuario la posibilidad de determinar si un agente SIP desea o no participar en una nueva sesión.


18

9


Ing. José Cotúa

Servicios que Soporta el Protocolo SIP • Servicio de Caracterí Características de Usuario: Usuario la posibilidad de determinar los flujos multimedia, y las características de loos mismos, que podrán utilizarse en una sesión. • Servicio de Manejo de Llamadas: Llamadas transferencia de llamadas, y terminación de sesiones.

19



Ing. José Cotúa

Entidades SIP Básicamente, la Arquitectura SIP soporta Dos Tipos de Entidades claramentes definidas dentro del protocolo: Agente de Usuario SIP, o simplemente Agente SIP. En adelante: Clientes SIP. Servidores SIP.


20

10


Ing. José Cotúa

Entidades SIP Agente de Usuario SIP, o simplemente Agente SIP Es el sistema final que modela el comportamiento del usuario del sistema SIP. Consta de dos funcionalidades: Cliente o Servidor. Esto es, el usuario final deberá poder o bien Establecer/Iniciar (Agente en Modo Cliente SIP) ó Recibir (Agente Servidor SIP) una nueva Llamada/Sesión. Ejemplos

Agente SIP, Modo Cliente SIP User Agent Client ‘UAC’ Inicia Peticiones

IPIP-Phone SoftSoft-Phone Adaptadores IPIP-PBX SIP Gateway’ Gateway’s

21



Ing. José Cotúa

Entidades SIP Servidor SIP Servidores de Localizació Localización (Location (Location Server). Server) Servidores de Registració Registración (Registrar Server). Server) Servidores Proxy (Proxy (Proxy Server) Modo Persistente (Stateful (Stateful Proxy Server). Server) Servidores Proxy de Estado Volá Volátil (Stateless (Stateless Proxy Server). Server)

Servidor de Redirecció Redirección (Redirection (Redirection Server). Capítulo VI – Protocolo de Señalización SIP

22

11


Ing. José Cotúa

Entidades SIP Servidor de Localizació Localización (Location (Location Server) Este tipo de servidor es utilizado por los servidores Proxy SIP ó por un servidor de Reenvío SIP para obtener información sobre la posible localización del Agente de Usuario que está siendo llamado. El servidor de localización puede estar externo a la red SIP y puede que emplee un protocolo alternativo, como TRIP (Telephony Routing over IP) para comunicarse con los otros servidores. Servidor de Localización Permite Obtener Informaciónde Localización de los Usuarios en Proceso de ser Llamados 23



Ing. José Cotúa

Entidades SIP Servidor de Registració Registración (Registrar Server) A este tipo de servidor se enviar peticiones de actualización de ubicación y registración por parte de los Agentes de Usuarios. Se pueden o no aceptar y/o rechazar peticiones de registración; todo basado en políticas de acceso y seguridad con contraseñas. Servidor de Registración Permite Obtener Actualizaciones de Ubicación y Peticiones de Registración de los Usuarios


24

12


Ing. José Cotúa

Entidades SIP Servidor de Redirecció Redirección (Redirection (Redirection Server) Este servidor devuelve a los Agentes de Usuarios la dirección del NHS (Next Hop Server). Permite el Establecimiento de Llamadas entre Clientes sin necesidad de usar Proxy SIP. Los procesos de llamadas redireccionadas disminuyen la carga de los Servidores Proxy debido a llamadas concurrentes.

25



Ing. José Cotúa

Entidades SIP Servidor de Proxy (Proxy (Proxy Server) Son quizá los servidores mas importantes y usados en SIP. Son los grandes Intermediarios (Proxy = Intermediario) de las Transacciones SIP y Tráfico de ‘Stream’ entre los Agentes de Usuarios SIP. Juegan un papel similar a los Proxy HTTP en la Navegación WEB. Un servidor Proxy reenvía peticiones al siguiente servidor (tambi tambié én llamado NHS, Next Hop Server) Server luego de decidir cual debe ser. El NHS puede ser cualquier tipo de servidor SIP.


26

13


Ing. José Cotúa

Entidades SIP Servidor de Proxy (Proxy (Proxy Server) De esta forma, antes de que una petición llegue al UAS final, en general, habrá atravesado varios servidores; que serán recorridos también por la respuesta en sentido contrario. Puesto que el servidor Proxy maneja peticiones y respuestas, actúa como Cliente y como Servidor SIP, según sea el caso.

27



Ing. José Cotúa

Entidades SIP Servidor de Proxy (Proxy (Proxy Server) Servidor Proxy en Modo Persistente (Stateful Proxy Server) El servidor asigna a cada petición entrante, una petición saliente, creando para ello un nuevo proceso de usuario que atenderá a cada llamada entrante.


28

14


Ing. José Cotúa

Entidades SIP Servidor de Proxy (Proxy (Proxy Server) Servidor Proxy de Estado Volá Volátil (Stateless Proxy Server) Procesa cada petición entrante en modo secuencial y elimina cualquier resto de la misma una vez que la petición saliente se ha generado. Consume menos recursos.

29



Ing. José Cotúa

Entidades SIP Servidor de Proxy (Proxy (Proxy Server) Servidor Proxy: Persistente Vs. Volá Volátil Stateful Proxy Server

Stateless Proxy Server

• Mantiene el estado de la llamada.

• No existe contexto de la llamada.

• Duplica el UAC/UAS para procesar peticiones/respuestas.

• La respuesta es independiente de la duplicación UA.

• Se guarda el estado de la llamada y de la transacción.

• Cliente anónimo.

• Deben funcionar sobre TCP para mayor fiabilidad. • Los servicios de valos añadido requieren guardar la información de estado. Capítulo VI – Protocolo de Señalización SIP

• Alta capacidad concurrentes.

de

procesos

• Menor uso de recursos, memoria y procesador.

30

15


Ing. José Cotúa

Protocolo de Señalización SIP El Proceso de Llamadas en SIP

31



Ing. José Cotúa

Llamada entre Usuarios SIP a travé través de Servidor Proxy y Servidor de Localizació Localización Servidor de Localización

2.2.- CONTACT

3.3.- PRECISE LOCATION

1.1.- INVITE

Usuario Origen

4.4.- INVITE

6.6.- SUCCESS

5.5.- SUCCESS

Proxy SIP 7.7.- ACK

Usuario Destino

8.8.- ACK

UAC

UAS

Llamante

Llamado


32

16


Ing. José Cotúa

Llamada entre Usuarios SIP a travé través de Servidor Proxy y Servidor de Localizació Localización UAC

Proxy SIP

UAS

Servidor de Localizació Localización

Llamante

Llamado

1.1.- INVITE 2.2.- CONTACT 3.3.- LOCATION 4.4.- INVITE 5.5.- SUCESS 6.6.- SUCESS 7.7.- ACK 8.8.- ACK RTP STREAMING

RTP STREAMING

BYE BYE SUCCESS SUCCESS

33



Ing. José Cotúa

Llamada entre Usuarios SIP a travé través de Servidor de Redirecció Redirección Servidor de Localización

2.2.- CONTACT

3.3.- PRECISE LOCATION

UAC

UAS 1.1.- INVITE

Usuario Origen

4.4.- SUCCESS 5.5.- ACK

Redirector SIP

Usuario Destino

6.6.- INVITE 7.7.- SUCESS 8.8.- ACK


34

17


Ing. José Cotúa

Llamada entre Usuarios SIP a travé través de Servidor de Redirecció Redirección UAC

Proxy SIP

Servidor de Localizació Localización

Llamante

UAS Llamado

1.1.- INVITE 2.2.- CONTACT 3.3.- LOCATION 4. -SUCCESS 5.5.- ACK 6.6.- INVITE 7. SUCESS 8. ACK RTP STREAMING BYE SUCCESS

35



Ing. José Cotúa

Protocolo de Señalización SIP Análisis Detallado de los Mensajes en SIP


36

18


Ing. José Cotúa

Los Mensajes SIP - Descripció Descripción General SIP

es un Protocolo basados en Mensajes de Petición y Respuesta entre los UAC y los UAS.

SIP es un Protocolo basado en Texto y utiliza un el set de Caracteres definido en el Estándar ISO-10646 (Conjunto Universal de Caracteres). Cada Mensaje SIP es un Conjunto de Líneas de Texto que terminan con los Caracteres Especiales: CRLF (DAHEX), CR (DHEX) ó LF (AHEX).

37



Ing. José Cotúa

Los Mensajes SIP - Descripció Descripción General La Sintáxis de los Mensajes SIP y los Campos de las Cabeceras son muy similares a los definidos en el Protocolo HTTP/1.1 (RFC2068). Sin embargo, hay que decir que SIP no es una Extensión de HTTP; hay diferencias notables como por ejemplo que HTTP usa solo TCP y SIP puede usar UDP, por defecto, y TCP.

Esta es la Razón por la cual se dice que SIP es un Protocolo que permite Fácilmente hacer ‘Debug’ en Tiempo Real. Pero, no hay que confundir esto con que sea mas sencillo y mas seguro. En H.323 la Estructura de los Mensajes es Binaria y Codificada.


38

19


Ing. José Cotúa

Los Mensajes SIP – Tipos de Mensajes En SIP se definen Dos (02) Tipos de Mensaje: 1) Mensajes de Petició Petición (Cliente (UAC) Servidor (UAS)). . (UAS)) Son los mensajes enviados por los clientes a los servidores SIP para el establecimiento de sesiones. 2) Mensajes de Respuesta (Servidor (UAS) Cliente (UAC)). Son los mensajes enviados de los servidores a los clientes SIP, como respuesta a las peticiones.

39



Ing. José Cotúa

Estructura de los Mensajes SIP La Estructura Genérica de un Mensaje SIP, sea de Petición o Respuesta, es la siguiente: ‘Start Line’ : Una Línea de Comienzo, que depende si el mensaje es de Petición o de Respuesta. ‘Headers’ : Una o más Cabeceras. ‘Empty Line’ : Una Línea Vacía que Indica el Fin de las Cabeceras (CRLF). ‘Message Body’ : El Cuerpo del Mensaje (Opcional).


40

20


Ing. José Cotúa

Los Mensajes SIP – Estructura Petició Petición/Respuesta Mensajes de Petició Petición Servidor SIP

INVITE, ACK, BYE, CANCLEL, REGISTER, OPTION, etc.

UAC

Red IP

Mensajes de Respuesta Respuesta del Servidor: 1XX, 2XX, 3XX, 4XX, 5XX, 6XX y 7XX

Cliente SIP UAC

¡¡ Tanto los Mensajes de Petició Petición como los de Respuesta contienen los Campos de Encabezado de SIP y Campos de Mensajes de SIP !! 41



Ing. José Cotúa

Mensajes SIP Estructura de los Mensajes de Petició Petición Línea de Comienzo: ‘Request-Line’ Cabeceras Línea en Blanco Cuerpo del Mensaje (Opcional) INVITE BYE

Method Space RequestRequest-URI Space SIPSIP-Version CRLF

OPTIONS ACK CANCEL REGISTER

RequestRequest-URI: Request Universal Resource Identifier

Versió Versión del Protocolo SIP utilizado

Especifica el Usuario o Servicio que dirige la Petició Petición Capítulo VI – Protocolo de Señalización SIP

42

21


Ing. José Cotúa

Mensajes SIP Estructura de los Mensajes de Respuesta Línea de Comienzo: ‘Status-Line’ Cabeceras Línea en Blanco Cuerpo del Mensaje (Opcional) SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF

Versió Versión del Protocolo SIP utilizado

1XX: Información. 2XX: Éxito. 3XX: Desvío.

Entero de Tres Dí Dígitos que Indica el Resultado del Intento de Servir la Petició Petición.

4XX: Error en el Cliente. 5XX: Error en el Servidor.


6XX: Fallo General


Cabeceras

43

Ing. José Cotúa

Mensajes SIP Las Cabeceras

En la cebecera de los mensajes se especifica información como: el llamante, el llamado, el camino o ruta del mensaje, el tipo y longitud del cuerpo del mensaje, etc. Existen campos que se emplean en todos los mensajes y otros que se utilizan únicamente en situaciones muy concretas. Línea de Comienzo Cabeceras Línea en Blanco Cuerpo del Mensaje (Opcional)


44

22


Cabeceras

Ing. José Cotúa

Mensajes SIP Las Cabeceras

En SIP existen 37 Campos de cabeceras diferentes que se agrupan en Cuatro (04) Tipos, que son: 1) Campos Gené Genéricos (General Header). 2) Campos de Entidad (Entity Header). 3) Campos de Respuesta (Response Header). 4) Campos de Petició Petición (Request Header). Línea de Comienzo Cabeceras Línea en Blanco Cuerpo del Mensaje (Opcional) 45



Ing. José Cotúa

Mensajes SIP, Las Cabeceras (Cont.) Cabeceras 1) Campos Genéricos (General Header). Estos campos se usan tanto en Mensajes de Peticiones como en Mensajes de Respuestas. 2) Campos de Entidad (Entity Header). Estos campos especifican información acerca del cuerpo del mensaje o, en caso de no existir este, sobre los recursos identificados en la petición.


46

23


Ing. José Cotúa

Mensajes SIP, Las Cabeceras (Cont.) Cabeceras 3) Campos de Respuesta (Response Header). Permiten al servidor pasar información adicional sobre la respuesta que no puede ser incluida en la línea de comienzo. 4) Campos de Petición (Request Header). Actúan como modificadores de la petición y sirven para que el cliente especifique información sobre la petición o sobre el mismo al servidor. Los mas importantes: ‘To’ y ‘From’ 47



Ing. José Cotúa

Mensajes SIP - El Cuerpo del Mensaje Cuerpo del Mensaje Todas las Peticiones pueden incluir, opcionalmente, un Cuerpo del Mensaje, excepto la Petició Petición de BYE. Para las Peticiones INVITE, ACK y OPTIONS el Cuerpo del Mensaje es una Descripció Descripción de la Sesió Sesión y esto se hace basado en el Protocolo SDP. Línea de Comienzo Cabeceras Línea en Blanco Cuerpo del Mensaje (Opcional) Capítulo VI – Protocolo de Señalización SIP

48

24


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petición

49



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method Puede ser cualquiera de los siguientes: - INVITE

- ACK

- OPTIONS

- BYE

- CANCEL

- REGISTER


50

25


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method: INVITE Para indicarle al UAS que está siendo invitado a participar en

una sesión.

En el Cuerpo del Mensaje se especifica una descripción de la sesión: Tipo de Medios a Transmitir, Direcciones de Red, etc. La Sesión se Identifica por un ‘Call-ID’ (Identificador Único). El UAS, si acepta la Invitación, Responde con una Respuesta de Código 200 (OK). 51



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method: ACK Confirmación de que el UAC ha recibido una respuesta final de una Petición INVITE. Todos los Mensajes de Respuesta de tipo 2XX son confirmados, por parte del UAC, con ACK.


52

26


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method: OPTIONS Para solicitud de Status y Capacidades del Server SIP que es llamado.

53



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method: BYE El UAC le indica al UAS que desea terminar la Llamada/Sesión.


54

27


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method: CANCEL Mediante una Petición CANCEL un UAC cancela una Petición Pendiente, asociada con las Cabeceras Call-ID, To, From y CSeq. Sin embargo, no cancela Peticiones ya completadas (aquellas en las que el UAS ya ha retornado una Respuesta Final). Un UAC puede hacer una Patición CANCEL en cualquier momento.

Un Servidor Proxy SIP que reciba una Petición CANCEL reenvía esta Petición a todos los Destinatarios con Peticiones Pendientes. 55



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Method: CANCEL Cuando un UAS recibe una Petición CANCEL, este NO DEBE enviar una Respuesta 2XX a la Petición Original.

Cuando Ocurre una Petició Petición CANCEL? Resp. Resp. Cuando el Usuario UAC tranca la llamada antes de que sea finalmente establecida. establecida.


56

28


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequestURI Space SIPSIP-Version CRLF Method: REGISTER El

UAC Registra una Dirección en el SIP Register Server.

La Dirección se especifica en el Campo ‘To’ de las Cabeceras. Campos de la Cabecera: To, From. Request-URI, Call-ID, Cseq y Contact.

57



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF RequestRequest-URI Especifica

el URI del Usuario del registro solicitado.

Ejemplo: sip:[email protected]


58

29


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF SIPSIP-Version Especifica

la Versión de SIP utilizada.

Ejemplo: “SIP/2.0”

59



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Petició Petición A) RequestRequest-Line Method Space RequestRequest-URI Space SIPSIP-Version CRLF Ejemplo, INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 169.130.12.5 From: To: T. A. Watson Call-ID: [email protected] Content-Length: 885 Encryption: PGP version=2.6.2,encoding=ascii


60

30


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta

61



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 1XX “Respuesta Informativa” Informativa” Status Code Definitions Status Code

Significado

RESPUESTA INFORMATIVA

. Respuesta que indica que el

servidor SIP está ejecutando una acción

1XX

Temporaría.

Esto

es, que el establecimiento de la llamada está en proceso y no hay todavía una respuesta definitiva.

100

Trying (Intentando)

180

Ringing (Repicando)

181

Call Is Being Forwarded (Llamada en Proceso de Reenvío) Queued (Llamada Encolada)

182

El Cliente DEBERÍA esperar por futuras Respuestas del Servidor y el Servidor DEBERÏA enviarlas. El Servidor DEBERÍA enviar una Respuesta 1XX si espera tomar mas de 200ms para el Establecimiento Definitivo de la Llamada. El Servidor PUEDE o no enviar Respuestas 1XX. Es Importante que las Respuestas 1XX se envían en Modo No Confirmado (el Cliente NO envía ACK). El Servidor es Libre de Retransmitir Respuestas y el Cliente puede solicitar por su propia cuenta Mensajes de Respuesta 1XX enviando Mensajes Request.


62

31


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 2XX “Respuesta OK” OK” Status Code 2XX

Significado

RESPUESTA OK Exitoso/Successfull

. El Servidor le indica al Cliente que el

Request ha sido

.

200

OK (Succesfully)

La Información Retornada con esta Respuesta depende del Método del Request Empleado.

BYE: Terminación de Llamada. Cuerpo del Mensaje Vacío. CANCEL: Búsqueda Cancelada. Cuerpo del Mensaje Vacío. INVITE: El Llamado se ha Unido a la Sesión (ha Aceptado Unirse). El Cuerpo del Mensaje indica las Capacidades del Llamado. OPTIONS: El Llamado ha Aceptado Compartir sus Capacidades, las cuales están en el Cuerpo del Mensaje. REGISTER: Proceso Exitoso de Registración. Información en el Cuerpo del Mensaje.

63



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 3XX “Respuesta de Redirecció Redirección” Status Code

Significado

RESPUESTA DE REDIRECCIÓN

. Las Respuestas 3XX le

informan al Cliente acerca de la Localización del usuario

Llamado

3XX

ó

Acerca

de

un

Servicio

Alternativo

que

DEBERÍAN

terminar

la

Búsqueda

y

PUEDEN

Iniciar nuevas Búsquedas.

Multiple Choices (Selección Múltiple)

301

Moved Permanently (Movida Permanente)

302

Moved Temporarily (Movida Temporalmente)

está

Disponible para hacer la Llamada. Con esta Respuesta los

Clientes

300

303

Alternative Service (Servicio Alternativo)

305

Use Proxy (Usar Proxy)

380

Queued (Llamada Encolada)

Para Eliminar Lazos de Reenvío, un UAC ó un Proxy DEBEN Chequear que la Dirección de Localización Retornada por el Servidor de Redirección Coincida

o No con Direcciones de Reenvío Transmitidas Anteriormente.


64

32


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 4XX “Error de Cliente” Cliente” Status Code

Significado 400 401 402 403 404 405

4XX

ERROR DE CLIENTE (REQUEST FAILURE).

406 407 408 410 413 414 415

Solicitud Errada No Autorizado Requerimiento Errado Prohibido No Encontrado Método No Permitido No Aceptado Se Requiere Autenticación del Proxy La Solicitud Sobrepaso el Tiempo de Espera Gone Solicitud muy Larga Solicitud URI muy Larga Tipo/Media No Soportado

65



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 4XX “Error de Cliente” Cliente” Status Code

4XX

ERROR DE CLIENTE (REQUEST FAILURE).


416 420 421 423 480 481 482 483 484 485 486 487 488 491 493

Esquema URI NO Soportado Extensión Errada Extensión Requerida Intervalo Algo Breve Temporalmente No Disponible Transacción No Existente Loop Detectado Exceso de Saltos Dirección Incompleta Ambiguo Ocupado Solicitud Terminada Solicitud No Aceptada Solicitud Pendiente Indescifrable

Significado

66

33


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 5XX “Error de Servidor” Servidor” Status Code

Significado 500

5XX

Server Failure (Error en el Servidor).

Server Internal Error (Error Interno del Servidor)

501

Not Implemented (No Implementado)

502

Bad Gateway (Gateway Errado)

503

Service Unavailable (Servicio No Disponible)

504

Gateway Time-Out (Tiempo de Espera Agotado en el Gateway)

505

Version Not Supported (Versión de Protocolo No Soportada)

513

Mensaje muy Largo

67



Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘Status Code’ Code’: 6XX “Error Global” Global” Status Code

6XX

Global Failures (Fallas Globales).


Significado 600

Busy Everywhere (Ocupado en Otra Solicitud)

603

Decline (Declinar)

604

Does Not Exist Anywhere (No Existe el Llamado)

606

Not Acceptable (No Aceptado)

68

34


Ing. José Cotúa

Mensajes SIP Detalles de los Mensajes de Respuesta A) StatusStatus-Line SIPSIP-Version Space StatusStatus-Code Space ReasonReason-Phrase CRLF ‘ReasonReason-Phrase’ Phrase’

Cadena de caracteres ASCII (‘String’) que describe el ‘Status-Code’. Enfoque No Autómata del Proceso. Ideal para Debug en Tiempo Real.

69



Ing. José Cotúa

Protocolo de Señalización SIP (Resumen Rápido)


70

35


Ing. José Cotúa

Resumen Caracterí Características de SIP Integració Integración a ambientes de WEB/INTERNET. Pensado

especialmente para IP.

Modelo Cliente/Servidor. Mensajes de Petició Petición y Respuesta. Reutiliza conceptos de otros servicios como: HTTP, SMTP y DNS. (Basados en Texto Plano).

71



Ing. José Cotúa

Resumen Caracterí Características de SIP Agentes de Usuario: UAC y UAS.

Servidores SIP: Proxy, Registració Registración, Redirecció Redirección y Localizació Localización. Uso de URI’s. Generalmente el Cuerpo de los Mensajes contiene Descripciones de las Sesiones Multimedia. Localización Basada en DNS.


72

36


Ing. José Cotúa

Resumen Caracterí Características de SIP Cabeceras como mé método de Ampliació Ampliación.

Actualmente utiliza SDP como mé método de descripció descripción de sesiones. El mensaje de oferta especifica el conjunto de medios y codecs que se pretende usar.

73



Ing. José Cotúa

Resumen Caracterí Características de SIP El receptor de la oferta genera una respuesta indicando si acepta cada uno de los medios ofertados, y los codecs que admite. Las ofertas/respuestas se pueden intercambiar durante sesiones activas.


74

37


Ing. José Cotúa

Protocolo de Señalización SIP Diferencias entre SIP y H.323

75



Ing. José Cotúa

Diferencias entre SIP y H.323 Las diferencias entre ambos son consecuencia de las

diferencias entre el IETF y la ITUITU-T.

Las diferencias en cuanto a servicios soportados se reducen a medida que se desarrollan nuevas versiones. Mucha propaganda cuando menos inexacta, incluso desde organizaciones aparentemente rigurosas.


76

38


Ing. José Cotúa

Diferencias entre SIP y H.323 Errores frecuentes, por ejemplo: SIP es má más simple.

Los aná análisis comparativos existentes son erró erróneos o no está están actualizados. Las comunidades existentes en torno a SIP y H.323 tienen tradiciones distintas.

77



Ing. José Cotúa

Diferencias entre SIP y H.323 H.323 especifica servicios, mientras que SIP es só sólo un

protocolo de señ señalizació alización para dar base a servicios.

H.323 engloba un amplio conjunto de protocolos de implementació implementación obligatoria. Negociació Negociación de capacidades má más completa y compleja en H.323. H.323 define mecanimos de gestió gestión y administració administración de la red.


78

39


Ing. José Cotúa

Diferencias entre SIP y H.323 En la arquitectura SIP, funciones y servicios como

garantí garantía de calidad, directorio o descripció descripción de sesiones son ortogonales.

SIP está está integrado en la infraestructura web y proporciona servicios de mensajerí mensajería instantá instantánea. SIP tiene mejores mecanismos de detecció detección de bucles, espirales y otros errores de configuració configuración de la red.

79



Ing. José Cotúa

Diferencias entre SIP y H.323 El 3gpp ha señ señalizació alización.

adoptado

SIP

como

protocolo

de

Desde las primeras versiones, el inicio de llamadas es más rapido con SIP.


80

40


Ing. José Cotúa


Ing. José Cotúa

Inter Asterisk eXchange Ing. José Cotúa, Agosto 2007

Capitulo 07(a): Protocolo IAX

1


Ing. José Cotúa

Inter Asterisk eXchange Es

un protocolo diseñado para intercambio de Señalización VoIP entre centrales telefónicas IP Asterisk. Sin embargo, actualmente está siendo utilizado entre otros equipos clientes y/o servidores que no son Asterisk. IAXv2 (IAX2) es la actual versión del protocolo IAX. La versión IAXv1 ya está obsoleta. Está diseñado fundamentalmente para solventar problemas de Barreras NAT’s y para maximizar la eficiencia en el Uso del Ancho de Banda en Llamadas de VoIP.


2


Ing. José Cotúa


Ing. José Cotúa

Inter Asterisk eXchange IAX2 está especialmente pensado para acoplarse directamente a soluciones de IP PABX (Centrales Telefónicas IP) y adaptarse en forma directa al Procesamiento del Plan de Llamadas.

En IAX2 (IAXv1 también) se implementa una Codificación Binaria, en lugar de una Codificación basada en Texto/ASCII como en SIP; lo cual es un aspecto que contribuye a la rapidez de procesamiento de los mensajes/paquetes en el protocolo y además hace que el protocolo consuma marginalmente un menor ancho de banda. Capitulo 07(a): Protocolo IAX

3


Ing. José Cotúa

Inter Asterisk eXchange IAX2

utiliza como UDP como Protocolo de Transporte; Puerto 4569 por defecto. IAXv1 utiliza UDP Puerto 5036.

A diferencia de SIP y H.323, IAX2 utiliza un Solo Canal UDP tanto para la Señalización de VoIP como para Multimedia. Se diferencia la información de señalización y de datos multimedia por el Tipo de Trama que se envía. El hecho de que IAX2 utiliza un solo canal para Señalización y para Multimedia, hace que este protocolo sea mas inmune a a barreras NAT’s y de Firewall’s que se puedan encontrar en la Red IPv4. Capitulo 07(a): Protocolo IAX

4


Ing. José Cotúa


Ing. José Cotúa

Inter Asterisk eXchange

Filosofí Filosofía del Procesamiento de Llamadas en IAX2 y los Mensajes.

a) Establecimiento b) Flujo de Datos Multimedia (M y F) c) Liberación Capitulo 07(a): Protocolo IAX

5


Ing. José Cotúa


Procesamiento de Llamadas con IAX2:

a) Establecimiento: Establecimiento El Llamante envía una Trama ‘NEW’ al Llamado y este responde/confirma la petición con una Trama ‘ACCEPT’; posteriormente el Llamante reconfirma con una Trama ‘ACK’. A continuación el Llamado envía al Llamante una Trama ‘RINGING’ y este responde enviando una Trama ‘ACK’. Cuando se acepta definitivamente la llamada, el Llamado envía una Trama ‘ANSWER’ al Llamante y este le confirma con una Trama ‘ACK’. Capitulo 07(a): Protocolo IAX

6


Ing. José Cotúa


Ing. José Cotúa



b) Flujo de Datos Multimedia: Multimedia Se sustenta en el envío, en ambas direcciones, de Tramas M y F. Tramas M (Mini-Frames): Contienen una Cabecera de 4 Bytes y contienen Data Multimedia (Voz). Tramas F (Frames (Frames)): Tramas de Sincronización. El IAX2 el Flujo de data Multimedia se envía en el mismo Canal UDP donde se envía la Señalización.


7


Ing. José Cotúa



c) Liberació Liberación ó Desconexió Desconexión: Cualquiera de los involucrados, Llamante ó Llamado, puede terminar la llamada enviando una Trama ‘HANGUP’ y esperando una Trama de Confirmación ‘ACK’. Nota: Nota IAX2 destaca por su sencillez y su reducido uso del Ancho de Banda; una de las razones de esto es que UDP tiene una Cabecera menor que TCP y además las Tramas de IAX tienen una Cabecera muy simple y reducida. !!! Capitulo 07(a): Protocolo IAX

8


Ing. José Cotúa


Ing. José Cotúa


Tramas IAX2 Tipo ‘F’ (Full Frame):

Cada Trama F explícitamente.

enviada

debe

ser

respondida


9


Ing. José Cotúa



F (1 Bit): Especifica (Valor = ‘1’) si la Trama es de Tipo ‘F’. Source Call Number - Número de Llamada de origen (15 Bits): Identificación de Origen de la Llamada. IAX2 puede Multiplexar Varias Llamadas en un mismo Canal UDP. R (1 Bit): Bit de Retransmisión, se coloca a ‘1’ en la Trama de F de Respuesta. Destination Call Number - Número de Llamada destino (15 Bits): Análogo al Identificador de Origen de la Llamada. Timestamp o Marca de Tiempo (32 Bits): Marca en Tiempo de Muestreo de la Primera Muestra de los Datos Multimedia.


10


Ing. José Cotúa


Ing. José Cotúa



Oseqno, Sec. de Salida (8Bits): Número de Secuencia de los mensajes de Trama ‘F’. Comienza en ‘0’. Iseqno, Sec. de Entrada (8 Bits): Análogo al anterior, pero de Entrada. Frame Type, Tipo de Trama (8 Bits): Especifica el Tipo de Trama. C (1 Bit): Un Valor de ‘0’ indica que el campo subclase debe tomarse como 7 bits (un solo mensaje): Puesto a 1 indica que el campo subclase se obtiene con 14 bits (dos mensajes consecutivos). Subclass, Subclase del Mensaje: Sub-Clase del Mensaje.

Data: Datos que se envían en formato binario.


11


Ing. José Cotúa


Tramas IAX2 Tipo ‘M’ (Mini Frame):

Contienen Data Multimedia con una Cabecera Reducida (4 Bytes). No Requieren Confirmación.


12


Ing. José Cotúa


Ing. José Cotúa


Tramas IAX2 Tipo ‘M’ (Mini Frame):

El significado de los campos es similar al de las Tramas ‘F’. El Bit F está en ‘0’ y el Timestamp es de solo 16 Bits. Son los clientes los que deben encargarse de llevar un Timestamp de 32 bits si lo desean y para sincronizarlo envían una trama F.


13


Ing. José Cotúa

Inter Asterisk eXchange Tipo de Trama IAX2 Tipo de Trama 1 2 3 4

Descripción DTMF Voz Video Control

5 6

No Usado Control IAX2

7 8 9

Texto Imagen HTML


Observaciones Señalización DTMF El Campo Sub-Clase especifica el Codec de Voz Utilizado El Campo Sub-Clase especifica el Codec de Video Utilizado Mensajes de Control de Sesión. El Campo Sub-Clase especifica el Tipo de Control. Control de Protocolo IAX2. El Campo Sub-Clase especifica el Tipo de Control IAX2.

14


Ing. José Cotúa


Ing. José Cotúa

Inter Asterisk eXchange SubSub-Campo, para Tipo de Trama = 0x02 Tipo de Codec Utilizado Tipo de Codec 0x001 0x002 0x004 0x008 0x080 0x100 0x200 0x400

Descripción del Codec G.723.1 GSM G.711u G.711a LPC10 G.729 Speex iLBC


15


Ing. José Cotúa

Inter Asterisk eXchange SubSub-Campo, para Tipo de Trama = 0x04 Tipo de Control de Sesió Sesión Tipo de Control 0x001 0x002 0x003 0x004 0x005 0x008 0x00E


Descripción del Cotrol HANGUP Llamada Colgada. RING Telefono Repicando. RINGINBACK ANSWER Respuesta. BUSY Usuario Ocupado. CONGESTION Congestión. CALL PROGRESS Llamada en Progreso.

16


Ing. José Cotúa


Ing. José Cotúa

Inter Asterisk eXchange SubSub-Campo, para Tipo de Trama = 0x06 Tipo de Control IAX2 Tipo de Control 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

NEW PING PONG ACK HANGUP REJECT ACCEPT AUTHREQ AUTHREP INVAL LAGRQ LAGRP REGREQ REGAUTH REGACK REGREJ

Descripción del Cotrol Inicio de Llamada. Envío de PING. Respuesta de PING. Confirmación ACK. Inicio de Desconexión. Mensaje de Rechazo. Mensaje de Aceptación. Petición de Autenticación. Respuesta de Autenticación. Llamada Inválida. Petición de LAG. Respuesta de LAG. Petición de Registro. Autenticación de Registro. Confirmación de Registro. Negación de Registro.


17


Ing. José Cotúa

Inter Asterisk eXchange SubSub-Campo, para Tipo de Trama = 0x06 Tipo de Control IAX2 Tipo de Control 17 18 19 20 21 22 23 24 25 26 27 28 29 32 33

REGREL VNAK DPREQ DPREP DIAL TXREG TXCNT TXACC TXREADY TXREL TXREJ QUELCH UNQUELCH MWI UNSUPPORT


Descripción del Cotrol Liberación de Registro. Petición de Retransmisión. Petición de 'DIALPLAN'. Respuesta de 'DIALPLAN'. Marcado. Petición de Transferencia. Conexión de Transferencia. Aceptación de Transferencia. Transferencia Preparada. Liberación de Transferencia. Rechazo de Transferencia. Detiene Transmisión de Audio. Continua Transmisión de Audio. Indicador de Mensaje de Espera. Mensaje No Soportado.

18


Ing. José Cotúa


Ing. José Cotúa

Inter Asterisk eXchange Comparació Comparación de IAX2 con SIP SIP

IAX2

Está Estándar IETF (RFC (RFC’’s)

Mark Spencer (Asterisk) Asterisk)

Codificació Codificación ASCII/Texto

Codificació Codificación Binaria

Ancho de Banda (-(--))

Ancho de Banda (--(---))

Canal SIP de Señ Señalizació alización UDP y Canal de Multimedia UDP

Un solo Canal UDP para Señ Señalizació alización y Multimedia

Efecto de Bareras NAT’ NAT’s y Firewall (--) --)

Efecto de Barreras NAT’ NAT’s y Firewall (---) ---)

Puerto UDP 5060, para Señ Señalizació alización

Puerto UDP 4569 para Todo


19


Ing. José Cotúa

Inter Asterisk eXchange Comparació Comparación de IAX2 con SIP SIP

IAX2

Soporta Redireccionamiento; Redireccionamiento; Flujo Multimedia de Extremo a Extremo

No Soporta Redireccionamiento; Redireccionamiento; dado que la Multimedia va Multiplexada en el mismo Canal de Señ Señalizació alización

Funcionalidades: Voz, Video, Juegos, etc. (Sesiones)


Funcionalidades Especiales para IPIP-PABX: Gestió Gestión de ‘DIALPLAN’ DIALPLAN’

20


Ing. José Cotúa


Ing. José Cotúa

Protocolo Skinny No es un estándar; es un Protocolo Propietario (Cisco). No es Inter-Operable entre Marcas/Modelos. Tráfico de Mensajes de Señalización y Multimedia VoIP entre Clientes y el Servidor ‘Call-Manager’. El ‘Call Manager’ actúa como un Proxy ‘Intermediario’ de Señalización de Llamadas entre los Clientes Cisco (Cisco Serie 7900). Utiliza TCP para Señalización y RTP/RTCP para Multimedia. Codificado en Binario (Códigos de Mensajes) Capitulo 07(a): Protocolo IAX

21


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Ing. José Cotúa, Agosto 2007

Capítulo VIII: Calidad de Servicio QoS

1


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Definició Definición Se entiende por QoS a todas aquellos procedimientos, técnicas, herramientas, estándares y/o políticas que aplicadas sobre los elementos de conmutación (capa 2 y capa 3) de una red basada en enrutamiento IP afectan el tráfico de los paquetes IP en función de dos aspectos fundamentales: • Retardo en Conexiones ‘End to End’ End’ • Ancho de Banda • Jitter (Variació (Variación del Retardo) • Pérdida de Paquetes


2

1


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Aspectos a Considerar La Red IPv4 no está pensada para tráfico de Data Multimedia (Voz/Audio/Video) las cuales son altamente sensibles a la Temporización. TCP asegura Conexiones Fiables con mecanismos de Entrega Correcta de Paquetes; sin embargo en TCP las conexiones tienen un retardo considerable que a las aplicaciones de Voz las afecta significativamente. Por tal motivo es que se utiliza UDP para Tráfico de Voz y Multimedia sobre IPv4.


3


Ing. José Cotúa

Calidad de Servicio QoS en VoIP ¿Cómo se Implementa QoS? QoS? Identificación y Clasificación del Tráfico IPv4. Definición de Políticas y Estratégias de Control. Definición de Niveles de Servicio. Implementación de Reglas y Políticas de Control y aseguramiento de QoS. ¿Dónde se implemnta QoS? Capa 2: Switch’s Capa 3: Encaminadores


4

2


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Definiciones Retardo (Latencia): Tiempo, medido en Milisengundos, que tarda un Paquete IPv4 en llegar desde su origen a su destino. ¿De que depende? Características de los Enlaces. Nivel de Tráfico y Congestión. Tamaño de los paquetes. Para VoIP (Full Duplex): Menor o igual a 150ms. !!!


5


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Definiciones Jitter: Variación en el tiempo en la llegada de los paquetes, causada por congestión de red, perdida de sincronización o por las diferentes rutas seguidas por los paquetes para llegar al destino. ¿De que depende? La No Uniformidad del Tráfico en la Red IPv4. Para VoIP (Full Duplex): Menor o igual a 100ms. !!!


6

3


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Definiciones Packet Loss (%): Pérdida Porcentual de Paquetes IPv4 de la Conexión VoIP. Para VoIP (Full Duplex): Menor o igual a 5% (Depende del Codec) Procesos de Corrección asociados: Compresión de Silencio. Supresión de ECO.


7


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Definiciones Eco: se define como una reflexión retardada de la señal acustica original. Para VoIP: que llegue a 65ms y con una Atenuación Mínima de entre 25 y 30dB. Procesos Asociados: - Supresores de ECO. - Cancelación de ECO.


8

4


Ing. José Cotúa

Calidad de Servicio QoS en VoIP Protocolos de QoS Protocolo de Reserva de Recursos: RSVP (Servicios Integrados). Protocolo de Servicios Diferenciados (DiffServ) y TOS. MPLS. IP QoS. IEEE 802.1Q. Control de Congestión y Políticas de Encolamiento.


9

5


Ing. José Cotúa

Aplicaciones de VoIP Ing. José José Cotú Cotúa, Agosto 2007

1

Capitulo IX: Aplicaciones de VoIP


Ing. José Cotúa

Aplicaciones de VoIP VoIP y la Telefonía Analógica y Digital Tradicional (PSTN) Telefoní Telefonía Analó Analógica Tradicional: - Puertos FXS - Puertos FXO - Puertos E&M Telefonía Digital Tradicional: - Puertos E1/T1 - Puertos ISDN (BRI/PRI)


Para Integrar la Telefonía Tradicional a VoIP se necesita: • En H.323: Gateway’s • En SIP e IAX2: Adaptadores • En MGCP y MEGACO: Media Gateway’s

2

1


Ing. José Cotúa

Aplicaciones de VoIP Teléfonos IP HardHard-Phone IP (Telé (Teléfonos IP): los hay para SIP, H.323 e IAX2. WirelessWireless-Phone IP (Telé (Teléfonos IP Inalá Inalámbricos): los hay en IEEE 802.11a/b/g Software): teléfonos IP, SIP/IAX2/H.323, que se Software-Phone IP (Softphone (Softphone): ejecutan como Aplicaciones en Sistemas Operativos GNU/Linux, Windows, MAC OS X, etc. Características: Pueden incluir soporte para Video IP. Disponen de Funciones de Valor Agregado como Agendas, Menúes, etc. Pueden tener Varias Líneas FXO asociadas. Configurables vía WEB/HTTP ó con Menú. 3



Ing. José Cotúa

Aplicaciones de VoIP Servicios de Fax en VoIP Soportado con el Protocolo T.38 de la ITU-T. Se recomienda Codec’s G.711a/u para Soporte Nativo de FAX en VoIP. Las Aplicaciones de IVR y IP-PABX pueden dar Soporte Automatizado a TX/RX de FAX con INPUT/OUTPUT a/de Formado PDF y con opciones de Envío Automatizado de email’s.


4

2


Ing. José Cotúa

Aplicaciones de VoIP VoIP para Radiocomunicación Móvil Terrestre Radiocomunicación Móvil Terrestre, Tradicional: Señalización y Voz Analógica Trunking (Smartnet, Smartnet, Smartzone, Smartzone, etc.): Señalización Digital y Voz Analógica Smartrunk: Smartrunk: Señalización Digital y Voz Analógica. Migración de Tradicional a Trunking. Sistema Mixto. Tetra: Tetra: Señalización y Voz Digitalizada. Sistemas en VFH, UHF, 800MHz y 900MHz. 5



Ing. José Cotúa

Aplicaciones de VoIP VoIP para Radiocomunicación Móvil Terrestre


6

3


Ing. José Cotúa

Aplicaciones de VoIP VoIP para Radiocomunicación Móvil Terrestre

7



Ing. José Cotúa

Aplicaciones de VoIP VoIP para Radiocomunicación Móvil Terrestre Otras Alternativas.Alternativas. Diseño propio Embedidos.

con

Microcontroladores

y/o

Sistemas

Utilizar Gateway’s y/o Adaptadores y crear nuevas Soluciones. IP-PABX Asterisk ya dispone de Módulos para VoIP basada en PTT.


8

4


Ing. José Cotúa

Aplicaciones de VoIP VoIP y Redes VPN Protocolos para Redes VPN IPSec

Aspectos a Considerar La VPN introduce Retardo.

OpenVPN

‘Overhead’ e Incremento Ancho de Banda.

VTUN L2TP

El Cifrado de la VPN.

Túneles GRE

VPN con Compresión.

Túneles IPv4/IPv6 Otros: PPtP, EoIP, Bridge’s, etc.

Aspectos de Firewall y NAT’s. 9



Ing. José Cotúa

Aplicaciones de VoIP Otras Aplicaciones VoIP en Telefonía Celular (Próxima Generación) Call Center’s y Nuevos Proveedores. Servicios de Valor Agregado en VoIP: Bases de Datos, IVR’s y RADIUS. VoIP para Intercomunicacores Digitales. VoIP para Estaciones de Radio FM/AM. Radio AM/FM en INTERNET.


10

5


Ing. José Cotúa

Aplicaciones de VoIP VoIP sobre INTERNET, Consideraciones Acceso a INTERNET:

- Garantizado/Dedicado ó Compartido? - Simétrico ó Asimétrico? - Asignación de IPv4 Reales/Fijas/certificadas? - Asignación estática ó DHCP?

11



Ing. José Cotúa

Aplicaciones de VoIP VoIP sobre INTERNET, Consideraciones Acceso a INTERNET:

- Cuál es el Ancho de Banda Disponible? - Cuál es el consumo WEB/HTTP Estimado de la Red, Número de Usuarios? - Que Codec’s y Protocolos voy a Utilizar? - Como es la Topología Virtual? - Que tipo de Acceso tengo: Inalámbrico, ADSL/ADSL2/ADSL2+, Fibra, etc.? Capitulo IX: Aplicaciones de VoIP

12

6


Ing. José Cotúa

Aplicaciones de VoIP Otras Tecnologías de Voz sobre Paquetes Voz sobre ATM: VoATM. Voz sobre Frame Relay: VoFR. Voz sobre MPLS: VoMPLS. Voz sobre Ethernet: VoETH.


13

7

curso telefonia ip

Recommend Documents