Arquitectura de Protocolos TCP/IP - Blog...

1

1

VoIP y Telefonía IP Ing. José Cotúa

Capítulo I: Arquitectura de Protocolos TCP/IP

Arquitectura de Arquitectura de

Protocolos TCP/IPProtocolos TCP/IP

Ing. José Cotúa, Agosto 2007

2



El Modelo de Referencia OSIEl Modelo de Referencia OSI

Layer 7: Aplicación

Layer 5: Sesión

Layer 6: Presentación

Layer 4: Transporte

Layer 1: Enlace

Layer 3: Red

Layer 1: Física

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

TCP, UDP, IPSec, OSPF

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

IPv4 , IPv6/IPng

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

Network

2

3



El Modelo de Referencia TCP/IPEl Modelo de Referencia TCP/IP

Aplicación

Transporte

Enlace/Acceso

Red

Física

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

TCP, UDP, IPSec, OSPF

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

IPv4 , IPv6/IPng

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

Network

4



Redes de ConmutaciRedes de Conmutacióón de Circuitosn de Circuitos

� Capacidad Dedicada entre Usuarios.

� Sincronización.

� Mayor confiabilidad y No requiere procedimientos de Re-Transmisión.

� Sistema de Acceso bajo demando ó Secuencial.

3

5



Redes de ConmutaciRedes de Conmutacióón de Paquetesn de Paquetes

Red IP

Origen

Destino

Destino

Origen

Paquetes/Datagramas: Entidades de Data que contienen una Cabecera y una Data Asociada.

6



EthernetEthernet IEEE 802.3 (Capa de Enlace)IEEE 802.3 (Capa de Enlace)

7 bytes 6 bytes 6 bytesde 46 a 1500

bytes4 bytes2

byt

es

preámbulo dirección de destino

dirección de origen

campo de datos

framecheck sequencelo

ng

itu

d

del

imit

ado

r

relle

no

.

1 byte

cam

po

d

e ti

po

� Ethernet 10Base5

� Ethernet 10Base2

� Ethernet 10/100/1000/10000BaseT

� Ethernet 10Base-FP

4

7



Otros Protocolos de Capa de EnlaceOtros Protocolos de Capa de Enlace

� Token Ring

� ATM

� Franme Relay

� IPX/SPX

� IEEE 802.1Q y IEEE 802.1P

8



Direccionamiento Direccionamiento IPv4IPv4Protocolo de Internet, VersiProtocolo de Internet, Versióón 4n 4

Redes Basadas en una Arquitectura de Direccionamiento IPv4

Direcciones IPv4 y Enrutamiento

Asignación de Direcciones IPv4 y Familias IPv4

5

9



Aspectos GeneralesAspectos Generales

•• EstEstáándar IETF, Documento RFC791 (1981).ndar IETF, Documento RFC791 (1981).

•• Protocolo Oficial para INTERNET.Protocolo Oficial para INTERNET.

•• Se Fundamenta el Uso de las Direcciones IP. Se Fundamenta el Uso de las Direcciones IP.

•• Es un Protocolo de Red, Capa 3 del Modelo OSI y el Modelo Es un Protocolo de Red, Capa 3 del Modelo OSI y el Modelo TCP/IP.TCP/IP.

•• Es un Protocolo No Confiable, No Confirmado. Es un Protocolo No Confiable, No Confirmado.

•• Es un Protocolo No Orientado a ConexiEs un Protocolo No Orientado a Conexióón.n.

•• Es un Protocolo Es un Protocolo EnrutableEnrutable..

•• Trabaja bajo el Criterio Trabaja bajo el Criterio ‘‘TheThe Best Best EffortEffort’’. .

•• PrPróóxima Generacixima Generacióón => n => IPv6IPv6 óó IpngIpng (IETF, 1996). (IETF, 1996).

Direccionamiento IPv4

10



El Protocolo de Internet, VersiEl Protocolo de Internet, Versióón 4n 4

31 24 23 16 15 8 7 0

ESTRUCTURA DE UNA DIRECCIÓN IPv4

Octeto 3 Octeto 2 Octeto 1 Octeto 0

8 Bits 8 Bits 8 Bits 8 Bits

32 Bits

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

6

11



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,Ejemplos,

Las siguientes son Direcciones Las siguientes son Direcciones IPv4IPv4::

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 Las siguientes NO son Direcciones IPv4IPv4::

10.10.25.300 10.10.10.256

25.130.256.285 1000.200.257.300

12



0.0.0.0

0.0.0.255

0.0.1.0

0.0.0.1.255

0.1.0.0

0.1.255.255

255.255.255.255

Rango Total de Direcciones IPv4

• Se Identifican y Define Bloques que Contienen Se Identifican y Define Bloques que Contienen siempre 2siempre 2NN Direcciones Direcciones IPv4IPv4 Contiguas. Contiguas.

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

7

13



DivisiDivisióón de las Direcciones n de las Direcciones IPv4IPv4 por Clasespor Clases

31 24 23 16 15 8 7 0

Direcciones IPv4 Clase A 0Bloque Clase A Reservado para Loopback

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 0

ID-RED (21 Bits) ID-HOST (8 Bits)

ID-GRUPO_MULTICAST (28 Bits)

ID-RESERVADO USO FUTURO (27 Bits)



127 ID-Dirección LOOPBACK

ESTRUCTURA DE UNA DIRECCIÓN IPv4

Octeto 3 Octeto 2 Octeto 1 Octeto 0

8 Bits 8 Bits 8 Bits 8 Bits

32 Bits

14



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.

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

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

0 7 bits: ID de Red 24 bits: ID de Host

8

15



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.

1 0 14 bits: ID de Red 16 bits: ID de Host

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

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

16



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.

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

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

1 1 0 21 bits: ID de Red 8 bits: ID de Host

9

17



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

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

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

1 1 1 0 28 bits: ID de Grupo Multicast

18



Direcciones IPv4 Clase E

� Reservadas por la IANA para Uso Futuro/Experimental.

� Familia IPv4 Clase E: 240.0.0.0 � 247.255.255.255

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

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

1 1 1 1 27 bits: Reservados0

10

19



Direcciones IPv4 para Interfaces ‘Loopback’

� Todo Host que hable IPv4 tiene una Interfaz Virtual, llamada Interfaz de Loopback ‘lo’, con asignación de Direcciones IPv4de 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 !!!

20



Bloques de Direcciones Bloques de Direcciones IPv4IPv4 y Familias y Familias IPv4IPv4

• 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 MMááscara de Redscara de Red.

• Un Bloque IPv4 de Tamaño 2N, SIEMPRE debe comenzar en una Dirección IPv4Múltiplo de 2N.

MMááscara de Redscara de 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.

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

Formato y Estructura de una Máscara de Red

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

11

21




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

Formato y Estructura de una Máscara de Red


Decimal Binario

255 11111111

254 11111110

252 11111100

248 11111000

240 11110000

224 11100000

192 11000000

128 10000000

0 00000000

22




Si MM es el Número de Bits en ‘1’ que tiene la Máscara de Red, entonces 22MM es el TamaTamañño de la Familia o de la Familia IPv4IPv4 o Bloque IPv4 al que hace Referencia.

Tamaño de la Familia IPv4

255 . 255 . 255 . 255 / 32 1

255 . 255 . 255 . 254 / 31 2

255 . 255 . 255 . 252 / 30 4

255 . 255 . 255 . 248 / 29 8

255 . 255 . 255 . 240 / 25 128

255 . 255 . 255 . 224 / 27 32

255 . 255 . 255 . 192 / 26 64

255 . 255 . 255 . 128 / 25 128

255 . 255 . 255 . 0 / 24 256

255 . 255 . 254 . 0 / 23 512

255 . 255 . 252 . 0 / 22 1.024

255 . 255 . 248 . 0 / 21 2.048

255 . 255 . 240 . 0 / 20 4.096

255 . 255 . 224 . 0 / 19 8.192

255 . 255 . 192 . 0 / 18 16.384

255 . 255 . 128 . 0 / 17 32.768

255 . 255 . 0 . 0 / 16 65.536

255 . 254 . 0 . 0 / 15 131.072

255 . 252 . 0 . 0 / 14 262.144

255 . 248 . 0 . 0 / 13 524.288

255 . 240 . 0 . 0 / 12 1.048.576

255 . 224 . 0 . 0 / 11 2.097.152

255 . 192 . 0 . 0 / 10 4.194.304

255 . 128 . 0 . 0 / 9 8.388.608

255 . 0 . 0 . 0 / 8 16.777.216

254 . 0 . 0 . 0 / 7 33.554.432

252 . 0 . 0 . 0 / 6 67.108.864

248 . 0 . 0 . 0 / 5 134.217.728

240 . 0 . 0 . 0 / 4 268.435.456

224 . 0 . 0 . 0 / 3 536.870.912

192 . 0 . 0 . 0 / 2 1.073.741.824

128 . 0 . 0 . 0 / 1 2.147.483.648

0 . 0 . 0 . 0 / 0 4.294.967.296

Formato Base 256 Formato CIDR (/M)

¡¡¡¡ 33 M33 Mááscaras de Red Posibles en scaras de Red Posibles en IPv4IPv4 !!!!

12

23




Si MM es el Número de Bits en ‘1’ que tiene la Máscara de Red, entonces 22MM es el TamaTamañño de la Familia o de la Familia IPv4IPv4 o Bloque IPv4 al que hace Referencia.

¡¡¡¡ 33 M33 Mááscaras de Red Posibles en scaras de Red Posibles en IPv4IPv4 !!!!

253111256255.255.255.0/24

125111128255.255.255.128/25

6111164255.255.255.192/26

2911132255.255.255.224/27

1311116255.255.255.240/28

51118255.255.255.248/29

1114255.255.255.252/30

********2255.255.255.254/31

********1255.255.255.255/32

RestantesIP DGWIP BroadcastIP FamiliaTotalesDecimalBarra

Total Direcciones IPMáscara de Red

24



Bloques de Direcciones Bloques de Direcciones IPv4IPv4 y y FmiliasFmilias IPv4IPv4

En una Familia IPv4 se especifica entonces con una Dirección IPv4 (Identificador IPv4de 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:

IPv4IPv4_Familia = (_Familia = (AnyAny--Dir_IPv4Dir_IPv4) ) And_BitsAnd_Bits ((MaskMask) ) EcEc. 1. 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 Hostde la Red.

• En Toda Familia IPv4 se Define una Dirección IPv4 Especial llamada DirecciDireccióón IP de n IP de BroadcastBroadcast (IPv4_Broadcast) de la Familia IP. Esta, es SIEMPRE la Última Dirección IPv4 del Bloque. Se calcula así,

IPv4IPv4__BroadcastBroadcast = (= (AnyAny--Dir_IPv4Dir_IPv4) ) Or_BitsOr_Bits ((MaskMask’’) ) EcEc. 2. 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.

13

25




�� Ejemplo de una Familia Ejemplo de una Familia IPv4IPv4..

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,

DesdeDesde: 200.47.50.0 (Esta Dirección NO se DEBE Asignar)

200.47.50.1

…

200.47.50.254

HastaHasta: 200.47.50.255 (Esta Dirección IP NO se DEBE Asignar)

Se Identifica la Familia IPv4 así:

200.47.50.0 /24200.47.50.0 /24

Note que Solo Tengo, en este caso, 254 Direcciones IPv4

para Asignar !!!

26




�� Ejemplo de una Familia Ejemplo de una Familia IPv4IPv4..

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

14

27



Tamaño IPv4 Asignables255 . 255 . 255 . 255 / 32 1 N/A

255 . 255 . 255 . 254 / 31 2 N/A

255 . 255 . 255 . 252 / 30 4 2

255 . 255 . 255 . 248 / 29 8 6

255 . 255 . 255 . 240 / 25 128 126

255 . 255 . 255 . 224 / 27 32 30255 . 255 . 255 . 192 / 26 64 62

255 . 255 . 255 . 128 / 25 128 126255 . 255 . 255 . 0 / 24 256 254

255 . 255 . 254 . 0 / 23 512 510

255 . 255 . 252 . 0 / 22 1.024 1.022

255 . 255 . 248 . 0 / 21 2.048 2.046

255 . 255 . 240 . 0 / 20 4.096 4.094

255 . 255 . 224 . 0 / 19 8.192 8.190

255 . 255 . 192 . 0 / 18 16.384 16.382

255 . 255 . 128 . 0 / 17 32.768 32.766

255 . 255 . 0 . 0 / 16 65.536 65.534

255 . 254 . 0 . 0 / 15 131.072 131.070

255 . 252 . 0 . 0 / 14 262.144 262.142

255 . 248 . 0 . 0 / 13 524.288 524.286

255 . 240 . 0 . 0 / 12 1.048.576 1.048.574

255 . 224 . 0 . 0 / 11 2.097.152 2.097.150

255 . 192 . 0 . 0 / 10 4.194.304 4.194.302

255 . 128 . 0 . 0 / 9 8.388.608 8.388.606

255 . 0 . 0 . 0 / 8 16.777.216 16.777.214

254 . 0 . 0 . 0 / 7 33.554.432 33.554.430

252 . 0 . 0 . 0 / 6 67.108.864 67.108.862

248 . 0 . 0 . 0 / 5 134.217.728 134.217.726

240 . 0 . 0 . 0 / 4 268.435.456 268.435.454

224 . 0 . 0 . 0 / 3 536.870.912 536.870.910

192 . 0 . 0 . 0 / 2 1.073.741.824 1.073.741.822

128 . 0 . 0 . 0 / 1 2.147.483.648 2.147.483.646

0 . 0 . 0 . 0 / 0 4.294.967.296 4.294.967.294

Formato Base 256 Formato CIDR (/M)

28



Otros Ejemplos de Familias Otros Ejemplos de Familias IPv4IPv410.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

15

29



La Familia La Familia IPv4IPv4 y la My la Mááscara de Redscara 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

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 (MEjemplo, la Red 10.0.64.0 /22 (Mááscara de Red /22, 255.255.252.0) !!!scara de Red /22, 255.255.252.0) !!!

30



La IANA (La IANA (httphttp://://www.iana.orgwww.iana.org))

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

multicastmulticast--addressesaddresses

portport--numbersnumbers

16

31



ClasificaciClasificacióón de las Direcciones n de las Direcciones IPv4IPv4 segsegúún la IANAn la IANA

Direcciones Direcciones IPv4IPv4 PrivadasPrivadas

• 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 Direcciones IPv4IPv4 de de LoopbackLoopback

• El Bloque 127.0.0.0/8, se Reserva su Uso Exclusivamente para Interfaces de Loopback (lo).

Direcciones Direcciones IPv4IPv4 de Uso Reservadode Uso Reservado

• Clase E: 240.0.0.0 �� 247.255.255.255

Direcciones Direcciones IPv4IPv4 PPúúblicas, Reales, Certificadasblicas, 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.

32



AsignaciAsignacióón de Direcciones n de Direcciones IPv4IPv4

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 IPv4en un Host; para evitar Problemas de Inestabilidad.

17

33



AsignaciAsignacióón de Direcciones n de Direcciones IPv4IPv4B) 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.

34



Escenario de Escenario de IPv4IPv4 en INTERNET para Redes Privadasen INTERNET para Redes PrivadasNAT’s y Enmascaramiento: Paño Caliente

El Ideal: Conexiones IP End To End

Red LAN

Protocolo TCP/IP

Familia IP

Router WAN / LAN

ISP / WISPInternetTCP/IP

18

35



Conexiones TCP y UDPConexiones TCP y UDP• 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

TCP UDP

ICMP IP IGMP

ARP Interfaz RARP

proc. de

usuario

proc. de

usuario

proc. de

usuario

proc. de

usuario

Red / Medio

Aplicación

Transporte

Red

Enlace

36



Protocolo TCPProtocolo 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 !!!

19

37



Protocolo UDPProtocolo 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; PuertosUDP: 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 !!!

38



Funciones de NAT y EnrutamientoFunciones 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

1

1


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

Análisis de la Señal de Voz

José Cotúa, Agosto 2007

2




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

2

3




Transductores (Conversión de Tipos de Señal)

De Acústica a Eléctrica: Micrófonos

De Eléctrica a Acústica: Cornetas

4



Análisis de la Señal de VozAná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 predecirsu valor en tiempo, pero podemos entender y explicar sucomportamiento.

� Señal No Periódica (Aperiódica).

� Señal que padece del Fenómeno de Irreversibilidad.

� Descrita Técnicamente con: Vprom (Vdc), Vrms, Vmax, Vminy Vpp

t

3

5



Análisis de la Señal de VozAná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:

t

∫

∫

=

==

−=

=

−

0

2

0

)(

)(

T

T

DCPROMEDIO

MINMAXPICOPICO

MAXPICO

dttXVRMS

dttXVV

VVV

VV

6



Análisis de la Señal de VozAná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.

4

7



Análisis de la Señal de VozAná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 !!).

FmaxFmax para Voz para Voz �� 4KHz4KHz

FmaxFmax para Audio para Audio �� hasta 22KHzhasta 22KHz

8



Análisis de la Señal de VozAcondicionamiento 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 ’

5

9



Análisis de la Señal de VozAcondicionamiento 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

10



Análisis de la Señal de VozEl 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).

6

11




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.

12




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.

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 frecuenciade muestreo).

TEOREMA DEL MUESTREO, NYQUIST:

7

13



Análisis de la Señal de VozEl 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.

14




Mensaje

SeñalcuantificadaCon Q=8

8

15




Mensaje


16




Mensaje


9

17




Mensaje


18




10

19




20




Niveles de Cuantificación (L) → Número de Bits por Muestra (n).

11

21



Análisis de la Señal de VozEl 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.

22



Análisis de la Señal de VozEl 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 ‘

12

23




Algunas ComparacionesSeñ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

TelefonTelefoníía (Voz)a (Voz) 200200--40004000 8KHz8KHz 8KHz8KHz 88 6464

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

1

1


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

CODEC’s de VoIP

Ing. JosIng. Joséé G. CotG. Cotúúa, Agosto 2007a, Agosto 2007

2



CODEC’s de VoIP

�� CodecCodec: Codificador : Codificador -- Decodificador Decodificador

�� Encargado de los Procesos de:Encargado de los Procesos de:

�� FiltradoFiltrado

�� Muestreo y RetenciMuestreo y Retencióónn

�� CuantificaciCuantificacióónn

�� CodificaciCodificacióónn

�� CompresiCompresióónn

�� EncriptamientoEncriptamiento

�� EmpaquetamientoEmpaquetamiento

2

3



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)

CODEC’s de VoIP

4




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

CODEC’s de VoIP

3

5




� 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 adicional al procesamiento de la Señal de Voz/Audio: Empaquetamiento.

�Si la comunicación de voz/audio es full-duplex, el proceso de CODEC es bidireccional.

� Fenómeno de Irreversibilidad de la Voz.

CODEC’s de VoIP

6




� Conceptos de Compresión Perceptiva.

� La Red IP: IPv4 ó IPv4/Ipng; Pérdida de Paquetes, Jitter, Retardo, Multienrutamiento, Desordenamiento (Desincroníade 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.

CODEC’s de VoIP

4

7




� 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 Sub-Audibles, 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.

CODEC’s de VoIP

8




� 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…..!!!!

CODEC’s de VoIP

5

9




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

CODEC’s de VoIP

10



Voz/Audio

Analógica

PBN: IP

CODEC

Digitalización: 64 KBPS

- Filtrado (Filter).

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

- Cuantificación (Cuantization).

- Codificación (Codification).

AnalogAnalog

?? KBPS

Paquetes UDP/IP/Ethernet

Compresión

Media Stream

CODEC de VoIPCODEC de VoIP

VisualizaciVisualizacióón del Proceson del Proceso

DigitalDigital

PacketsPackets

6

11



Estructura Funcional de un CODEC de VoIPEstructura Funcional de un CODEC de VoIP

Filter/Sample/Hold Cuantificación Codificación

Codificación PCM

Voz

Compresión

Algoritmo

Interface

KBPS_OUT_Interface

PPS_OUT_Interface

Media Stream

KBPS_OUT_Algoritmo

Empaquetamiento

KBPSTípico

BWFS

N

NFSNFSfPCMKBPS

n

64 :

2

2

*),(_

≥

=

==

oritmoAOutKBPS

PCMKBPSKoritmoACompresiónFactor

lg__

_:1lg__ ==

11000…11100 11000…11100

Frame N Frame N+1

vmin, vmax, vprom, vrms, fmax (BW)

Fs: Frecuencia de Muestreo

Ts � Fs (8 KHz)

N: Número de Bits por Muestra

(N = 8)

KBPS_IN_Algoritmo

• Tamaño del Frame, en MS ó en Bytes: Frame

• Tamaño del Payload: PAYLOAD.

• Requerimientos de PPS: PPS.

• Factor de Compresión: K.

• Retardo Intrínseco: RETARDO.

UDPIPv4ETH RTP

PCMPCM

DPCMDPCM

ADPCMADPCM

12



Compresión

Algoritmo

IN: KBPS_PCM

Típico: 64KBPSOUT: KBPS_Out_Algoritmo

Típico: << 64KBPS

� El Procesamiento es COMPLETAMENTE Digital: Algoritmo/Software/DSP.

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

El Algoritmo de CompresiEl Algoritmo de Compresióónn

7

13



ParametrizaciParametrizacióón del Algoritmo (CODEC)n del Algoritmo (CODEC)

� Frecuencia 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)

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

�� FrameFrame en en BytesBytes: : Frame(ms) * FS(KHZ).

14




�� Payload: Número de Bytes de Data de Voz/Audio enviados por cada Paquete RTP/UDP. Se puede Expresar también en ms.

� K_FrameK_Frame:: Número de Frames por Payload.

� PPS: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 !!.PPS: Requerimiento de Ancho de Banda Real !!.

8

15




� Delay: Retardo Introducido por el Algoritmo desde que se Muestrea la Señal de Voz hasta que se dispone del ‘StreamMedia 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 SeEl Sacrificio: La Calidad de la Seññal de Voz al de Voz Recuperada !!Recuperada !!

16



El Proceso de EmpaquetamientoEl Proceso de Empaquetamiento

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

IN: KBPS_Algoritmo

Típico: << 64KBPSOUT: KBPS_Out_Interface

Típico: < 64KBPS

> 64 KBPS !!Empaquetamiento

IPv4UDPRTP ETH

9

17




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

IN: KBPS_Algoritmo


Típico: < 64KBPS


IPv4UDPRTP ETH

!! !! KBPS_InterfaceKBPS_Interface >> >> KBPS_AlgoritmoKBPS_Algoritmo ¡¡¡¡!! Los Protocolos A!! Los Protocolos Aññaden Control, pero Cobran KBPS aden Control, pero Cobran KBPS ¡¡¡¡

18



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

Cabecera RTP:Cabecera RTP: 12 12 BytesBytes.. ¡¡¡¡ Requerimientos de Real Time Requerimientos de Real Time ProtocolProtocol……

Cabecera UDP:Cabecera UDP: 8 8 BytesBytes.. ¡¡¡¡ Requerimientos de TransporteRequerimientos de Transporte……

Cabecera IPv4:Cabecera IPv4: 20 20 BytesBytes. . ¡¡¡¡ Requerimientos de Requerimientos de RedRed……

Ethernet Capa 2:Ethernet Capa 2: 26 26 BytesBytes.. ¡¡¡¡ Requerimientos de Enlace e Requerimientos de Enlace e InterfaceInterface……

De forma que,

Total_Header(RTPTotal_Header(RTP+UDP+IPv4+ETH) = 66 +UDP+IPv4+ETH) = 66 BytesBytes. .

Total_Packet_BytesTotal_Packet_Bytes = = Voice_PayloadVoice_Payload + + Total_Header(RTPTotal_Header(RTP+UDP+IPv4+ETH)+UDP+IPv4+ETH)

Donde, Voice_Payload= K*Frame(Bytes). Típico: K: 1, 2 ó 3.

Algoritmo de Compresión

OSI Protocolos


IN: KBPS_Algoritmo


Típico: < 64KBPS


IPv4UDPRTP ETH

10

19



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.

El Proceso de EmpaquetamientoEl Proceso de EmpaquetamientoIN: KBPS_Algoritmo


Típico: < 64KBPS


IPv4UDPRTP ETH

20



Protocolo RTPProtocolo RTP

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

P X M

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

Formato de la Cabecera RTP

Multimedia Data

Timestamp

Synchronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifiers

V=2 CC PT Seq

Cabecera de Extensión RTP


Bits / Bytes de Información

1 Byte 1 Byte 1 Byte

User Defined Length

Header Extension (Longitud Variable)

1 Byte


1 Byte 1 Byte 1 Byte 1 Byte

…

Cabecera RTP (normalmente):Cabecera RTP (normalmente): 12 Bytes

PayloadPayload del CODEC:del CODEC: X Bytes

TamaTamañño del Paquete RTP:o del Paquete RTP: (12 + X) Bytes

11

21



Protocolo UDPProtocolo UDP

Cabecera UDP:Cabecera UDP: 8 Bytes

Paquete RTP:Paquete RTP: (12 + X) Bytes

TamaTamañño del Paquete UDP:o del Paquete UDP: (20 + X) Bytes

0000 1111 2222 3333 4444 5555 6666 7777 8888 9999 10101010 11111111 12121212 13131313 14141414 15151515 16161616 17171717 18181818 19191919 20202020 21212121 22222222 23232323 24242424 25252525 26262626 27272727 28282828 29292929 30303030 31313131

Formato de la Cabecera UDP

Payload UDP = Paquete RTP

Puerto Origen (0 - 65535) (SAP-Origen) Puerto Destino (0 - 65535) (SAP Destino)Longitud en Bytes del Datagrama UDP (>=8) Checksum

22



Protocolo Protocolo IPv4IPv4

Cabecera Cabecera IPv4IPv4 (normalmente):(normalmente): 20 Bytes

Paquete UDP:Paquete UDP: (20 + X) Bytes

TamaTamañño del Paquete o del Paquete IPv4IPv4:: (40 + X) Bytes

0000 1111 2222 3333 4444 5555 6666 7777 8888 9999 10101010 11111111 12121212 13131313 14141414 15151515 16161616 17171717 18181818 19191919 20202020 21212121 22222222 23232323 24242424 25252525 26262626 27272727 28282828 29292929 30303030 31313131

Formato de la Cabecera IPv4Formato de la Cabecera IPv4Formato de la Cabecera IPv4Formato de la Cabecera IPv4

IPv4 Destino

((Opciones) + (Relleno (Multiplo de 32 Bits)))

Payload IPv4 = Paquete UDPPayload IPv4 = Paquete UDPPayload IPv4 = Paquete UDPPayload IPv4 = Paquete UDP

TTL Protocolo (ICMP=1, TCP, UDP, etc.) Header Checksum (Solo Aplicado a Header IPv4)

IPv4 Origen

Identificacion Indicadores Offset del Segmento

Version IHL (x32 Bits) TOS Longitud Total de Header y Data (en Bytes)

12

23



Protocolo Protocolo EthernetEthernet

Formato de la Trama Formato de la Trama EthernetEthernet

Campos Cabecera Campos Cabecera EthernetEthernet: 26 : 26 BytesBytes

Paquete Paquete IPv4IPv4:: (40 + X) Bytes

TamaTamañño del Paquete o del Paquete IPv4IPv4:: (66 + X) Bytes

preámbulodirección de destino


Paquete IPv4

frame check sequenceca

mp

o

de

tip

o


bytes4 bytes

2 b

ytes

preámbulodirección de destino


Paquete IPv4

frame check sequenceca

mp

o

de

tip

o


bytes4 bytes

2 b

ytes

Entonces,

Ancho de Banda del Algoritmo (Ancho de Banda del Algoritmo (InterfaceInterface) = (PPS * (66 + X) * 8) ) = (PPS * (66 + X) * 8) bpsbps

24



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


13

25



� 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 encapsulamientoextras; hay un ‘Overhead’ Adicional que hay que considerar y que aumenta el Ancho de Banda Real que consume SOLAMENTE el Codec.


26



Tipos de CodecTipos de Codec’’ss

Existen, al menos, Tres (03) Tipos de Existen, al menos, Tres (03) Tipos de CodecCodec’’ss::

�� Algoritmos de Forma de Onda (Algoritmos de Forma de Onda (CodecCodec’’ss))

�� Algoritmos de Algoritmos de ParamParaméétricostricos ((VocodecVocodec’’ss))

�� Algoritmos Algoritmos ParParáámetricosmetricos de Ande Anáálisis y lisis y SistesisSistesis en en enen TXTX

14

27




Algoritmos de Forma de OndaAlgoritmos 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.

28




Algoritmos de Fuente VocalAlgoritmos de Fuente Vocal� Utiliza 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

15

29



El Proceso de CompresiEl Proceso de Compresióón n �� Procesamiento Digital de la SeProcesamiento Digital de la Seññal de Voz/Audioal de Voz/Audio

11000…11100 11000…11100

Frame N+1 Frame N

++-

+

ErrorError

Filtro Filtro DigitalDigital

SwitchSwitch

Ruido Ruido BlancoBlanco

Tren de Tren de PulsosPulsos

AnAnáálisislisis

SSííntesisntesis

La SeLa Seññal de al de

Voz/AudioVoz/Audio

Filtro Digital: Filtro Digital: ‘‘SetSet de Coeficientesde Coeficientes’’

30



Tipos de CodificaciTipos de Codificacióónn

Con respecto a la CodificaciCon respecto a la Codificacióón, se usan los siguientes esquemas:n, se usan los siguientes esquemas:

1)1) CodificaciCodificacióón PCM.n PCM.

2)2) CodificaciCodificacióón DPCM.n DPCM.

3)3) CodificaciCodificacióón ADPCM.n ADPCM.

4)4) CodificaciCodificacióón CELP.n CELP.

5)5) CodificaciCodificacióón CSn CS--ACELP.ACELP.

CodificaciCodificacióón PCMn 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.

16

31










CodificaciCodificacióón DPCMn 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.

32



Tipos de CodificaciTipos de CodificacióónnCon respecto a la CodificaciCon respecto a la Codificacióón, se usan los siguientes esquemas:n, se usan los siguientes esquemas:






CodificaciCodificacióón ADPCMn 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.

17

33



Tipos de CodificaciTipos de CodificacióónnCon respecto a la CodificaciCon respecto a la Codificacióón, se usan los siguientes esquemas:n, se usan los siguientes esquemas:






CodificaciCodificacióón CELP (Prediccin CELP (Prediccióón Lineal con Excitacin Lineal con Excitacióón de Cn de Cóódigos)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.

34









5)5) CodificaciCodificacióón CSn CS--ACELP y LDACELP y LD--CELP.CELP.

PredicciPrediccióón por Excitacin por Excitacióón Lineal de Cn Lineal de Cóódigo Algebraico de Estructura digo Algebraico de Estructura Conjugada (CSConjugada (CS--ACELP)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.

18

35



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

36



Medida Subjetiva de la Calidad de VozMedida Subjetiva de la Calidad de Voz

Media OpiniMedia Opinióón n ScopeScope (M(Méétodo MOS)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.

19

37



Medida Subjetiva de la Calidad de VozMedida Subjetiva de la Calidad de Voz

No se entiende nadaMala1

Se requiere esfuerzo adicional considerablePobre2

Se requiere un primer nivel de esfuerzo moderado

Media3

Atención necesaria, muy poco esfuerzoBuena4

Relajación completa, no requiere esfuerzoExcelente5

Respuesta y EsfuerzoMedida del MOS

38



Los Los CODECCODEC’’ss de VoIP mas de VoIP mas UtilizadosUtilizados

20

39



CodecCodec ITUITU--T G.711T G.711

G.711a y G.711uG.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.

40



CodecCodec ITUITU--T G.729T G.729

CodecCodec de Voz a 8kbps mediante Prediccide Voz a 8kbps mediante Prediccióón Lineal con Excitacin Lineal con Excitacióón n por Cpor Cóódigo Algebraico de Estructura Conjugada (CSdigo Algebraico de Estructura Conjugada (CS--ACELP)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.

21

41



CodecCodec ITUITU--T G.723.1T G.723.1

CodecCodec de Voz de Doble Velocidad para la Transmiside Voz de Doble Velocidad para la Transmisióón en n en Comunicaciones Multimedia a 5.3 y 6.3 Comunicaciones Multimedia a 5.3 y 6.3 kbpskbps (MP(MP--MLQ)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)

42



Otros Otros CodecCodec’’ss de VoIPde VoIP

�� ITUITU--TT: G.726 (24kbps), G.726 (32kbps), G.728, entre otros.

�� iLBCiLBC ((internetinternet LowLow BitrateBitrate CodecCodec)): creado originalmente por Global IP Sound; pero actualmente es de Código Libre FREE (httphttp://://www.ilbcfreeware.orgwww.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 LPC10 (Linear PredictivePredictive CodingCoding withwith 10 10 PredicmentPredicment CoefficientsCoefficientsCalculationsCalculations)): Usado en condiciones de bajo Ancho de Banda disponible. La Vozse escucha Robotizada; pero se entiende.

22

43



Otros Otros CodecCodec’’ss de VoIPde VoIP

�� SPEEX (SPEEX (httphttp://://www.speex.orgwww.speex.org//)): Codec Open Open Source/Free Software, 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

�� GSMGSM: 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 Otros CodecCodec’’ss usados en VoIPusados en VoIP: Siren (muy poca información), DVI4 (ADPCM), GIPS, DoD CELP, etc.

44



¿¿CuCuáál l CodecCodec de VoIP utilizar?de VoIP utilizar?

RespResp. . �� Depende.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.

23

45





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

46





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

24

47



Conclusiones y ComentariosConclusiones 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.

48



Conclusiones y ComentariosConclusiones y Comentarios

� La frecuencia de Muestreo de la Voz/audio y los Bits por Muestratienen un Impacto tremendo en el Ancho de Banda Requerido por elCodec.

� Si FS = 8KHz (TS = 125us) , @8 Bits por Muestra � 64000 Bits/Seg = 64KBPS.

�Fmax = 4KHz, Nyquist � FSMin = 8KHz.

25

49



Conclusiones y ComentariosConclusiones 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 (VoiceActivity 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.

50



Comentarios FinalesComentarios 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…!!!

26

51



TransportTransport ProtocolProtocol forfor RealReal--Time Time ApplicationsApplications

Protocolo RTP

Estándar de la IETF

Documento RFC1889 (Jun 1996)

52



DescripciDescripcióón General de RTPn General de RTP

� RTP es el protocolo que da soporte al transporte end-to-end 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.

27

53




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

54




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

28

55




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

56



Servicios Soportados por RTPServicios 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 soportadopor los protocolos de red IPv4 ó IPv6.

29

57



AplicaciAplicacióón de RTP: Conferencia de Audio Multicastn de RTP: Conferencia de Audio Multicast

� RTP se soporta en los servicios de IP Multicast para permitirdistribuir 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 empleanesquemas de codificación PCM, ADPCM ó LPC.

58



AplicaciAplicacióón de RTP: Conferencia de Audio y Video Multicastn 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.

30

59



AplicaciAplicacióón de RTP: n de RTP: MixersMixers andand TranslatorsTranslators

� Ú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ésde 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.

60



RTP y los Protocolos de Transporte y de Red que UtilizaRTP 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óximopuerto 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 justamentepor 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 redesbasadas en conmutación de paquetes.

31

61



Megaco

Ethernet / IEEE 802.3, 802.1Q, 802.1P

ARP RARP

IPv4 IPv6

ICMPv4 IGMP

UDP / UDP Lite TCP / SCTP

RTPRTCP SIP H.323

MultimediaMultimedia

StreamingStreaming

SeSeññalizacializacióónnSuperviciSupervicióónn

ControlControl

ICMPv6

62



Definiciones en RTP y RTCPDefiniciones en RTP y RTCP

�� RTP Payload (RTP Payload (CargaCarga ÚÚtiltil RTP)RTP): data multimedia transportada dentro de un paqueteRTP. Por ejemplo, muestras de audio, voz o video comprimido. Su formato o interpretación no está definido dentro del estándar RTP.

�� RTP Packet (RTP Packet (PaquetePaquete RTP)RTP): entidad RTP contentiva de una Cabecera RTP (de longitud fija) y una Data Payload.

�� RTCP RTCP packetpacket (Paquete RTCP)(Paquete 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)Port (Puerto): Puerto UDP/TCP asociado en la capa de transporte.

�� RTP Session (RTP Session (SesiSesióónn RTP)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 sesionesRTP, cada Media es transmitido con un canal RTP propio; con su respectivo canal RTCP cada uno. RTP session � Multiple Streams

32

63




�� SynchronizationSynchronization Source (SSRC):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.

64




�� Contributing Source (CSRC): 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 End SystemSystem (Sistema Final)(Sistema Final): Aplicación asociada al tráfico de data multimedia. La que origina y/o recibe los datos RTP.

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

33

65




� TranslatorTranslator (Traductor): (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.

�� MonitorMonitor: 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 NoProtocolos No--RTPRTP: 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.

66



Formatos, AlineaciFormatos, Alineacióón y Tiemposn y Tiempos

� Para nPara núúmeros enteros, se utiliza el formato meros enteros, se utiliza el formato ‘‘bigbig--endianendian’’: Bytes, MSB : Bytes, MSB �� LSB. LSB. �� Para las constantes decimales, se utiliza el sistema decimal (BPara las constantes decimales, se utiliza el sistema decimal (Base 10). ase 10). �� Sistema de numeraciSistema de numeracióón de octetos: comienzo en n de octetos: comienzo en ‘‘00’’. .

Formato y Estructura de un Paquete RTPFormato y Estructura de un Paquete RTP

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

P X M

1 Byte

… Contributing Source (CSRC) Identifiers





V=2 CC PT Seq

Multimedia Data

Timestamp

34

67




V, VersiV, Versióón (2 bits)n (2 bits): especifica la versión del protocolo RTP implementado. Actualmente, se utiliza la versión 2 (10B).

P, P, PaddingPadding (1 (1 bitbit)): 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.

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

68




X, X, ExtensionExtension (1 (1 bitbit)): 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:

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

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

User Defined Length

Header Extension (Longitud Variable)


1 Byte 1 Byte 1 Byte 1 Byte

Cabecera de Extensión RTP

35

69




CC, CSRC CC, CSRC CountCount (4 bits)(4 bits): especifica el número de identificadores CSRC.

M, M, MarkerMarker (1 (1 bitbit)): 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’.

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

70




PT, PT, PayloadPayload TypeType (7 bits)(7 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’.

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

36

71




PT, PT, PayloadPayload Type (7 bits)Type (7 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

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

72




SeqSeq, , SequenceSequence NumberNumber (16 bits)(16 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 aleatoriamentealeatoriamente.

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

37

73




TimestampTimestamp, Marcador de Tiempo (32 bits), Marcador de Tiempo (32 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 aleatoriamentealeatoriamente. Puede estar asociado al clock del sistema ó al clockdel muestreo de la señal de media (voz, audio ó video).

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

74




SSRC, SSRC, SinchronizationSinchronization SourceSource (32 bits)(32 bits): identifica la fuente de sincronización. Este identificador se establece aleatoriamentealeatoriamente, 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.

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

38

75




CSRC, CSRC, ContributingContributing SourceSource (0 (0 toto 15 15 itemsitems, 32 bits c/u), 32 bits 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 !!! MIXER !!!

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

P X M

1 Byte






V=2 CC PT Seq

Multimedia Data

Timestamp

76



Multiplexado de Sesiones RTPMultiplexado 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.

39

77



RTP Control RTP Control ProtocolProtocol (RTCP)(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).

SeSeññalizacializacióónn

RTPRTP

RTCPRTCP

¡¡¡¡ RTCP estRTCP estáá pensado para trabajar en conjunto con RTP !!pensado para trabajar en conjunto con RTP !!

78



Funciones de RTCPFunciones de RTCP

� Obtener información acerca de la Calidad de Entrega de los Datos (feedback onthe 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.

MonitorizaciMonitorizacióón de la QoS y control de congestin de la QoS y control de congestióón (n (SRSR y y RRRR))

� Transmitir unos identificadores asociados a las fuentes RTP, identificadores conocidos como CNAME (Canonical Name), com o una identificación antelnativaal SSRC; por si este varía.

IdentificaciIdentificacióón de Fuente (n de Fuente (SDESSDES).).

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

SincronizaciSincronizacióón Intern Inter--Media.Media.

� Control de los participantes dentro de una sesión. Escalado de la informaciEscalado de la informacióón de control.n de control.

40

79



Tipos de Paquetes RTCPTipos de Paquetes RTCP

�� SR, SR, SenderSender ReportReport. .

SenderNTP Timestamp (MSW)NTP Timestamp (ISW)

RTP TimestampContador de Paquetes del Emisor

V P LongitudRC PT=200 (SR)

0 31

Contador de Octetos del EmisorSSRC 1

… datos adicionales RR …SSRC n

… datos adicionales RR …

80




�� SR, SR, SenderSender ReportReport. .

SenderNTP Timestamp (MSW)NTP Timestamp (ISW)

RTP TimestampContador de Paquetes del Emisor

V P LongitudRC PT=200 (SR)

0 31

Contador de Octetos del EmisorSSRC 1

… datos adicionales RR …SSRC n

… datos adicionales RR …

41

81




�� SR, SR, ReceiverReceiver ReportReport. .

Paquetes perdidos

V P LongitudRC PT=201 (RR)

0 31

Número de secuencia recibido más alto

Jitter entre llegadas

Último SR TimeStamp (LSR)

Retardo desde último SR (DLSR)

Lost fraction

SSRC

82




�� Otros Paquetes RTCP.Otros Paquetes RTCP.

• SDESSource Description RTCP Packet

CNAME, NAME, E-MAIL, PHONE, LOC.

• BYEIndica que una o más fuentes dejan de estar activas

• APPPaquetes específicos de aplicaciones

• Algunos no se utilizan en H.323

1

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

Ing. José G. Cotúa

Protocolo de Señalización ITU-T

H.323

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

VoIP y Telefonía IP



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 Normalizacia) Sector de Normalizacióón (ITUn (ITU--T)T)

b) Sector de Radiocomunicaciones (ITUb) Sector de Radiocomunicaciones (ITU--R)R)

c) Sector de Desarrollo de las c) Sector de Desarrollo de las Telecomunicaciones (ITUTelecomunicaciones (ITU--D)D)


2



ITU-T – Sector de Normalización de la Unión Internacional de Telecomunicaciones

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



Ing. José G. CotúaVoIP y Telefonía IP

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 ComunicaciSistemas de Comunicacióón Multimedios n Multimedios basados en Paquetes basados en Paquetes ””

3



Protocolo H.323

Serie H, de las Recomendaciones ITU-T

““ Sistemas Audiovisuales y Multimedios 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)

4



Á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 (IEEE 802.3) 10/100/1000/10000BaseTX

5



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.

6



Rec H.323 - Definiciones

� Llamada: Comunicación multimedios entre dos puntos extremos H.323. La llamada empieza con el procedimiento de establecimiento de la comunicaciprocedimiento de establecimiento de la comunicacióónny termina con el procedimiento de terminaciprocedimiento de terminacióónn 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.




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

7




� Canal Lógico: Canal utilizado para transportar trenes de información entre puntos extremos H.323. Estos canales se establecen siguiendo losprocedimientos 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.




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

8



Entidades H.323

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



Punto Extremo H.323

TerminalEnd Point


9



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




Punto Extremo H.323

Estructura y Elementos de un PE H.323

Codec de Audio

Codec de Video

Módulo de

Sincronización

y Retardo

Control H.245

Señalización H.225.0

Control RAS H.225.0

Capa

H.225.0

IN/OUT Audio

IN/OUT Video

IN/OUT Data

Interfaz Usuario Inte

rfaz

de

Red

Alcance Rec. ITU-T H.323


10



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

PasarelaPuerta de Acceso


11



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 Interoperabilidad entre la RCC y la PBN a nivel de canales de voz y telefoncanales de voz y telefoníía; reflejar del lado de la PBN la a; reflejar del lado de la PBN la realidad RCC (y viceversa) en modo transparenterealidad 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




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)


12



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


Gateway H.323

Red A (Protocolo A)

Red B (Protocolo B)



Gatekeeper H.323

Controladores de AccesoGuardián de Puerta


13



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


14



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

© Ing. José G. Cotúa


15



Entidad H.323Procesador 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.323Procesador 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)


16



Controlador MultipuntoMC





Entidad H.323Controlador 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


17




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





MC

� 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


18




MC

� 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





MC

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


19



Unidad de Control Multipunto MCU




Entidad H.323Unidad 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


20



Aspectos Generales y Lineamientos

Protocolo de Señalización 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.


21



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.


22



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




� 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

Direcciones de Red (IPv4/IPv6)Direcciones de Red (IPv4/IPv6)



23



� 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

Direcciones TSAPDirecciones TSAP





� 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


Direcciones de AliasDirecciones de Alias


24



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)





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.


25




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.





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


26




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.




Canal de Datos en H.323


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

27





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





� 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 lallamada H.323, por supuesto, se cierra todo canal lógico T.120 asociado.

Apertura de Canal Lógico para T.120

28





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

29





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





Pre-Llamada, Canal RAS

GK Discovery y Registración

� Los Procesos Inciales Claves de Pre-Llamada son:

a)a) GK DiscoveryGK Discovery

b)b) RegistraciRegistracióón de PE y/o GW en GKn 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

30



Canal RASCanal RAS

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

Gatekeeper DiscoveryGatekeeper Discovery


31



� 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.)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 quegatekeeper utilizar.


32



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.




Procedimiento


Punto Extremo H.323 Gatekeeper H.323

Multidifusión/Unidifusión GRQ

Unidifusión GCF/GRJ

Automatic Gatekeeper Discovery (Fuente: Autor)


33



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.




Canal RASCanal RAS

RegistraciRegistracióón de Puntos Extremos en n de Puntos Extremos en GatekeeperGatekeeper’’ss

34



� 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 haciaslos puertos de un gateway.

Registro de Puntos Extremos en Gatekeeper 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.


35



Procedimiento


La Registración �� Aceptación ó Rechazo


Petición de Registro, RRQ

Aceptación/Rechazo de Registro, RCF/RRJ

Registration Process (Fuente: Autor)




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.


36



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







Petición de Desregistro, URQ

Aceptación/Rechazo de Desregistro, UCF/URJ

Unregistration Process (Fuente: Autor)


37






Petición de Desregistro, URQ

Aceptación de Desregistro, UCF

Unregistration Process (Fuente: Autor)







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

38



Canal RASCanal RAS

LocalizaciLocalizacióón de Puntos Extremosn 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.


39




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







Localización y Admisión�� AdmisiAdmisióón, Cambios de Ancho de Banda, Situacin, Cambios de Ancho de Banda, Situacióón y n y

DesligamientoDesligamiento

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

40



Canal RASCanal RAS

Admisiones, Cambios de Ancho de Banda, Admisiones, Cambios de Ancho de Banda, SituaciSituacióón y Desligamienton y Desligamiento



Canal RASCanal RAS

Admisiones, Cambios de Ancho de Banda, SituaciAdmisiones, Cambios de Ancho de Banda, Situacióón y n y DesligamientoDesligamiento

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


41



Canal RASCanal RAS

Testigos de AccesoTestigos 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


42





Llamadas PE – PE sin Registración

PE (Llamante)

PE (Llamado)

Red IPv4/IPv6

H.225.0

H.245

Multimedia/Data





Llamadas PE-PE Co-Registrados en GK

PE (Llamante)

PE (Llamado)

GK

Red IPv4/IPv6

Gatekeeper

Regist

rado

Registrado

43





Llamadas PE-PE donde solo un PE (Llamante) tiene GK

PE (Llamante)

PE (Llamado)

GK

Red IPv4/IPv6

Gatekeeper

Regist

rado





Llamadas PE-PE donde solo un PE (Llamado) tiene GK

PE (Llamante)

PE (Llamado)

GK

Red IPv4/IPv6

Gatekeeper

Registrado

44




Llamadas PE-PE cada uno con su GK

PE (Llamante)

PE (Llamado)

GK

Gatekeeper

Reg

istr

ado

Reg

istr

ado

GK

Gatekeeper

Red IPv4/IPv6




Señalización de LlamadaProtocolo H.323

Ing. José G. CotúaJunio, 2007


45



SeSeññalizacializacióón de Llamada en H.323n de Llamada en H.323

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

DefiniciDefinicióónn





Canal de SeCanal de Seññalizacializacióón n

de Llamadade Llamada


46



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 y gatekeeper’s en redes H.323 que tienen gatekeeper.

Canal de SeCanal de Seññalizacializacióón de Llamadan de Llamada

Características del Canal de Señalización de Llamada

� Es un Canal Fiable (TCP)

� Basado en Mensajes H.225.0




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 SeCanal H.225.0, de Seññalizacializacióón de Llamadan de Llamada

5.) Canal de Control H.245

6.) Canales de Multimedia y Datos


47



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




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


48



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




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.



49



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.


� 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 Procedimientos de SeSeññalizacializacióón de Llamadan de Llamada


50



Procedimientos de SeProcedimientos de Seññalizacializacióón de Llamadan 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







1.-) Llamadas entre Puntos Extremos sin Gatekeeper

Punto Extremo 1 Punto Extremo 2

(1) Establecimiento

(2) Llamada en Curso

(3) Aviso

(4) Conexión


51






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.






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)


52






2.1.-) Señalización de Llamada DirectaPunto Extremo 1

(llamante)Punto Extremo 2

(llamado)GatekeeperARQ (1)

ACF/ARJ (2)

Establecimiento (3)

Llamada en Curso (4)

ARQ (5)ACF/ARJ (6)

Aviso (7)

Conexión (8)






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) delgatekeeper envía entonces un Mensaje de Liberación al PE1.

� El PE2 responde con un Mensaje de Conexión al PE1, especificandole la dirección TSAP del canal de control H.245.


53






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)


ARQ (6)

ACF/ARJ(7)

Aviso (8) Aviso (8)

Conexión (9) Conexión (9)








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


54







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






3.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamante)

Punto Extremo 1 (llamante/registrado)

Punto Extremo 2 (llamado/no registrado)Gatekeeper

ARQ (1)

ACF/ARJ (2)

Establecimiento (3)


Aviso (5)

Conexión (6)



55






� 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 deConexión (6) que contiene su identificación TSAP del canal de control H.245.








Punto Extremo 1 (llamante/registrado)

Punto Extremo 2 (llamado/no registrado)Gatekeeper

ARQ (1)

ACF/ARJ (2)


Establecimiento (3) Establecimiento (4)

Llamada en Curso (5)Llamada en Curso (5)

Aviso (6)Aviso (6)

Conexión (7)Conexión (7)


56






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








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



57





4.-) Llamadas entre Puntos Extremos con Gatekeeper SOLO para un Punto Extremo (llamado)

� Procedimiento Análogo…!!!








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, señalización de llamada directa/encaminada

4.3.-) Ambos PE registrados, señalización de llamada encaminada/directa

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


58





5.-) Otros procedimientos de señalización

5.1.-) Señalización Opcional de PE llamado

5.2.-) Procedimiento de Conexión Rápida





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ónH.245


59




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





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


60




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)


61




� 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: ‘‘TunelizaciTunelizacióónn H.245H.245’’.





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.


62



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





� Los Mensajes de Control H.245 se clasifican en:

a) ) de Peticide Peticióónn, requieren una acción específica y una respuesta inmediata.

b) de Respuestade Respuesta, respondetn a peticiones.

c) de Instruccide Instruccióónn, requieren acción específica; pero no una respuesta

d) de Indicacide Indicacióónn, informativos y no requieren respuesta



63



� 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





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



64



� 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 ejemploPor 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 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 Canales Unidireccionales (Asimétricos) óBidireccionales.

� Canales Lógicos para Voz y Video: UDP, RTP/RTCP.

� Canales Lógicos para Data: TCP.



1

1


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

Media Gateway Control ProtocolMedia Gateway Control Protocol

MGCP v1.0MGCP v1.0

Ing. JosIng. Joséé CotCotúúa, Agosto 2007a, Agosto 2007

2



DescripciDescripcióón General de MGCPn 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

3



DescripciDescripcióón General de MGCPn General de MGCP

Agentes de Llamada 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.

PasarelasPasarelas

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

4



DescripciDescripcióón General de MGCPn General de MGCP�� MGCP es un protocolo de tipo Maestro/Esclavo (Gestión Centralizada).

- Maestro: Los Agentes de Llamada.

- Esclavo: Las Pasarelas.

Event

os

Event

os

Eventos

Eventos

Coman

dos

Coman

dos

Pasarela

Esclavo

Pasarela

Esclavo

Agente de

LLamada

Maestro

� FXO � FXS � TDM

� FXO � FXS � TDM

Comandos

Comandos

3

5



GestiGestióón Centralizada MGCPn 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.

6



Detalles de Funcionamiento MGCPDetalles de Funcionamiento MGCP

�� El Media GatewayEl Media Gateway. . El Media Gateway tiene la funciEl Media Gateway tiene la funcióón n principal de conversiprincipal de conversióón de protocolos de la Red de n de protocolos de la Red de ConmutaciConmutacióón de Circuitos (RCCn de Circuitos (RCC--PSTN) a la Red de PSTN) a la Red de ConmutaciConmutacióón de Paquetes (PBN). n de Paquetes (PBN).

Media Media GatewayGateway

Red de ConmutaciRed de Conmutacióónn

de Circuitosde CircuitosRed de ConmutaciRed de Conmutacióónn

de Paquetesde Paquetes

IPIP

E1/T1, FXS, FXO, E&METH, ATM, xDSL, WiFI, WiMAX, Fibra, PLC

4

7




�� CallCall Agent (Media Gateway Controller).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.

8




� Desde el punto de vista de los Media Gateway’s, en MGCP se definen Dos (02) tipos de estructuras:

�� Los EndpointsLos Endpoints:: fuentes/origen de data multimedia, pueden ser físicos o virtuales. Son todos y cada una de las interfaces de los MediaGateway.

�� Las ConexionesLas 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.

5

9




�� Conexiones y Llamadas.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.

10




�� RelaciRelacióón de MGCP con H.323: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.

�� IdentificaciIdentificacióón de los Endpointn de los Endpoint’’ss. De la forma,

�� Media_Gateway_Local_Name@Media_Gateway_DomainMedia_Gateway_Local_Name@Media_Gateway_Domain

�� Media_Gateway_Local_Name@Media_Gateway_IPv4Media_Gateway_Local_Name@Media_Gateway_IPv4

�� Media_Gateway_Local_Name@Media_Gateway_IPv6Media_Gateway_Local_Name@Media_Gateway_IPv6

6

11



Llamada entre Dos Endpoints, cada uno asociado a un Media Llamada entre Dos Endpoints, cada uno asociado a un Media Gateway, a travGateway, a travéés de un Call Agents 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.

12



Llamada entre Dos Endpoints, cada uno asociado a un Media Llamada entre Dos Endpoints, cada uno asociado a un Media Gateway, a travGateway, a travéés de un Call Agents 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.

7

13



Llamada entre Dos Endpoints, cada uno asociado a un Media Llamada entre Dos Endpoints, cada uno asociado a un Media Gateway, a travGateway, a travéés de distintos Call Agents de distintos Call Agent’’ss

� 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 EndpointUna vez establecidas las conexiones entre los Endpoint’’s, el Call Agent s, el Call Agent puede en cualquier momento; utilizando Comandos puede en cualquier momento; utilizando Comandos ‘‘Modify ConnectionsModify Connections’’, ,

modificar los parmodificar los paráámetros de tales conexiones. Por ejemplo, cambiar los metros de tales conexiones. Por ejemplo, cambiar los CodecCodec’’s, modificar las Direcciones IPs, modificar las Direcciones IP’’s, cambiar los Puertos UDP, etc. s, cambiar los Puertos UDP, etc. ””

14



GestiGestióón de Conexiones por parte de los Call Agentn de Conexiones por parte de los Call Agent’’ss

““ Una vez establecidas las conexiones entre los EndpointUna vez establecidas las conexiones entre los Endpoint’’s, el Call Agent s, el Call Agent puede en cualquier momento; utilizando Comandos puede en cualquier momento; utilizando Comandos ‘‘Modify ConnectionsModify Connections’’, ,

modificar los parmodificar los paráámetros de tales conexiones. Por ejemplo, cambiar los metros de tales conexiones. Por ejemplo, cambiar los CodecCodec’’s, modificar las Direcciones IPs, modificar las Direcciones IP’’s, cambiar los Puertos UDP, etc. s, cambiar los Puertos UDP, etc. ””

““ Los Call AgentLos Call Agent’’s pueden eliminar Conexiones enviando Comandos de tipo s pueden eliminar Conexiones enviando Comandos de tipo ‘‘Delete ConnectionsDelete Connections”” a los Media Gateway. Los Media Gateway podra los Media Gateway. Los Media Gateway podráán n

responder, ante tal solicitud, de forma afirmativa o negativaresponder, ante tal solicitud, de forma afirmativa o negativa””

8

15



Protocolo MEGACOProtocolo MEGACO

VersiVersióón 1n 1

Ing. JosIng. Joséé CotCotúúa, Junio 2007a, Junio 2007

16



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

1

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


1

Protocolo de SeProtocolo de Seññalizacializacióón n SIPSIP

SessionSession InitiationInitiation ProtocolProtocol

Ing. JosIng. Joséé G. CotG. Cotúúaa

Agosto, 2007Agosto, 2007



2


IntroducciIntroduccióón y Descripcin y Descripcióón Generaln General

2



3

OrigenesOrigenes de SIPde 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.



4

� 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 = n Multimedia = VozVoz + Video + Data !!!+ Video + Data !!!

Definiciones de SIPDefiniciones de SIP

3



5

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

Aspectos Generales de SIPAspectos Generales de SIP



6

� 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 deConexió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?


4



7

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




8


� Sintáxis:

sip:user:password@host:port;transportsip:user:password@host:port;transport==tcptcp//udpudp;;……

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];maddrsip:[email protected];maddr=239.255.255.1;=239.255.255.1;ttlttl=15=15


5



9


� Ejemplos de SIP-URL’s:sip:[email protected]:j.doe:[email protected];transport=tcpsip:[email protected]?subject=projectsip:+1-212-555-1212:[email protected];user=phonesip:[email protected]:[email protected]:[email protected]:alice%[email protected]:[email protected];method=REGISTER

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




10

� Basado en el Uso de URL (Uniform ResourceLocators).

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


6



11

� 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 Simplificada, conservando Robustez y Funcionalidades.

� Solventar Rápidamente Inconvenientes de Firewall’s y NAT’s.

� Hacer uso efectivo de la Arquitectura de Protocolos TCP/IP.

Objetivos de SIPObjetivos de SIP



12

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

Arquitectura Multimedia de la IETFArquitectura Multimedia de la IETF

7



13

Aplicación

Transporte

Red

Enlace

Física

Aplicación

Transporte

Red

Enlace

TCP UDP

Física

IPv4 IPv6/IPng ICMP

IEEE 802.3/802.11

SIP SDP RTP/RTCP

Red IPRed IP

SIP y la Arquitectura de Protocolos



14


Detalles de FuncionamientoDetalles de Funcionamiento

8



15

Detalles de Funcionamiento del Protocolo SIPDetalles 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 =>Protocolo SIP => Canal_de_SeCanal_de_Seññalizacializacióón_SIPn_SIP ++Canal_de_Streaming_VozCanal_de_Streaming_Voz/Video/Video !!!!

Red IPRed IP

Canal de ‘Streaming’(Voz/Video)

RTP/RTCP/UDP

Canal de Señalización SIP

UDP/TCP

Agente SIP

(Cliente)

Servidor SIP

(Servidor)



16

SIP es un Protocolo basado en HTTP =>> FSIP es un Protocolo basado en HTTP =>> Fáácil cil ‘‘DebugDebug’’el Tiempo Realel 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. ((‘‘SnifferSniffer’’))……

9



17

SIP es un Protocolo basado en HTTP =>> FSIP es un Protocolo basado en HTTP =>> Fáácil cil ‘‘DebugDebug’’el Tiempo Realel 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.



18

Servicios que Soporta el Protocolo SIPServicios que Soporta el Protocolo SIP

• Servicio de LocalizaciServicio de Localizacióón de Usuariosn de Usuarios: determinación de las direcciones de localización de los usuarios finales que participarán en las sesiones multimedia.

•• Servicio de Establecimiento de LlamadaServicio de Establecimiento de Llamada: repique, negociación de parámetros entre los participantes de una sesión.

•• Servicio de Disponibilidad de UsuarioServicio de Disponibilidad de Usuario: la posibilidad de determinar si un agente SIP desea o no participar en una nueva sesión.

10



19

Servicios que Soporta el Protocolo SIPServicios que Soporta el Protocolo SIP

•• Servicio de CaracterServicio de Caracteríísticas de Usuariosticas de Usuario: la posibilidad de determinar los flujos multimedia, y las características de loosmismos, que podrán utilizarse en una sesión.

•• Servicio de Manejo de LlamadasServicio de Manejo de Llamadas: transferencia de llamadas, y terminación de sesiones.



20

Entidades SIPEntidades SIP

Básicamente, la Arquitectura SIP soporta Dos Tipos de Entidades claramentes definidas dentro del protocolo:

�� Agente de Usuario SIP, o simplemente Agente SIP. Agente de Usuario SIP, o simplemente Agente SIP. En adelante: Clientes SIP. En adelante: Clientes SIP.

�� Servidores SIP. Servidores SIP.

11



21

Agente de Usuario SIP, o simplemente Agente 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.

EjemplosEjemplos

IPIP--PhonePhone

SoftSoft--PhonePhone

AdaptadoresAdaptadores

IPIP--PBX SIPPBX SIP

GatewayGateway’’ss

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

Inicia Peticiones




22

Servidor SIPServidor SIP

�� Servidores de LocalizaciServidores de Localizacióón (n (LocationLocation Server)Server).

�� Servidores de Servidores de RegistraciRegistracióónn (Registrar Server)(Registrar Server).

�� Servidores Proxy (Servidores Proxy (ProxyProxy Server) Server) Modo Persistente (Modo Persistente (StatefulStateful Proxy Server)Proxy Server).

Servidores Proxy de Estado VolServidores Proxy de Estado Voláátil (til (StatelessStateless Proxy Server)Proxy Server).

�� Servidor de RedirecciServidor de Redireccióón (n (RedirectionRedirection Server).Server).


12



23

Servidor de LocalizaciServidor de Localizacióón (n (LocationLocation Server)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 overIP) para comunicarse con los otros servidores.

Servidor de Localización �� Permite Obtener Informaciónde Localización de los Usuarios en Proceso

de ser Llamados




24

Servidor de Servidor de RegistraciRegistracióónn (Registrar Server)(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


13



25

Servidor de RedirecciServidor de Redireccióón (n (RedirectionRedirection Server)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.




26

Servidor de Proxy (Servidor de Proxy (ProxyProxy Server)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 (tambitambiéén llamado n llamado NHS, NHS, NextNext HopHop ServerServer) luego de decidir cual debe ser. El NHS puede ser cualquier tipo de servidor SIP.


14



27


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.




28


Servidor Proxy en Modo Persistente Servidor Proxy en Modo Persistente ((StatefulStateful Proxy Proxy Server)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.


15



29


Servidor Proxy de Estado VolServidor Proxy de Estado Voláátil til ((StatelessStateless Proxy Server)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.




30


Servidor Proxy: Persistente Vs. VolServidor Proxy: Persistente Vs. Voláátiltil

StatefulStateful Proxy ServerProxy Server

• Mantiene el estado de la llamada.

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

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

• Deben funcionar sobre TCP para mayor fiabilidad.

• Los servicios de valos añadido requieren guardar la información de estado.

StatelessStateless Proxy ServerProxy Server

• No existe contexto de la llamada.

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

• Cliente anónimo.

• Alta capacidad de procesos concurrentes.

• Menor uso de recursos, memoria y procesador.


16



31


El Proceso de Llamadas en SIPEl Proceso de Llamadas en SIP



32

Usuario Origen Proxy SIP

Usuario Destino

Servidor de

Localización

1.1.-- INVITEINVITE

2.2.-- CONTACTCONTACT 3.3.-- PRECISE LOCATIONPRECISE LOCATION

4.4.-- INVITEINVITE

5.5.-- SUCCESSSUCCESS6.6.-- SUCCESSSUCCESS

7.7.-- ACKACK 8.8.-- ACKACK

UAC

Llamante

UAS

Llamado

Llamada entre Usuarios SIP a travLlamada entre Usuarios SIP a travéés de Servidor Proxy s de Servidor Proxy

y Servidor de Localizaciy Servidor de Localizacióónn

17



33

UAC

Llamante

UAS

Llamado

Proxy SIPProxy SIP

1.1.-- INVITEINVITE

Servidor de LocalizaciServidor de Localizacióónn

2.2.-- CONTACTCONTACT

3.3.-- LOCATIONLOCATION

4.4.-- INVITEINVITE

5.5.-- SUCESSSUCESS6.6.-- SUCESSSUCESS

7.7.-- ACKACK8.8.-- ACKACK

BYEBYEBYEBYE

SUCCESSSUCCESSSUCCESSSUCCESS

RTP STREAMINGRTP STREAMINGRTP STREAMINGRTP STREAMING

Llamada entre Usuarios SIP a travLlamada entre Usuarios SIP a travéés de Servidor Proxy s de Servidor Proxy

y Servidor de Localizaciy Servidor de Localizacióónn



34

Usuario Origen Redirector

SIP

Usuario Destino

Servidor de

Localización

1.1.-- INVITEINVITE

2.2.-- CONTACTCONTACT 3.3.-- PRECISE LOCATIONPRECISE LOCATION

6.6.-- INVITEINVITE

8.8.-- ACKACK

5.5.-- ACKACK

UAC UAS

4.4.-- SUCCESSSUCCESS

7.7.-- SUCESSSUCESS

Llamada entre Usuarios SIP a travLlamada entre Usuarios SIP a travéés de Servidor de s de Servidor de

RedirecciRedireccióónn

18



35

UAC

Llamante

UAS

Llamado

Proxy SIPProxy SIP

1.1.-- INVITEINVITE

Servidor de LocalizaciServidor de Localizacióónn

2.2.-- CONTACTCONTACT

3.3.-- LOCATIONLOCATION

4. 4. --SUCCESSSUCCESS

5.5.-- ACKACK

6.6.-- INVITEINVITE

7. SUCESS7. SUCESS

BYEBYE

SUCCESSSUCCESS

RTP STREAMINGRTP STREAMING

8. ACK8. ACK

Llamada entre Usuarios SIP a travLlamada entre Usuarios SIP a travéés de Servidor de s de Servidor de

RedirecciRedireccióónn



36


AnAnáálisis Detallado de los lisis Detallado de los Mensajes en SIPMensajes en SIP

19



37

Los Mensajes SIP Los Mensajes SIP -- DescripciDescripcióón Generaln 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 (DACRLF (DAHEXHEX),), CR (DHEX) ó LF (AHEX).



38

Los Mensajes SIP Los Mensajes SIP -- DescripciDescripcióón Generaln 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.

20



39

En SIP se definen Dos (02) Tipos de Mensaje:

1) Mensajes de Petici1) Mensajes de Peticióón (Cliente (UAC) n (Cliente (UAC) �� Servidor 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) 2) Mensajes de Respuesta (Servidor (UAS) �� Cliente Cliente (UAC)).(UAC)).Son los mensajes enviados de los servidores a los clientes SIP, como respuesta a las peticiones.

Los Mensajes SIP Los Mensajes SIP –– Tipos de MensajesTipos de Mensajes



40

Estructura de los Mensajes SIPEstructura 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).

21



41

Cliente SIPCliente SIP

UACUAC

Servidor SIPServidor SIP

UACUAC

Red IPRed IP

Mensajes de PeticiMensajes de Peticióónn

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

Mensajes de RespuestaMensajes de Respuesta

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

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

Los Mensajes SIP Los Mensajes SIP –– Estructura Estructura PeticiPeticióón/Respuestan/Respuesta



42

Mensajes SIPMensajes SIPEstructura de los Mensajes de PeticiEstructura de los Mensajes de Peticióónn

Línea de Comienzo: ‘Request-Line’

Cabeceras

Línea en Blanco

Cuerpo del Mensaje (Opcional)

MethodMethod Space RequestRequest--URIURI Space SIPSIP--VersionVersion CRLFINVITE

BYE

OPTIONS

ACK

CANCEL

REGISTER

RequestRequest--URI: Request Universal URI: Request Universal ResourceResource IdentifierIdentifier

Especifica el Usuario o Servicio que dirige la PeticiEspecifica el Usuario o Servicio que dirige la Peticióónn

VersiVersióón del Protocolo n del Protocolo SIP utilizadoSIP utilizado

22



43

Mensajes SIPMensajes SIPEstructura de los Mensajes de RespuestaEstructura de los Mensajes de Respuesta

Línea de Comienzo: ‘Status-Line’

Cabeceras

Línea en Blanco


SIPSIP--VersionVersion Space StatusStatus--CodeCode Space ReasonReason--PhrasePhrase CRLF

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

1XX:1XX: Información.

2XX:2XX: Éxito.

3XX:3XX: Desvío.

4XX:4XX: Error en el Cliente.

5XX:5XX: Error en el Servidor.

6XX:6XX: Fallo General

VersiVersióón del Protocolo n del Protocolo SIP utilizadoSIP utilizado



44

Mensajes SIPMensajes SIPLas CabecerasLas Cabeceras

CabecerasCabeceras� 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


23



45

Mensajes SIPMensajes SIPLas CabecerasLas Cabeceras

CabecerasCabecerasEn SIP existen 37 Campos de cabeceras diferentes que se

agrupan en Cuatro (04) Tipos, que son:

1) Campos Gen1) Campos Genééricos (General Header). ricos (General Header). 2) Campos de Entidad (Entity Header).2) Campos de Entidad (Entity Header).3) Campos de Respuesta (Response Header).3) Campos de Respuesta (Response Header).4) Campos de Petici4) Campos de Peticióón (Request Header).n (Request Header).

Línea de Comienzo

Cabeceras

Línea en Blanco




46

Mensajes SIP, Las Cabeceras (Cont.)Mensajes SIP, Las Cabeceras (Cont.)

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.

CabecerasCabeceras

24



47

Mensajes SIP, Las Cabeceras (Cont.)Mensajes SIP, Las Cabeceras (Cont.)

CabecerasCabeceras

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’



48

Mensajes SIP Mensajes SIP -- El Cuerpo del MensajeEl Cuerpo del Mensaje

Cuerpo del MensajeCuerpo del Mensaje

Todas las Peticiones pueden incluir, opcionalmente, un Todas las Peticiones pueden incluir, opcionalmente, un Cuerpo del Mensaje, excepto la PeticiCuerpo del Mensaje, excepto la Peticióón de BYE. Para las n de BYE. Para las Peticiones INVITE, ACK y OPTIONS el Cuerpo del Mensaje Peticiones INVITE, ACK y OPTIONS el Cuerpo del Mensaje es una Descripcies una Descripcióón de la Sesin de la Sesióón y esto se hace basado en el n y esto se hace basado en el Protocolo SDP. Protocolo SDP.

Línea de Comienzo

Cabeceras

Línea en Blanco


25



49

Mensajes SIPMensajes SIPDetalles de los Mensajes Detalles de los Mensajes

de Peticide Peticióón n



50

Mensajes SIP Mensajes SIP Detalles de los Mensajes de PeticiDetalles de los Mensajes de Peticióón n

A) RequestA) Request--Line Line �� MethodMethod Space RequestRequest--URIURI Space SIPSIP--VersionVersion CRLF

Puede ser cualquiera de los siguientes:

- INVITE - ACK

- OPTIONS - BYE

- CANCEL - REGISTER

MethodMethod

26



51


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

Method:Method: INVITEINVITE




52

A) RequestA) Request--Line Line �� MethodMethod Space RequestRequest--URIURISpace SIPSIP--VersionVersion CRLF

Method:Method: ACKACK


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

27



53


Method:Method: OPTIONSOPTIONS


� Para solicitud de Status y Capacidades del Server SIP que es llamado.



54


Method:Method: BYEBYE


� El UAC le indica al UAS que desea terminar la Llamada/Sesión.

28



55


Method:Method: CANCELCANCEL

� Mediante una Petición CANCEL un UAC cancela unaPetición Pendiente, asociada con las Cabeceras Call-ID, To, From y CSeq. Sin embargo, no cancela Peticiones yacompletadas (aquellas en las que el UAS ya ha retornadouna Respuesta Final). Un UAC puede hacer una PaticiónCANCEL 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.




56


Method:Method: CANCELCANCEL

� Cuando un UAS recibe una Petición CANCEL, este NO DEBE enviar una Respuesta 2XX a la Petición Original.

CuandoCuando OcurreOcurre unauna PeticiPeticióónn CANCEL? CANCEL?

RespResp.. CuandoCuando el el UsuarioUsuario UAC UAC trancatranca la la llamadallamada antes de antes de queque sea sea finalmentefinalmente establecidaestablecida. .


29



57


Method:Method: REGISTERREGISTER


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



58


RequestRequest--URIURI


� Especifica el URI del Usuario del registro solicitado.

Ejemplo:

sip:[email protected]

30



59


SIPSIP--VersionVersion


� Especifica la Versión de SIP utilizada.

Ejemplo:

“SIP/2.0”



60


Ejemplo,Ejemplo,


INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 169.130.12.5From: <sip:[email protected]>To: T. A. Watson <sip:[email protected]>Call-ID: [email protected]: 885Encryption: PGP version=2.6.2,encoding=ascii

31



61

Mensajes SIPMensajes SIPDetalles de los Mensajes Detalles de los Mensajes

de Respuesta de Respuesta



62

Mensajes SIPMensajes SIPDetalles de los Mensajes de Respuesta Detalles de los Mensajes de Respuesta

A) StatusA) Status--Line Line �� SIPSIP--VersionVersion Space StatusStatus--CodeCodeSpace ReasonReason--PhrasePhrase CRLF

‘‘Status CodeStatus Code’’: 1XX : 1XX ““Respuesta InformativaRespuesta Informativa”” SignificadoSignificadoSignificadoSignificado100100100100 TryingTryingTryingTrying (Intentando)180180180180 RingingRingingRingingRinging (Repicando)181181181181 Call Is Being ForwardedCall Is Being ForwardedCall Is Being ForwardedCall Is Being Forwarded (Llamada en Proceso de Reenvío)182182182182 QueuedQueuedQueuedQueued (Llamada Encolada)El Cliente DEBERÍA esperar por futuras Respuestas del Servidor y el Servidor DEBERÏA enviarlas. El Servidor DEBERÍA enviar una Respuesta 1XX siespera tomar mas de 200ms para el Establecimiento Definitivo de la Llamada. El Servidor PUEDE o no enviar Respuestas 1XX. Es Importante que lasRespuestas 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 solicitarpor su propia cuenta Mensajes de Respuesta 1XX enviando Mensajes Request. Status Code DefinitionsStatus Code DefinitionsStatus Code DefinitionsStatus Code DefinitionsStatus CodeStatus CodeStatus CodeStatus Code1XX1XX1XX1XX RESPUESTARESPUESTARESPUESTARESPUESTA INFORMATIVAINFORMATIVAINFORMATIVAINFORMATIVA. Respuesta que indica que elservidor SIP está ejecutando una acción Temporaría.Temporaría.Temporaría.Temporaría. Estoes, que el establecimiento de la llamada está en proceso yno hay todavía una respuesta definitiva.

32



63



‘‘Status CodeStatus Code’’: 2XX : 2XX ““Respuesta OKRespuesta OK”” SignificadoSignificadoSignificadoSignificado2XX2XX2XX2XX RESPUESTARESPUESTARESPUESTARESPUESTA OKOKOKOK. El Servidor le indica al Cliente que elRequest ha sido Exitoso/SuccessfullExitoso/SuccessfullExitoso/SuccessfullExitoso/Successfull. 200200200200 OK (Succesfully)OK (Succesfully)OK (Succesfully)OK (Succesfully)BYE:BYE:BYE:BYE:CANCEL:CANCEL:CANCEL:CANCEL:INVITE:INVITE:INVITE:INVITE:OPTIONS:OPTIONS:OPTIONS:OPTIONS:REGISTER:REGISTER:REGISTER:REGISTER:Status CodeStatus CodeStatus CodeStatus CodeLa Información Retornada con esta Respuesta depende del Método del Request Empleado. Terminación de Llamada. Cuerpo del Mensaje Vacío.Búsqueda Cancelada. Cuerpo del Mensaje Vacío. El Llamado se ha Unido a la Sesión (ha Aceptado Unirse). El Cuerpo del Mensaje indica las Capacidades del Llamado.El Llamado ha Aceptado Compartir sus Capacidades, las cuales están en el Cuerpo del Mensaje. Proceso Exitoso de Registración. Información en el Cuerpo del Mensaje.



64



‘‘Status CodeStatus Code’’: 3XX : 3XX ““Respuesta de RedirecciRespuesta de Redireccióónn”” SignificadoSignificadoSignificadoSignificado300300300300 Multiple ChoicesMultiple ChoicesMultiple ChoicesMultiple Choices (Selección Múltiple)301301301301 Moved PermanentlyMoved PermanentlyMoved PermanentlyMoved Permanently (Movida Permanente)302302302302 Moved Temporarily (Movida Temporalmente)Moved Temporarily (Movida Temporalmente)Moved Temporarily (Movida Temporalmente)Moved Temporarily (Movida Temporalmente)303303303303 Alternative ServiceAlternative ServiceAlternative ServiceAlternative Service (Servicio Alternativo)305305305305 Use ProxyUse ProxyUse ProxyUse Proxy (Usar Proxy)380380380380 QueuedQueuedQueuedQueued (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 Coincidao No con Direcciones de Reenvío Transmitidas Anteriormente. Status CodeStatus CodeStatus CodeStatus Code3XX3XX3XX3XX RESPUESTARESPUESTARESPUESTARESPUESTA DEDEDEDE REDIRECCIÓNREDIRECCIÓNREDIRECCIÓNREDIRECCIÓN. Las Respuestas 3XX leinforman al Cliente acerca de la Localización del usuarioLlamado ó Acerca de un Servicio Alternativo que estáDisponible para hacer la Llamada. Con esta Respuesta losClientes DEBERÍAN terminar la Búsqueda y PUEDENIniciar nuevas Búsquedas.

33



65



‘‘Status CodeStatus Code’’: 4XX : 4XX ““Error de ClienteError de Cliente”” SignificadoSignificadoSignificadoSignificado400400400400 Solicitud ErradaSolicitud ErradaSolicitud ErradaSolicitud Errada401401401401 No AutorizadoNo AutorizadoNo AutorizadoNo Autorizado402402402402 Requerimiento ErradoRequerimiento ErradoRequerimiento ErradoRequerimiento Errado403403403403 ProhibidoProhibidoProhibidoProhibido404404404404 No EncontradoNo EncontradoNo EncontradoNo Encontrado405405405405 Método No PermitidoMétodo No PermitidoMétodo No PermitidoMétodo No Permitido406406406406 No AceptadoNo AceptadoNo AceptadoNo Aceptado407407407407 Se Requiere Autenticación del ProxySe Requiere Autenticación del ProxySe Requiere Autenticación del ProxySe Requiere Autenticación del Proxy408408408408 La Solicitud Sobrepaso el Tiempo de EsperaLa Solicitud Sobrepaso el Tiempo de EsperaLa Solicitud Sobrepaso el Tiempo de EsperaLa Solicitud Sobrepaso el Tiempo de Espera410410410410 GoneGoneGoneGone413413413413 Solicitud muy LargaSolicitud muy LargaSolicitud muy LargaSolicitud muy Larga414414414414 Solicitud URI muy LargaSolicitud URI muy LargaSolicitud URI muy LargaSolicitud URI muy Larga415415415415 Tipo/Media No SoportadoTipo/Media No SoportadoTipo/Media No SoportadoTipo/Media No SoportadoStatus CodeStatus CodeStatus CodeStatus Code

ERROR DE CLIENTE (REQUEST FAILURE). ERROR DE CLIENTE (REQUEST FAILURE). ERROR DE CLIENTE (REQUEST FAILURE). ERROR DE CLIENTE (REQUEST FAILURE). 4XX4XX4XX4XX



66



‘‘Status CodeStatus Code’’: 4XX : 4XX ““Error de ClienteError de Cliente”” SignificadoSignificadoSignificadoSignificado416416416416 Esquema URI NO SoportadoEsquema URI NO SoportadoEsquema URI NO SoportadoEsquema URI NO Soportado420420420420 Extensión ErradaExtensión ErradaExtensión ErradaExtensión Errada421421421421 Extensión RequeridaExtensión RequeridaExtensión RequeridaExtensión Requerida423423423423 Intervalo Algo BreveIntervalo Algo BreveIntervalo Algo BreveIntervalo Algo Breve480480480480 Temporalmente No DisponibleTemporalmente No DisponibleTemporalmente No DisponibleTemporalmente No Disponible481481481481 Transacción No ExistenteTransacción No ExistenteTransacción No ExistenteTransacción No Existente482482482482 Loop DetectadoLoop DetectadoLoop DetectadoLoop Detectado483483483483 Exceso de SaltosExceso de SaltosExceso de SaltosExceso de Saltos484484484484 Dirección IncompletaDirección IncompletaDirección IncompletaDirección Incompleta485485485485 AmbiguoAmbiguoAmbiguoAmbiguo486486486486 OcupadoOcupadoOcupadoOcupado487487487487 Solicitud TerminadaSolicitud TerminadaSolicitud TerminadaSolicitud Terminada488488488488 Solicitud No AceptadaSolicitud No AceptadaSolicitud No AceptadaSolicitud No Aceptada491491491491 Solicitud PendienteSolicitud PendienteSolicitud PendienteSolicitud Pendiente493493493493 IndescifrableIndescifrableIndescifrableIndescifrableStatus CodeStatus CodeStatus CodeStatus Code

4XX4XX4XX4XX ERROR DE CLIENTE (REQUEST FAILURE).

34



67



‘‘Status CodeStatus Code’’: 5XX : 5XX ““Error de ServidorError de Servidor”” SignificadoSignificadoSignificadoSignificado500500500500 Server Internal Error Server Internal Error Server Internal Error Server Internal Error (Error Interno del Servidor)501501501501 Not Implemented Not Implemented Not Implemented Not Implemented (No Implementado)502502502502 Bad Gateway Bad Gateway Bad Gateway Bad Gateway (Gateway Errado)503503503503 Service Unavailable Service Unavailable Service Unavailable Service Unavailable (Servicio No Disponible)504504504504 Gateway Time-Out Gateway Time-Out Gateway Time-Out Gateway Time-Out (Tiempo de Espera Agotado en el Gateway)505505505505 Version Not Supported Version Not Supported Version Not Supported Version Not Supported (Versión de Protocolo No Soportada)513513513513 Mensaje muy LargoMensaje muy LargoMensaje muy LargoMensaje muy LargoStatus CodeStatus CodeStatus CodeStatus Code5XX5XX5XX5XX Server Failure (Error en el Servidor).Server Failure (Error en el Servidor).Server Failure (Error en el Servidor).Server Failure (Error en el Servidor).



68



‘‘Status CodeStatus Code’’: 6XX : 6XX ““Error GlobalError Global”” SignificadoSignificadoSignificadoSignificado600600600600 Busy EverywhereBusy EverywhereBusy EverywhereBusy Everywhere (Ocupado en Otra Solicitud)603603603603 Decline Decline Decline Decline (Declinar)604604604604 Does Not Exist Anywhere Does Not Exist Anywhere Does Not Exist Anywhere Does Not Exist Anywhere (No Existe el Llamado)606606606606 Not Acceptable Not Acceptable Not Acceptable Not Acceptable (No Aceptado)Status CodeStatus CodeStatus CodeStatus Code6XX6XX6XX6XX Global Failures (Fallas Globales). Global Failures (Fallas Globales). Global Failures (Fallas Globales). Global Failures (Fallas Globales).

35



69



‘‘ReasonReason--PhrasePhrase’’

� Cadena de caracteres ASCII (‘String’) que describe el ‘Status-Code’.

� Enfoque No Autómata del Proceso.

� Ideal para Debug en Tiempo Real.



70


(Resumen R(Resumen Ráápido)pido)

36



71

Resumen CaracterResumen Caracteríísticas de SIPsticas de SIP�� IntegraciIntegracióón a ambientes de WEB/INTERNET. Pensado n a ambientes de WEB/INTERNET. Pensado especialmente para IP.especialmente para IP.

�� Modelo Cliente/Servidor.Modelo Cliente/Servidor.

�� Mensajes de PeticiMensajes de Peticióón y Respuesta. n y Respuesta.

�� Reutiliza conceptos de otros servicios como: HTTP, Reutiliza conceptos de otros servicios como: HTTP, SMTP y DNS. (Basados en Texto Plano).SMTP y DNS. (Basados en Texto Plano).



72

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

�� Servidores SIP: Proxy, Servidores SIP: Proxy, RegistraciRegistracióónn, Redirecci, Redireccióón y n y LocalizaciLocalizacióón. n.

� Uso de URI’s.

� Generalmente el Cuerpo de los Mensajes contiene Descripciones de las Sesiones Multimedia.

� Localización Basada en DNS.

37



73

Resumen CaracterResumen Caracteríísticas de SIPsticas de SIP�� Cabeceras como mCabeceras como méétodo de Ampliacitodo de Ampliacióón. n.

�� Actualmente utiliza SDP como mActualmente utiliza SDP como méétodo de descripcitodo de descripcióón de n de sesiones. sesiones.

�� El mensaje de oferta especifica el conjunto de medios y El mensaje de oferta especifica el conjunto de medios y codecscodecs que se pretende usar.que se pretende usar.



74

Resumen CaracterResumen Caracteríísticas de SIPsticas de SIP�� El receptor de la oferta genera una respuesta indicando El receptor de la oferta genera una respuesta indicando si acepta cada uno de los medios ofertados, y los si acepta cada uno de los medios ofertados, y los codecscodecsque admite. que admite.

��Las ofertas/respuestas se pueden intercambiar durante Las ofertas/respuestas se pueden intercambiar durante sesiones activas.sesiones activas.

38



75


Diferencias entre SIP y H.323Diferencias entre SIP y H.323



76

Diferencias entre SIP y H.323Diferencias entre SIP y H.323�� Las diferencias entre ambos son consecuencia de las Las diferencias entre ambos son consecuencia de las diferencias entre el IETF y la ITUdiferencias entre el IETF y la ITU--T.T.

�� Las diferencias en cuanto a servicios soportados se Las diferencias en cuanto a servicios soportados se reducen a medida que se desarrollan nuevas versiones.reducen a medida que se desarrollan nuevas versiones.

�� Mucha propaganda cuando menos inexacta, incluso Mucha propaganda cuando menos inexacta, incluso desde organizaciones aparentemente rigurosas.desde organizaciones aparentemente rigurosas.

39



77

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

�� Los anLos anáálisis comparativos existentes son errlisis comparativos existentes son erróóneos o no neos o no estestáán actualizados.n actualizados.

�� Las comunidades existentes en torno a SIP y H.323 Las comunidades existentes en torno a SIP y H.323 tienen tradiciones distintas.tienen tradiciones distintas.



78

Diferencias entre SIP y H.323Diferencias entre SIP y H.323�� H.323 especifica servicios, mientras que SIP es sH.323 especifica servicios, mientras que SIP es sóólo un lo un protocolo de seprotocolo de seññalizacializacióón para dar base a servicios.n para dar base a servicios.

�� H.323 engloba un amplio conjunto de protocolos de H.323 engloba un amplio conjunto de protocolos de implementaciimplementacióón obligatoria.n obligatoria.

�� NegociaciNegociacióón de capacidades mn de capacidades máás completa y compleja s completa y compleja en H.323.en H.323.

�� H.323 define H.323 define mecanimosmecanimos de gestide gestióón y administracin y administracióón de n de la red.la red.

40



79

Diferencias entre SIP y H.323Diferencias entre SIP y H.323�� En la arquitectura SIP, funciones y servicios como En la arquitectura SIP, funciones y servicios como garantgarantíía de calidad, directorio o descripcia de calidad, directorio o descripcióón de sesiones n de sesiones son ortogonales.son ortogonales.

��SIP estSIP estáá integrado en la infraestructura integrado en la infraestructura webweb y y proporciona servicios de mensajerproporciona servicios de mensajeríía instanta instantáánea.nea.

��SIP tiene mejores mecanismos de detecciSIP tiene mejores mecanismos de deteccióón de bucles, n de bucles, espirales y otros errores de configuraciespirales y otros errores de configuracióón de la red.n de la red.



80

Diferencias entre SIP y H.323Diferencias entre SIP y H.323�� El 3gpp ha adoptado SIP como protocolo de El 3gpp ha adoptado SIP como protocolo de seseññalizacializacióón.n.

��Desde las primeras versiones, el inicio de llamadas es Desde las primeras versiones, el inicio de llamadas es mmáás s rapidorapido con SIP.con SIP.


1


Capitulo 07(a): Protocolo IAX


Inter Asterisk eXchange

2




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


3




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

4




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


5




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

a) Establecimiento

b) Flujo de Datos Multimedia (M y F)

c) Liberación

6




� Procesamiento de Llamadas con IAX2:Procesamiento de Llamadas con IAX2:

a)a) EstablecimientoEstablecimiento: 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’.


7





b)b) Flujo de Datos MultimediaFlujo de Datos 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 (Tramas F (FramesFrames)): 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.

8





c)c) LiberaciLiberacióón n óó DesconexiDesconexióónn: Cualquiera de los involucrados, Llamante ó Llamado, puede terminar la llamada enviando una Trama ‘HANGUP’ y esperando una Trama de Confirmación ‘ACK’.

NotaNota: 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. !!!


9




� Tramas IAX2 Tipo Tramas IAX2 Tipo ‘‘FF’’ (Full Frame):(Full Frame):

� Cada Trama F enviada debe ser respondida explícitamente.

10




� Tramas IAX2 Tipo Tramas IAX2 Tipo ‘‘FF’’ (Full Frame):(Full Frame):� 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.


11




� Tramas IAX2 Tipo Tramas IAX2 Tipo ‘‘FF’’ (Full Frame):(Full Frame):� 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.

12




� Tramas IAX2 Tipo Tramas IAX2 Tipo ‘‘MM’’ (Mini Frame):(Mini Frame):

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


13




� Tramas IAX2 Tipo Tramas IAX2 Tipo ‘‘MM’’ (Mini Frame):(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.

14




Tipo de Trama Descripción Observaciones1 DTMF Señalización DTMF2 Voz El Campo Sub-Clase especifica el Codec de Voz Utilizado3 Video El Campo Sub-Clase especifica el Codec de Video Utilizado4 Control Mensajes de Control de Sesión. El Campo Sub-Clase especifica

el Tipo de Control.5 No Usado6 Control IAX2 Control de Protocolo IAX2. El Campo Sub-Clase especifica el

Tipo de Control IAX2.7 Texto8 Imagen9 HTML

Tipo de Trama IAX2Tipo de Trama IAX2


15




SubSub--Campo, para Tipo de Trama = 0x02Campo, para Tipo de Trama = 0x02Tipo de Tipo de CodecCodec UtilizadoUtilizado

Tipo de Codec0x0010x0020x0040x0080x0800x1000x2000x400

LPC10G.711a

G.729SpeexiLBC

Descripción del CodecG.723.1GSMG.711u

16




SubSub--Campo, para Tipo de Trama = 0x04Campo, para Tipo de Trama = 0x04Tipo de Control de SesiTipo de Control de Sesióónn

Tipo de Control0x001 HANGUP Llamada Colgada.0x002 RING Telefono Repicando.0x003 RINGINBACK0x004 ANSWER Respuesta.0x005 BUSY Usuario Ocupado.0x008 CONGESTION Congestión.0x00E CALL PROGRESS Llamada en Progreso.

Descripción del Cotrol


17




SubSub--Campo, para Tipo de Trama = 0x06Campo, para Tipo de Trama = 0x06Tipo de Control IAX2Tipo de Control IAX2

Tipo de Control1 NEW Inicio de Llamada.2 PING Envío de PING.3 PONG Respuesta de PING.4 ACK Confirmación ACK.5 HANGUP Inicio de Desconexión.6 REJECT Mensaje de Rechazo.7 ACCEPT Mensaje de Aceptación.8 AUTHREQ Petición de Autenticación.9 AUTHREP Respuesta de Autenticación.

10 INVAL Llamada Inválida.11 LAGRQ Petición de LAG.12 LAGRP Respuesta de LAG.13 REGREQ Petición de Registro.14 REGAUTH Autenticación de Registro.15 REGACK Confirmación de Registro.16 REGREJ Negación de Registro.


18




SubSub--Campo, para Tipo de Trama = 0x06Campo, para Tipo de Trama = 0x06Tipo de Control IAX2Tipo de Control IAX2

Tipo de Control17 REGREL Liberación de Registro.18 VNAK Petición de Retransmisión.19 DPREQ Petición de 'DIALPLAN'.20 DPREP Respuesta de 'DIALPLAN'.21 DIAL Marcado.22 TXREG Petición de Transferencia.23 TXCNT Conexión de Transferencia.24 TXACC Aceptación de Transferencia.25 TXREADY Transferencia Preparada.26 TXREL Liberación de Transferencia.27 TXREJ Rechazo de Transferencia.28 QUELCH Detiene Transmisión de Audio.29 UNQUELCH Continua Transmisión de Audio.32 MWI Indicador de Mensaje de Espera.33 UNSUPPORT Mensaje No Soportado.



19




ComparaciComparacióón de IAX2 con SIPn de IAX2 con SIP

�� SIPSIP

�� EstEstáándar IETF (ndar IETF (RFCRFC’’ss))

�� CodificaciCodificacióón ASCII/Texton ASCII/Texto

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

�� Canal SIP de SeCanal SIP de Seññalizacializacióón UDP n UDP y Canal de Multimedia UDPy Canal de Multimedia UDP

�� Efecto de Efecto de BarerasBareras NATNAT’’ss y y FirewallFirewall ((----))

�� Puerto UDP 5060, para Puerto UDP 5060, para SeSeññalizacializacióónn

�� IAX2IAX2

� MarkMark SpencerSpencer ((AsteriskAsterisk))

�� CodificaciCodificacióón Binarian Binaria

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

�� Un solo Canal UDP para Un solo Canal UDP para SeSeññalizacializacióón y Multimedian y Multimedia

�� Efecto de Barreras Efecto de Barreras NATNAT’’ss y y FirewallFirewall ((------))

�� Puerto UDP 4569 para TodoPuerto UDP 4569 para Todo

20




ComparaciComparacióón de IAX2 con SIPn de IAX2 con SIP

�� SIPSIP

�� Soporta Soporta RedireccionamientoRedireccionamiento; ; Flujo Multimedia de Extremo a Flujo Multimedia de Extremo a ExtremoExtremo

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

�� IAX2IAX2

� No Soporta No Soporta RedireccionamientoRedireccionamiento; dado que ; dado que la Multimedia va la Multimedia va MultiplexadaMultiplexadaen el mismo Canal de en el mismo Canal de SeSeññalizacializacióónn

�� Funcionalidades Especiales Funcionalidades Especiales para IPpara IP--PABX: GestiPABX: Gestióón de n de ‘‘DIALPLANDIALPLAN’’


21



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)

1

1


Capítulo VIII: Calidad de Servicio QoS

Calidad de Servicio Calidad de Servicio QoSQoS

en VoIPen VoIP


2



Calidad de Servicio Calidad de Servicio QoSQoS en VoIPen VoIP

DefiniciDefinicióónn

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 Retardo en Conexiones ‘‘EndEnd toto EndEnd’’

•• Ancho de BandaAncho de Banda

•• JitterJitter (Variaci(Variacióón del Retardo)n del Retardo)

•• PPéérdida de Paquetesrdida de Paquetes

2

3




Aspectos a ConsiderarAspectos 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.

4




¿¿CCóómo se Implementa mo se Implementa QoSQoS??

� 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

3

5




DefinicionesDefiniciones

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

6





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

4

7





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

8





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

5

9




Protocolos de Protocolos de QoSQoS

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

1

1


Capitulo IX: Aplicaciones de VoIP

Aplicaciones de VoIPAplicaciones de VoIP

Ing. JosIng. Joséé CotCotúúa, Agosto 2007a, Agosto 2007

2




VoIP y la Telefonía Analógica y Digital Tradicional (PSTN)

�� TelefonTelefoníía Anala Analóógica Tradicional: 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

3




Teléfonos IP

�� HardHard--PhonePhone IP (TelIP (Telééfonos IP): fonos IP): los hay para SIP, H.323 e IAX2.

�� WirelessWireless--PhonePhone IP (TelIP (Telééfonos IP Inalfonos IP Inaláámbricos):mbricos): los hay en IEEE 802.11a/b/g

� SoftwareSoftware--PhonePhone IP (IP (SoftphoneSoftphone): ): teléfonos IP, SIP/IAX2/H.323, que se 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ú.

4




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 e-mail’s.

3

5




VoIP para Radiocomunicación Móvil Terrestre

�� Radiocomunicación Móvil Terrestre,

Tradicional:Tradicional: Señalización y Voz Analógica

TrunkingTrunking ((SmartnetSmartnet, , SmartzoneSmartzone, etc.):, etc.): Señalización Digital y Voz Analógica

SmartrunkSmartrunk:: Señalización Digital y Voz Analógica. Migración de Tradicional a Trunking. Sistema Mixto.

TetraTetra:: Señalización y Voz Digitalizada.

� Sistemas en VFH, UHF, 800MHz y 900MHz.

6





4

7





8





Otras Alternativas.Otras Alternativas.--

� Diseño propio con Microcontroladores y/o Sistemas Embedidos.

� Utilizar Gateway’s y/o Adaptadores y crear nuevas Soluciones.

� IP-PABX Asterisk ya dispone de Módulos para VoIP basada en PTT.

5

9




VoIP y Redes VPN

Protocolos para Redes VPNProtocolos para Redes VPN

� IPSec

� OpenVPN

� VTUN

� L2TP

� Túneles GRE

� Túneles IPv4/IPv6

� Otros: PPtP, EoIP, Bridge’s, etc.

Aspectos a ConsiderarAspectos a Considerar

� La VPN introduce Retardo.

� ‘Overhead’ e Incremento Ancho de Banda.

� El Cifrado de la VPN.

� VPN con Compresión.

� Aspectos de Firewall y NAT’s.

10




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.

6

11




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?

12




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

7

13




Otras Tecnologías de Voz sobre Paquetes

� Voz sobre ATM: VoATM.

� Voz sobre Frame Relay: VoFR.

� Voz sobre MPLS: VoMPLS.

� Voz sobre Ethernet: VoETH.

Arquitectura de Protocolos TCP/IP - Blog...

Documents

Transcript of Arquitectura de Protocolos TCP/IP - Blog...