Protocolos de
señalización
- Abstract
- Componentes y
Protocolos - La suite
H.323 - Variantes en
H.323 - Protocolos MGCP y
SIP - Otros protocolos de
señalización
La Telefonía–IP ha sido
tratada en varios números de Journal Monografía. En algunos casos ligados a
desarrollos de tecnología en
particular (Softswitch o Gateway IP-IP), en otros ligados a la
topología de la red (la red de distribución o de telefonía), por
último ligados a productos.
Este número se ocupa de describir el funcionamiento en
detalle del protocolo H.323 y
una introducción a otros protocolos de
señalización en la red telefónica. Por
ejemplo, el caso de MGCP y SIP como competidores de H.323 o los
protocolos de señalización de la red tradicional
como ser DTMF, MFC-R2 y SS7.
Desde el punto de vista de esta monografía
los protocolos son intercambio de mensajes cuya función es
la de establecer, mantener y gestionar una conexión
telefónica. Además permiten el management de la red
en su conjunto. Por ser un proceso de
intercambio de mensajes son analizados mediante figuras de
evolución temporal.
1- ANTECEDENTES
La voz sobre redes IP VoIP (Voice over
IP) inicialmente se implementó para reducir el ancho
de banda mediante compresión vocal, aprovechando los
procesos de
compresión diseñados para sistemas
celulares en la década de los años 80. En
consecuencia, se logró reducir los costos en el
transporte
internacional. Luego tuvo aplicaciones en la red de servicios
integrados sobre la LAN e Internet. Con posterioridad
se migró de la LAN (aplicaciones privadas) a la WAN
(aplicaciones pública) con la denominación
IP-Telephony.
En telefonía pública se pueden observar
diferencias entre un operador local y otro de larga distancia.
Cuando nos referimos a Telefonía-IP, nos ocupamos de la
aplicación pública local. Existen varias
características que hacen de la Telefonía-IP un
problema de complejidad elevada respecto de la VoIP. Algunos
de ellos son las siguientes:
1- Interoperatividad. Una diferencia inicial entre VoIP y
Telefonía-IP es la interoperatividad con las redes
telefónicas actuales. En el caso de iplan se disponen de
dos tipos de Interconexión a la PSTN: desde un switch class-4
(tránsito) y directamente desde Gateway-E1.
2- Calidad de
Servicio Garantizada. Mientras VoIP se piensa en el
ámbito de interconexión mediante Internet (sin
calidad de
servicio
asegurada); en Telefonía-IP se piensa en una Backbone de
alta velocidad
no-bloqueante para garantizar la calidad de servicio mediante
herramientas
de QoS (en redes ATM) o mediante "Fuerza Bruta"
(en redes Gigabit como la de iplan). En Telefonía-IP se
aplica el concepto de
carrier-grade. Este concepto puede incluir varios
aspectos:
-redundancia de equipamiento para lograr disponibilidad
elevada (por ejemplo, 99,99%),
-calidad vocal garantizada (bajos indicadores de
errores, de retardo, de jitter y de eco, etc),
3- Servicios de Valor
Agregado. Se requiere la disponibilidad de servicios de valor
agregado, similar a los ofrecidos en la red PSTN mediante la
señalización SS7, conocido como red inteligente
IN (Inteligent Network). En iplan se aplica la
Plataforma de Servicios COSO (Journal No 2) para
los servicios de IN-Virtual, así como el Softswitch
(Journal No 4).
2.1- Componentes del Sistema.
Los Componentes de una red de
Telefonía-IP se muestran en la Figura 1.
2.1.1- Terminales de Usuario. Pueden encontrarse
clientes que
desean utilizar sus teléfonos convencionales y aquellos
que cambian hacia una Telefonía-IP integrada con su LAN.
Cuando un cliente desea
instalar un servicio integrado de telefonía y datos, la
red LAN es
donde se conectan los terminales, los elementos de
interconexión al exterior (router,
proxy o
gateway GW) y el gatekeeper GK local. El servicio de
Telefonía-IP puede ofrecerse sin necesidad de una LAN, por
ejemplo mediante líneas analógicas que se conectan
a la vieja PABX del usuario.
En el caso de utilizar la LAN, los terminales se
comunica en forma bidireccional en tiempo real.
Se utilizan software en la PC o
teléfonos dedicados (IP-Phone). De esta forma el mismo
terminal de cableado
estructurado se utiliza para ambos componentes del escritorio
(el teléfono y la PC). Para el caso de utilizar
la vieja PABX, se requiere instalar un Gateway de usuario FXS o
E1. En iplan se utiliza el concepto de Nodo de Manzana para la
distribución de líneas analógicas FXS
(Journal No 1).
2.1.2- Gateway GW-FXS. Provee la conectividad
entre el mundo IP y el de telefonía convencional. Realizan
la emulación de interfaz FXO/FXS (Foreing
Exchange Station/Office), lo que permite adaptar una PABX a
la VoIP. Se conecta a la PABX convencional por un lado y a la red
de transporte IP por el otro, lo que permite conectar un usuario
convencional a la red de Telefonía-IP pública.
Permite la traslación de direcciones desde IP a la ITU
E.164 de la red telefónica convencional. Es decir,
actúa de interfaz desde la red IP (dirección de 4 bytes) hacia la PSTN
(dirección de 16 dígitos decimales).
2.1.3- Gateway GW-E1. Este GW se encuentra entre
la red IP y la PSTN para interconectar distintos proveedores de
telefonía mediante técnicas
de transporte diversas. Entre las funciones del GW
se encuentra: la conversión de codificación vocal; la supresión de
silencios y señalización DTMF; la supresión
de eco; generar las conexiones RTP; etc.
Figura 1. Componentes
en una red de Telefonía-IP.
2.1.4- Gatekeeper GK. Realiza el control para el
procesamiento de la llamada en protocolo H.323. Es un software
que puede funcionar por ejemplo sobre Linux u otro
sistema
operativo. Pueden existir varios GK por razones de
redundancia y compartir la carga en la red. El principal
parámetro del GK es la cantidad de llamadas cursadas en
las horas pico. Dicho parámetros se conoce como
BHCA (Busy Hour Call Attempts).
Las funciones del GK son:
-Traslación de direcciones desde una
dirección "alias" del terminal hacia dirección de
capa 3/4 (socket);
-Control de admisión para autorizar el acceso a
la red mediante mensajes ARQ/ACF/ARJ (protocolo RAS);
-Control de ancho de banda mediante mensajes BRQ/BRJ/BCF
(protocolo RAS);
-Señalización de control de llamada para
autorización o rechazo de llamadas;
-Servicios de directorio;
-Servicio de reservación de ancho de banda,
etc.
2.1.5- MGC (Media Gateway Controller) o
Softswitch. Es el control de procesamiento con la red
pública PSTN. El MGC es un software que contiene en su
interior al GK. Realiza las siguientes funciones:
-Control de llamada (asimilable al punto de
conmutación en las PABX);
-Identificación del tráfico H.323 y
aplicación de las políticas
apropiadas;
-Limitación del tráfico H.323 sobre la LAN
y WAN;
-Entrega archivos
CDR (Call Detail Records) para la
facturación (Billing);
-Realiza la interfaz con las redes
inteligentes;
-Inserta calidad de servicio e implementa
políticas de seguridad.
Los MGC pueden colocarse en
configuración Failover para protección ante fallas.
Los GW son controlados por el MGC mediante el protocolo MGCP
(Media Gateway Control Protocol). Como protocolo de
señalización hacia la PSTN se utilizan ISUP/TCAP de
la serie SS7 o el MFC-R2 para centrales sin facilidad SS7. En las
redes de Telefonía-IP públicas, el GK se encuentra
integrado al MGC. También se dispone de servidores para
RADIUS (para gestión
de seguridad), para LDAP (servicio de directorio y memoria) y para
AAA (funciones de autentificación y cobro).
Las funciones del MGC pueden ser
realizadas mediante dos técnicas distintas. La primera
toma del mundo de la telefonía pública convencional
las partes que pueden ser utilizadas (procesador
central, memoria, cómputo de tráfico, etc.) y
eliminan aquellas que no corresponden (red de conmutación
de circuitos). En
la segunda, se trata de un software absolutamente nuevo (conocido
como Softswitch) que corre sobre una plataforma genérica
(por ejemplo, Linux). De acuerdo con la nomenclatura de
la norma H.323 el controlador de llamada es el Gatekeeper GK; sin
embargo, se ha popularizado también la denominación
MGC para una mayor extensión de funciones.
2.1.6- Las nubes IP y PSTN. Los Router conforman
la "nube" IP. Son los componentes que distribuidos en la red IP
permiten el enrutamiento de los paquetes entre GW (reemplazan a
los centros de conmutación de las PSTN). La PSTN
(Public Switched Telephone Network) conforma la "nube" de
telefonía convencional con conmutación de
circuitos.
2.2- Los Protocolos.
La Telefonía-IP utiliza como soporte cualquier
medio basado en routers y los protocolos de transporte UDP/IP. El
modelo de
capas diseñado en 1981 para IP tenía prevista que
la voz estuviera soportada sobre protocolos RTP/IP. El modelo
actual en cambio, agrega
RTP/UDP/IP. Existen varios organismos involucrados en los
standards para la señalización: el ITU-T
(que dio lugar a la suite de protocolos H.323, por ejemplo); el
ETSI (con el proyecto Tiphon)
y el IETF (que administra los protocolos de Internet, SIP
por ejemplo).
Los protocolos de señalización utilizados
en Telefonía-IP son de diversos tipos. El ITU-T H.323 es
el primero aplicado para acciones
dentro de una Intranet
fundamentalmente. Es una cobertura para una suite de protocolos
como el H.225, H.245 y RAS que se soportan en TCP y UDP. El IETF
define otros tipos de protocolos: el MGCP para el control de las
gateway a la red pública PSTN y SIP hacia las redes
privadas o públicas (ver más adelante una
introducción a ambos).
La señal vocal se transmite sobre el protocolo de
tiempo real RTP (con el control RTPC) y con transporte sobre UDP.
El protocolo de reservación de ancho de banda RSVP puede
ser de utilidad en
conexiones unidireccionales (distribución de señal
de broadcasting, por ejemplo).
La señalización SS7 se utiliza hacia la
red pública PSTN. De forma que se disponen de los
protocolos ISUP/SCCP/TCAP que se transmiten sobre MTP en la PSTN
y sobre TCP/IP en la
red de paquetes. El protocolo Q.931 (derivado de ISDN) se utiliza
para establecer la llamada en H.323.
2.3- Calidad de servicio en la nube
IP.
Dos son los mitos que
involucran a la Telefonía-IP. Uno se refiere a la baja
calidad de Internet. Se confunden las prestaciones
de los accesos dial-up con el uso de canales de transporte
punto-a-punto con calidad contratada. Otro se refiere al medio de
transportar a los paquetes IP. Aquí se menciona que solo
ATM está en condiciones de garantizar la calidad de
servicio. Nuevamente se ignora la serie de herramientas que posee
una red IP y Gigabit-Ethernet para
garantizar una calidad de servicio.
Los problemas que
son evidentes en una red de VoIP, son la Latencia, el Jitter y el
Eco. En Telefonía-IP estos problemas son resueltos
mediante diversas técnicas.
2.3.1- Latencia. Se define así al gap en
la conversación debido a los retardos acumulados. El
primer retardo es en la matriz de
switch (el retardo producido por el proceso
store-and-forward) y el retardo de procesamiento (cambio
de encabezado de paquetes, por ejemplo). A esto se suman los
retardos propios del proceso de compresión vocal
(insignificante en codificación G.711 y más elevado
en aplicaciones con G.729).
Los retardos en la red pueden ser reducidos mediante el
protocolo de reservación RSVP. El retardo debido a la
compresión vocal se puede eliminar usando la velocidad de
64 kbps sin compresión (G.711). Este último aspecto
es muy interesante. Inicialmente VoIP se desarrolló para
reducir costos con menor velocidad y usando la infraestructura de
Internet. Actualmente, con el modelo de una red IP de alta
velocidad, la compresión vocal no es obligatoria en una
red local. En este caso, Telefonía-IP se desarrolla para
brindar una red de servicios integrados soportada en protocolo
IP, sin límites en
el ancho de banda.
Cuando se trabaja con señales
en Internet en cambio, el ancho de banda es limitado y por ello
se requiere compresión vocal. Por ejemplo, el
tamaño de un paquete RTP incluye 66 Bytes de encabezado
(26 de MAC, 20 de IP, 8 de UDP y 12 de RTP) y 71 de carga
útil. El overhead puede ser comprimido. La información vocal puede ser reducida. Por
ejemplo: para G.723 trabajando a 6,3 kbps (trama de 30 mseg) sin
supresión de silencios se requieren 11 paquetes/seg y 71
Bytes/paquete. Si integramos la supresión de silencios
(técnica VAD) esta velocidad se reduce
sustancialmente.
2.3.2- Jitter. Es el efecto por el cual el
retardo entre paquetes no es constante. Se trata de una latencia
variable producida por la congestión de tráfico en
el backbone de red, por distinto tiempo de tránsito de
paquetes debido al connectionless, etc. Se puede utilizar
un buffer para distribuir los paquetes y reducir el jitter, pero
introduce un retardo adicional. Lo correcto es incrementar el
ancho de banda del enlace; solución posible en un backbone
pero de menor posibilidad en los enlaces WAN. Otra posibilidad es
la formación de colas para prioridad de tráfico de
telefonía sobre los de datos.
2.3.3- Eco. Las características anteriores
(latencia y jitter) pueden producir eco sobre la señal
telefónica, lo cual hace necesario el uso de canceladores
de eco (ITU G.168). Se tienen 2 tipos de eco. Uno tiene alto
nivel y poco retardo y se produce en el circuito híbrido
de 2 a 4 hilos local; mientras que otro es de bajo nivel y gran
retardo y se produce en el circuito separador híbrido
remoto. El cancelador de eco se construye mediante la
técnica de ecualización transversal autoadaptativa.
Consiste en usar una parte de la señal de
transmisión para cancelar el eco producido por la
desadaptación de impedancias en el circuito híbrido
que convierte de 4 a 2 hilos.
2.3.4- Throughput. Es la capacidad de un enlace
de transportar información útil. Representa a la
cantidad de información útil que puede transmitirse
por unidad de tiempo. No tiene relación directa con el
delay. (por ejemplo, se puede tener un enlace de alto throughput
y alto delay o viceversa, como sería por ejemplo un enlace
satelital de 2Mbps y 500 mseg de delay).
2.3.5- Packet Loss. Es la tasa de perdida de
paquetes. Representa el porcentaje de paquetes transmitidos que
se descartan en la red. Estos descartes
pueden ser producto de
alta tasa de error en alguno de los medios de
enlace o por sobrepasarse la capacidad de un buffer de una
interfaz en momentos de congestión. Los paquetes perdidos
son retransmitidos en aplicaciones que no son de Tiempo Real; en
cambio para telefonía, no pueden ser recuperados y se
produce una distorsión vocal.
El delay afecta a la performance de aplicaciones
interactivas (por ejemplo, Telnet). El
throughput afecta a la performance de aplicaciones que mueven
grandes volúmenes de información (por ejemplo, Mail
y FTP). El
packet loss afecta a ambos tipos de aplicaciones. El jitter
afecta a aplicaciones de tiempo real como la voz y el video por
IP.
3.1- Familia de
protocolos H.32x.
Para aplicaciones de multimedia, las
primeras acciones se emprendieron con la definición de los
protocolos RTP/RTCP (RFC-1889). La norma del ITU-T H.225 utiliza
a RTP (está anexa enteramente de H.225). El ITU-T ha
definido standard de cobertura para distintos servicios, siendo
el que nos ocupa en este Journal, el H.323. Inicialmente se
presenta una descripción de la serie de standard
H.32x.
3.1.1- ITU-T H.320. Se ha
diseñado para tecnologías referidas como
velocidades Px64 kbps para video-teléfono. El
estándar cubre desde 64 a 2048 kbps con un retardo
inferior a 150 mseg. Se señala un protocolo de
conectividad internacional que permite la
comunicación entre aparatos de distinta producción y compatible con ISDN. La norma
H.320 involucra las funciones una familia de normas: H.261
para la señal de vídeo; G.721/722/728 para sonido; H.221
para el entramado de datos; H.230 para el control y H.242 para la
señalización. Determinan los componentes del
sistema de videoteléfono conectado a una central privada o
desde un acceso ISDN a 2×64 kbps. El algoritmo de
codificación de vídeo se indica el H.261; el
algoritmo de audio en AV.250; el control de sistema en H.242
(señalización dentro de banda) y H.230 (intercambio
de tramas de control); el multiplexor de las 3 señales
anteriores en H.221 y el adaptador hacia la red en
I.400.
3.1.2- ITU-T H.323. Esta norma data de 1996
(versión 1) y 1998 (versión 2) y ha sido generada
para sistemas de comunicación multimediales basado en
paquetes (redes que pueden no garantizar correctamente la calidad
de servicio QoS). Esta tecnología permite la
transmisión en tiempo real de vídeo y audio por una
red de paquetes. Es de suma importancia ya que los primeros
servicios de voz sobre protocolo Internet (VoIP) utilizan esta
norma. En la versión 1 del protocolo H.323v1 se
disponía de un servicio con calidad de servicio (QoS) no
garantizada sobre redes LAN. En
la versión 2 se definió la aplicación VoIP
independiente de la multimedia. Una versión 3 posterior
incluye el servicio de fax sobre IP
(FoIP) y conexiones rápidas entre otros.
La versión H.323v2 introduce una serie de
mejoras sobre la H.323v1. Algunas de ellas son:
-permite la conexión rápida (elimina
parte de tiempo de solicitud de
conexión);
-mediante H.235 introduce funciones de seguridad
(autentificación, integridad,
privacidad);
-mediante H.450 introduce los servicios
suplementarios;
-soporta direcciones del tipo RFC-822 (e-mail) y
del formato URL;
-mediante la unidad MCU permite el control de
llamadas multi-punto (conferencia);
-permite la redundancia de
gatekeeper;
-soporta la codificación de vídeo en
formato H.263;
-admite el mensaje RIP (Request in
Progress) para informar que la llamada no puede ser procesada
por el momento;
-provee la facilidad que el gateway informe al
gatekeeper sobre la disponibilidad de enlaces para mejorar el
enrutamiento de llamadas.
3.1.3- ITU-T H.324. Esta norma incluye la
codificación H.263 para la señal de vídeo.
El objetivo de
ITU-T H.263 es mejorar la calidad de H.261. Esta norma es
coherente con MPEG-4
desarrollado por la ISO.
Formalmente utiliza las mismas técnicas de
compresión de imagen con 5 a 15
imágenes/seg. H.324 permite la
interactividad entre terminales PC-multimediales, módem de
voz-datos, Browsers de web con
vídeo en vivo, videoteléfonos, sistemas de
seguridad, etc.
3.2- Protocolos de la Suite
H.323.
Ahora estudiemos con más detalle la suite
de protocolo que se conocen bajo el nombre genérico de
H.323.
3.2.1- Tráfico. El tráfico de
señal vocal se realiza sobre los protocolos UDP/IP. La
codificación de audio puede ser de diferentes tipos. Con
G.711 a velocidad es de 64 kbps. El ITU-T ratificó en 1995
a G.729 para las aplicaciones de VoIP. En tanto, el VoIP-Forum en
1997, liderado por Intel y Microsoft,
seleccionó a G.723.1 con velocidad de 6,3 kbps para la
aplicación VoIP. La codificación de vídeo se
realiza de acuerdo con H.263. Ambos servicios se soportan en el
protocolo de tiempo real RTP.
Figura 2.
Familia de protocolos para H.323.
3.2.2- Señalización. La
señalización se transporta sobre los protocolos
TCP/IP o UDP/IP. La familia de
protocolos de señalización en H.323 incluye los
siguientes protocolos (ver la Figura 2):
–H.225. Son los mensajes de control de
señalización de llamada que permiten establecer la
conexión y desconexión. Este protocolo describe
como funciona el protocolo RAS y Q.931. El H.225 define como
identificar cada tipo de codificador y discute algunos conflictos y
redundancias entre RTCP y H.245.
-Q.931. Este protocolo es definido
originalmente para señalización en accesos ISDN
básico. Es equivalente al ISUP utilizado desde el GW hacia
la red PSTN.
–RAS (Registration, Admission and
Status) utiliza mensajes H.225 para la comunicación
entre el GW y GK. Sirve para registración, control de
admisión, control de ancho de banda, estado y
desconexión.
–H.245. Este protocolo de
señalización transporta la información
no-telefónica durante la conexión. Es utilizado
para comandos
generales, indicaciones, control de flujo, gestión de
canales lógicos, etc. Se usa en las interfaz GW-GW y
GW-GK. El H.245 es una librería de mensajes con sintaxis
del tipo ASN.1. En particular codifica los dígitos
DTMF (Dual-Tone MultiFrequency) en el mensaje
UserInputIndication.
-H.235. Provee una mejora sobre H.323
mediante el agregado de servicios de seguridad como
autentificación y privacidad (criptografía). El H.235 trabaja soportado
en H.245 como capa de transporte. Todos los mensajes son con
sintaxis ASN.1.
3.2.3- Calidad de servicio. Se transporta
en protocolos UDP/IP. Se tienen los protocolos
siguientes:
–RTP (Real-Time Transport Protocol).
Es usado con UDP/IP para identificación de carga
útil, numeración secuencial, monitoreo, etc.
Trabaja junto con RTCP (RT Control Protocol) para
entregar un feedback sobre la calidad de la transmisión de
datos. El encabezado de RTP puede ser comprimido para reducir el
tamaño de archivos en la red.
–RSVP. El protocolo de reservación
de ancho de banda es usado para reservar un ancho de banda
especificado dentro de la red IP. Téngase en cuenta que
RSVP trabaja sobre PPP (o similar a HDLC) pero no trabaja bien
sobre una LAN multiacceso.
–PPP Interleaving se utiliza para enlaces
inferiores a 2 Mb/s para fraccionar los paquetes de gran longitud
y permitir el intercalado con paquetes de servicios en
tiempo-real.
3.3- Procedimiento de
Comunicación H.323.
El procedimiento de funcionamiento de los
protocolos de la suite H.323 se describe con detalle a
continuación. En H.323 se encuentran 3 tipos de mensajes
de señalización diferentes:
–H.245: se describen estos mensajes en
forma de texto
concatenado en letras tipo bold (por ejemplo se menciona el
mensaje: maximumDelayJitter).
–RAS: se representa mediante 3 letras (por
ejemplo ARQ).
-H.225/Q.931: representado en una o dos
palabras con la primer letra en mayúsculas (ejemplo: Call
Proceeding). Es usado para encapsular los mensajes H.245 de
señalización entre terminales y originalmente fue
diseñado como protocolo DSS1 en capa 3/7 para los accesos
ISDN.
3.3.1- Fase de Mantenimiento
de la Registración. Contiene un intercambio de
mensajes para mantener activa la conexión entre los
Gateways GW y el Gatekeeper GK. Ver la Figura 3 para el
intercambio de mensajes de RAS.
1- Discovery. Este primer paso es el
proceso por el cual el GW determina cual es el GK que atiende a
la red en ese momento. El mensaje desde el GW es del tipo
multicast y se denomina GRQ (Gatekeeper Request).
El GK responde con la aceptación GCF (GK
Confirmation) o rechazo GRJ (GK Reject). El GK
puede indicar un GK alternativo mediante mensajes
alternateGatekeeper. Si no se está en condiciones
de procesar el request, se puede enviar un mensaje RIP
(Requst in Progress) para indicar que se está
procesando el request; esto resetea el timeout de la
conexión.
2- Registration. El GW informa de sus
direcciones de transporte y alias mediante RRQ
(Registration Request) y el GK responde con RCF
(Registration Confirmation) o RRJ (Registration
Reject). El RRQ se emite en forma periódica. La
registración tiene un tiempo de duración (expresado
en segundos) para lo cual se utiliza el mensaje
timeToLive. El terminal o el GK puede cancelar la
registración mediante el mensaje URQ (Unregister
Request) al cual le corresponde la confirmación
URF (Unregister Confirmation).
Figura 3. Fase
de mantenimiento de la registración entre GW y
GK.
3- Location. Un GW o GK que tiene un alias
para un GW y quiere determinar su información de contacto,
puede emitir el mensaje de requerimiento de localización
LRQ (Location Request). Al cual le corresponde la
confirmación LCF (Location Confirmation) con
la información requerida. La dirección puede ser
del tipo E.164 si se trata de un GK fuera de la
red.
De existir varios GK se disponen de mensajes para
intercomunicación, por ejemplo, LRQ para Locate
Request y LCF para Locate
Confirm.
4- Status. Se trata de un mensaje periódico
(mayor a 10 segundos) que emite el GK al terminal para determinar
el estado y
requerir un diagnóstico. Se trata de los mensajes
IRQ (Information Request) y IRR
(Information Response). La habilitación se realiza
mediante willRespondToIRR enviado en el mensaje RCF o
ACF.
3.3.1- Fase de Conexión de la
llamada. Representa las distintas etapas para establecer una
llamada.
5- Admission. En la Figura 4, el proceso se
inicia cuando desde la PSTN se recibe un mensaje de Setup para
inicio de una llamada entrante en protocolo ISUP (de la suite de
protocolos de señalización telefónica SS7).
El GW responde a la PSTN mediante el mensaje Call Proceesing,
para mantener la conexión en espera.
El GW requiere iniciar una llamada mediante el
pedido de admisión desde GW al GK. Este mensaje es
ARQ (Admissions Request) y contiene un
requerimiento Call Bandwidth (en formato Q.931). El GK puede
reducir las características de la solicitud en el mensaje
de confirmación ACF (Admissions Confirm). En
el mismo mensaje ARQ se dispone de la funcionalidad
TransportQOS para habilitar la funcionalidad de
reservación de ancho de banda RSVP, para servicios
unidireccionales (orientado-al-receptor).
6a- Setup Modo No-Ruteado. Una vez admitido
el GW-B por el GK el procedimiento se bifurca en el modo ruteado
y no-ruteado. En el modo de operación no-ruteado, el GK
informa al GW-B cual es la dirección IP del GW-A al cual
va dirigida la llamada, de acuerdo con la dirección E.164
recibida en el mensaje ARQ. Ahora, el GW-B se comunica con el
GW-A que fue indicado por el GK y le envía el mensaje
Setup. Este mensaje (en protocolo Q.931) es respondido mediante
el mensaje Call Proceesing.
El GW-A se ocupa de registrarse
mediante ARQ y recibe desde el GK el mensaje ACF. Con estas
acciones cumplidas, el GW-A se ocupa de informar al usuario de la
llamada entrante (corriente de llamada al teléfono) y
hacia el GW-B le envía el mensaje de Alerting en Q.931
para indicar el estado de llamada. El GW-B envía el
mensaje de Alerting a la PSTN, ahora en formato de protocolo
ISUP.
6b- Setup Modo Ruteado. Para el caso de
trabajar con Modo Ruteado, el mensaje de Setup entre GW pasa por
el GK. En el caso No-Ruteado anterior, el GK se desentiende de la
conexión y solo se ocupa de la traslación entre
direcciones E.164 y IP. En el modo ruteado el GK seguirá
toda la conexión, de forma que haciendo uso de las
funcionalidades de Softswitch se podrán ofrecer servicios
de valor agregado.
7- Conect. Cuando el usuario en el GW-A
responde se genera el mensaje Q.931 de Connect. Este mensaje se
emite hacia el GK (Modo Ruteado), quien hace lo mismo hacia el
GW-B y este lo imita hacia la PSTN pero en protocolo ISUP. Ver la
Figura 5.
El paso siguiente es establecer las capacidades de
los terminales utilizando el protocolo H.245 entre GWs. Se trata
del mensaje TerminalCapabilitySet de solicitud y el
TerminalCapabilityAck de respuesta, que permite determinar
capacidad del terminal, tipo de codificador, canal lógico,
etc. Finalmente, se envía el mensaje OpenLogical
Channel para abrir un canal lógico.
8- Canal Vocal. El canal vocal se
transporta sobre los protocolos RTP de la suite IP. Para
más detalles se puede consultar el siguiente ítem
3.4.
Para ver los gráficos seleccione la opción
"Descargar" del menú superior
Figura 4.
Arriba la operación de Conexión mediante el
Modo No-Ruteado y debajo mediante el Modo
Ruteado.
9- Bandwidth. Durante una conexión
el terminal o el GK pueden requerir el cambio de ancho de banda
del canal mediante el mensaje BCR (Bandwidth Change
Request).
3.3.2- Fase de desconexión de la
llamada. En la Figura 5 se indica la fase de
desconexión de la llamada. La misma se realiza con
mensajes Release Complete de Q.931 y DRQ (Delete
Request) y DCF (Delete Confirm) de
RAS.
Sobre el paquete Q.931 (H.225) se disponen de
distintos tipos de mensajes:
-Mensajes para establecimiento de llamada:
Alerting, Call Proceeding, Connect, Setup, Progress,
etc.
-Mensajes para la fase de información de
llamada: Resume, Suspend, User Information,
etc.
-Mensajes para el cierre de la llamada:
Disconnect, Release, Restart, etc.
-Mensajes misceláneos: Segment, Congestion
Control, Information, Notify, Status, Status Enquiry,
etc.
Los mensajes manejados en el ámbito de
H.245 (durante la fase de comunicación telefónica)
son:
–multimediaSystemControl para efectuar el
control del sistema; las variantes del mensaje son request,
response, command and indication.
–otros mensajes de interés
son: masterSlaveDetermination, terminalCapability,
MaintenanceLoop, communication Mode, communicationMode,
conferenceRequest and Response,
terminal-ID.
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 5.
Conexión final de la llamada y desconexión de
la misma en Modo Ruteado.
3.4- Protocolo de transporte
RTP.
El protocolo RTP es utilizado para el transporte
de la señal vocal (tal como se indica en la Figura
5).
3.4.1- Protocolo RTP (Real-Time
Transport Protocol). Tanto el protocolo de transporte en
tiempo-real RTP como el protocolo de control RTCP se encuentran
disponibles en RFC-1889 del año 1996. El protocolo RTP
tiene como objetivo asegurar una calidad de servicio QoS para
servicios del tipo tiempo-real. Incluye: la identificación
del payload, la numeración secuencial, la medición de tiempo y el reporte de la
calidad (función del protocolo RTCP).
Entre sus funciones se encuentran: la
memorización de datos, la simulación
de distribución interactiva, el control y mediciones de
aplicaciones.
El RTP trabaja en capa 4 y sobre
UDP, de forma que posee un checksum para detección de
error y la posibilidad de multiplexación de puertas (port
UDP). Las sesiones de protocolo RTP pueden ser multiplexadas.
Para ello se recurre a un doble direccionamiento mediante las
direcciones IP y el número de port en UDP. Sobre RTP se
disponen de protocolos de aplicación del tipo H.320/323
para vídeo y voz (H.32x forma una familia del ITU-T de
normas para videoconferencia).
El RTP funciona en conjunto con RSVP (capa 3) para
la reservación de ancho de banda y asegurar de esta forma
la QoS del tipo Garantizada. La QoS del tipo Diferenciada se
logra mediante la priorización de tráfico que puede
adoptar dos alternativas. En IP se pueden asignar diversos
alternativas de prioridad para formar una cola de espera en
routers. Un algoritmo particular de gestión de prioridad
de tráfico es el WFQ (Weighted Fair Queuing)
que utiliza un modelo de multiplexación TDM para
distribuir el ancho de banda entre clientes. Cada cliente ocupa
un intervalo de tiempo en un
Round-Robin.
La funcionalidad ToS (Type of
Service) en IP puede determinar un ancho de banda
específico para el cliente. Un servicio sensible al
retardo requiere un ancho de banda superior. En IP además
del ToS se puede utilizar la dirección de origen y destino
IP, tipo de protocolo y número de socket para
asignar una ponderación. En redes que disponen de switch
de capa 2 se requiere extender la gestión de la calidad de
servicio a dicha capa. Para ello la IEEE ha determinado el ToS
sobre IEEE-802.
El RTP además provee transporte para
direcciones unicast y multicast. Por esta razón,
también se encuentra involucrado el protocolo IGMP
para administrar el servicio multicast. El paquete de RTP
incluyen un encabezado fijo y el payload de datos; RTCP utiliza
el encabeza del RTP y ocupa el campo de carga
útil.
Un protocolo conocido como RTP-HC
(Real-Time Protocol – Header Compression) permite la
compresión del encabezado para mejorar la eficiencia del
enlace en paquetes de corta longitud en la carga útil. Se
trata de reducir los 40 Bytes de encabezado en RTP/UDP/IP a una
fracción de 2 a 5 Bytes, eliminando aquellos que se
repiten en todos los paquetes. Como los servicios de tiempo-real
generalmente trabajan con paquetes pequeños y generados en
forma periódica se procede a formar un encabezado de
longitud reducida que mejore la eficiencia de la
red.
3.4.2- Protocolo RTCP (Real-Time Control
Protocol). Este protocolo permite completar a RTP facilitando
la comunicación entre extremos para intercambiar datos y
monitorear de esta forma la calidad de servicio y obtener
información acerca de los participantes en la
sesión. RTCP se fundamenta en la transmisión
periódica de paquetes de control a todos los participantes
en la sesión usando el mismo mecanismo de RTP de
distribución de paquetes de datos. El protocolo UDP
dispone de distintas puertas (UDP Port) como mecanismo de
identificación de protocolos.
La función primordial de RTCP es la de
proveer una realimentación de la calidad de servicio. Se
relaciona con el control de congestión y flujo de datos.
El RTCP involucra varios tipos de mensajes, por
ejemplo:
–Send report para emisión y
recepción de estadísticas (en tiempo random) desde
emisores activos.
–Receiver Report para recepción
estadísticas desde emisores no activos.
–Source Description para un identificador
de nivel de transporte denominado CNAME (Canonical
Name).
–Bye para indicar el final de la
participación en la conexión.
–Application para aplicaciones
específicas.
El mensaje Send Report, uno de los
más interesantes, disponen de 3 secciones bien
diferenciadas:
-Los primeros 8 Bytes se refieren a un encabezado
común.
-La segunda parte de 20 Bytes permite la evaluación
de diferentes parámetros (retardo, jitter, eficiencia de
datos, etc).
-La tercera parte de 24 Bytes lleva reportes que
han sido obtenidos desde el último reporte informado.
Incluye los siguientes reportes: cantidad total de paquetes RTP
perdidos y a la proporción de los mismos; la cantidad de
paquetes recibidos y el jitter entre paquetes; el horario del
último paquete recibido y el retardo de transmisión
del mismo.
4.1- Variante con
Softswitch.
Una evolución más detallada de
las figuras anteriores, donde se muestra solo el
GK, es el Softswitch de la Figura 6. En la versión de
Softswitch disponible en Journal No 4 el
módulo denominado RAS (diseñado en iplan) es
reemplazado aquí por el GK Cisco-7400. El motivo es la
confiabilidad que puede dar al conjunto el GK que está
trabajando desde el 2002 sin inconvenientes. Las funcionalidades
son las mismas y no modifica la topología. El Proxy
denominado GKMPU en el Journal mencionado, se cambia por el
GKTMP. Los módulos CSMU se denomina Q.931 y el
módulo BMU es el módulo de Billing (cambian solo
los nombres).
Para levantar el problema de la
escalabilidad se sugiere utilizar un API (pieza de software) del
IOS de Cisco que se denomina GKTMP (Gatekeeper
Transaction Message Protocol). Este software disponible en el
GK Cisco-7400 se comunica con un server externo que contiene el
mismo protocolo. Se le agrega una Base de Datos
externa y mediante una interfaz Web se puede efectuar la
configuración. El conjunto de server GKTMP, con la base de
datos y la interfaz web para el provisioning se lo conoce como
VSM (VoIP Service Manager) en la Figura
6.
El VSM de iplan, además de resolver
el problema de escalabilidad de los GK 7400, puede proveer
algunos servicios básicos manipulando mensajes, como ser:
Bloqueos; Black and White lists; Presuscripciones a carriers;
Ruteo basado en ANI y DNIS; Manipulación de
Dígitos; Balanceo de carga entre gateways; Anuncios;
Servicios de emergencia y Redes privadas
virtuales.
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 6.
Comunicación H.323 con Softswitch (modo ruteado)
para funciones de Billing.
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 7. Proceso de
comunicación con un softphone H.323 en
Internet.
Desde el punto de vista del proceso de
comunicación se requiere la modalidad ruteada, como ser el
Billing y los desvíos por abonado B ocupado o por B no
contesta. Una estructura de
este tipo es similar al NAM de Cisco, que fuera probado a inicios
del 2002 como alternativa para solucionar los problemas del 0800
en iplan. Este problema fue resuelto definitivamente gracias a la
Plataforma de servicios COSO (ver Journal No
2).
4.2- Softphone en
Internet.
El softphone es un GW de voz H.323 en software que
corre sobre una PC conectada a Internet (más detalles en
Journal No 3). El funcionamiento se muestra en la Figura
7. Se indica el procedimiento para iniciar una llamada y la forma
en que se contabiliza el tiempo de llamada.
Mediante el intercambio de mensajes se procede al
pedido de admisión del terminal al GK mediante ARQ y ACF.
Luego, se pasa al intercambio de mensajes con el GW-E1 de
interconexión hacia la PSTN. Se trata del Setup y ARQ del
este GW-E1. A continuación, el GW-E1 dialoga con el Radius
para solicitar el permiso correspondiente a procesar la llamada
saliente de la red. Radius consulta con la Base de Datos para
conocer el crédito
del cliente y responde al GW-E1 para que este contabilice el
tiempo y corte la llamada cuando se termina el crédito.
Cuando el Softphone se utiliza en un ambiente
prepago se calcula el tiempo que el cliente tiene disponible para
la comunicación. Esta operación se realiza sobre la
base de la información disponible en el server de Data
Base. La operación es similar a la utilizada en la
Plataforma de Servicios Prepagos como en las Calling
Card.
El GW-E1 informa que el usuario llamado se
encuentra en estado de alerta (tono de llamada para el
softphone). Luego, cuando el usuario responde, envía el
mensaje Connect al softphone y realiza la apertura del ticket de
llamada iniciada en el Radius y la Base de Datos. La llamada
continua mediante paquetes en protocolo RTP, transparente a la
Plataforma de Softphone y el GK.
Cuando la llamada termina, el GW-E1 pide el cierre
del ticket de llamada en curso y abre el ticket de llamada
completada. Se genera entonces un CDR correspondiente a la
llamada con el tiempo total de la misma.
4.3- Gateway
IP-IP.
El GW IP-IP trabaja en dos dominios IP, donde cada
uno tiene su propio GK y se lo utiliza para unir un dominio privado
de uno público o dos privados. La Figura 8 muestra una
secuencia típica de mensajes de señalización
para una llamada a través del GW IP-IP registrado en dos
GK. Se trata de una secuencia fácilmente interpretable
como resumen de la Figuras anteriores de este Journal. Una
descripción más detallada puede encontrarse en el
Journal No 6.
5.1- Protocolo
MGCP.
Otros protocolos
competidores con H.323 son MGCP (Media Gateway Control Protocol)
y SIP (Session Initiation Protocol). El MGCP es un protocolo que
soporta un control de señalización de llamada
escalable. El control de
calidad de servicio QoS se integra en el gateway GW o en el
controlador de llamadas MGC. Este protocolo tiene su origen en el
SGCP (de Cisco y Bellcore) e IPDC. Bellcore y Level3 plantearon
el MGCP a varios organismos.
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 8.
Proceso de comunicación entre dominios con el GW
IP-IP.
El protocolo SIP se aplica
para sesiones punto-a-punto unicast. Puede ser usado para enviar
una invitación a participar en una conferencia multicast.
Utiliza el modelo cliente-servidor y se
adapta para las aplicaciones de Telefonía-IP. El server
puede actuar en modo proxy o redirect (se direcciona el
requerimiento de llamada a un server
apropiado).
El MGCP es un protocolo que permite
comunicar al controlador de gateway MGC (también conocido
como Call Agent) con las gateway GW de telefonía
(hacia la PABX o PSTN). La primera versión 1.0 es de
octubre-1999 (RFC-2705). Se trata de un protocolo de tipo
master-slave donde el MGC informa las acciones a seguir al GW.
Los mensajes MGCP viajan sobre UDP/IP, por la misma red de
transporte IP con seguridad IPsec.
El formato de trabajo genera
una inteligencia
externa a la red (concentrada en el MGC) y donde la red de
conmutación está formada por los router de la red
IP. El GW solo realiza funciones de conversión vocal
(analógica o de velocidad digital) y genera un camino RTP
entre extremos. La sesión de MGCP puede ser punto-a-punto
o multipunto. El protocolo MGCP entrega al GW la dirección
IP, el port de UDP y los perfiles de
RPT.
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 9.
Proceso de comunicación con protocolo
MGCP.
En la Figura 9 se muestra el intercambio de
mensajes en el establecimiento de una comunicación con
protocolo MGCP. Los mensajes o comandos disponibles en MGCP son
los siguientes:
Comando NotificationsRequest. Este
primer mensaje se genera ante el requerimiento de conexión
de un teléfono. El GW-A indica al MGC el requerimiento del
usuario A. Como respuesta se recibe un
Ack-NotificationRequest. El mismo comando transfiere los
dígitos discados cuando el usuario termina la
marcación correspondiente.
Mensaje CreateConnection,. Es
utilizado para crear una conexión que se inicia en el GW.
Se envía a ambos GW y se recibe el comando de
confirmación Ack-CreateConnection. El comando
ModifyConnection, puede ser usado para cambiar los
parámetros de la conexión existente. El comando
DeleteConnection es usado en cambio para cancelar la
conexión existente al final de la llamada. Otro comando,
AuditConnection, es usado para requerir el estado de la
conexión.
Con ambos extremos conectados, se entrega la
señal de llamada al extremo del GW-B y finalmente se
establece la conexión entre
extremos.
Comando DeleteConnection. Utilizado
para el cierre de la llamada. Como respuesta el GW envía
una serie de informaciones obtenidas desde el protocolo RTP
número de paquetes y de Bytes emitidos; número de
paquetes y Bytes recibidos; número de paquetes perdidos;
jitter promedio en mseg, retardo de la transmisión,
etc.
Comando AuditEndpoint. Es usado para
requerir el estado del extremo al GW. Los comandos
AuditEndpoint y AuditConnection permiten obtener
información que posteriormente forman parte de la MIB y
pueden consultadas mediante el protocolo SNMP por el sistema de
Management. Por ejemplo, se obtienen los siguientes mensajes de
respuesta: RequestedEvents, DigitMap, SignalRequests,
RequestIdentifier, NotifiedEntity, ConnectionIdentifiers,
DetectEvents, ObservedEvents, EventStates, Restart-Reason,
RestartDelay, ReasonCode, and
Capabilities.
Existen otros comandos de interés.
Por ejemplo, RestartInProgress es usado por el GW para
notificar que un grupo de
conexiones se encuentran en falla o reinicio. El
EndpointConfiguration es usado para indicar al GW las
características de codificación esperadas en el
extremo final.
5.2- Protocolo
SIP.
El IETF ha generado un set de protocolos que
simplifican las funciones de H.323, el cual tiene previstas
funciones dentro de una red corporativa y en multimedia. SIP es
un protocolo más simple que H.323 y está basado en
HTTP. En H.323
se utiliza el GK, mientras que en SIP se usa el SIP-Server, el
cual tiene mejores aspectos de escalabilidad para grandes redes.
En H.323 para grandes redes se recurre a definir zonas de
influencia y colocar varios GK. Para la interoperatividad de
protocolos se requiere un GW de borde que realice la
conversión.
SIP es un protocolo basado en texto (de
acuerdo con RFC-2279 para la codificación del set de
caracteres) y el mensaje basado en http (RFC-2068 para la
semántica y sintaxis). La dirección
usada en SIP se basa en un localizador URL (Uniform
Resource Locater) con un formato del tipo
sip:roberto@192.190.132.31 (o mediante el dominio Domain:
teleinfo.com.ar). De esta forma SIP integra su servicio a la
Internet. En este modelo se requiere el auxilio de un server de
resolución de dominio DNS (Domain Name
Server).
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 10.
Intercambio de mensajes para establecer una
comunicación con protocolo SIP.
El protocolo SIP incorpora también
funciones de seguridad y autentificación, así como
la descripción del medio mediante el protocolo SDP. Para
el proceso de facturación billing se puede recurrir
a un server RADIUS.
Las fases de comunicación soportadas
en una conexión unicast mediante el protocolo SIP, son las
siguientes:
–User location. En esta fase
se determina el sistema terminal para la
comunicación.
–User capabilities: Permite
determinar los parámetros del medio a ser
usados.
-User availability: Para determinar
la disponibilidad del llamado para la
comunicación.
–Call setup: ("ringing"); Para el
establecimiento de la llamada entre ambos
extremos.
–Call handling: Incluye la
transferencia y terminación de la
llamada.
El protocolo SIP tiene dos tipos de
mensajes: Request y Response. El mensaje de Request
es emitido desde el cliente terminal al server terminal. El
encabezado del mensaje request y response contiene campos
similares:
–Start Line. Usada para
indicar el tipo de paquete, la dirección y la
versión de SIP.
–General Header. Contiene el
Call-ID (se genera en cada llamada para identificar la
misma); Cseq (se inicia en un número aleatorio e
identifica en forma secuencial a cada request); From (es
la dirección del origen de la llamada); To (es la
dirección del destino de la llamada); Via (sirve
para recordar la ruta del request; por ello cada proxy en la ruta
añade una línea de vía) y Encryption
(identifica un mensaje que ha sido encriptado para
seguridad).
–Additionals.
Además del encabezado general se pueden transportar campos
adicionales. Por ejemplo: Expire indica el tiempo de
valides de registración; Priority indica la
prioridad del mensaje; etc.
Se han definido 6 métodos
para los mensajes de request-response.
-Invite. para invitar al
usuario a realizar una conexión. Localiza e identifica al
usuario.
–Bye. para la terminación de
una llamada entre usuarios.
–Options. información de
capacidades que pueden ser configuradas entre agentes o mediante
un server SIP.
–ACK. usado para reconocer que el
mensaje Invite puede ser aceptado.
–Cancel. termina una búsqueda
de un usuario.
–Register. emitido en un mensaje
multicast para localizar al server SIP.
6- OTROS
PROTOCOLO DE SEÑALIZACION
6.1-
Clasificación de los
protocolos.
Por
señalización se entiende el conjunto de
informaciones intercambiadas entre dos puntos de la red
telefónica que permiten efectuar operaciones
de:
–Supervisión (detección de
condición o cambio de
estado).
-Direccionamiento (establecimiento de
llamada).
-Explotación (gestión y
mantenimiento de la red).
El ITU-T se ocupó de recomendar
los sistemas de señalización a fin de ser usados en
las comunicaciones
internacionales. El primer sistema fue el SS1, que se
inició en 1934. Es monofrecuente con un valor de 500 o
1000 Hz interrumpida con una cadencia de 20 Hz para la selección
de llamada. Se lo utilizó para algunos servicios manuales
bidireccionales. Desde el SS1 hasta el SS5 son sistemas de
señalización analógicos. El SS6 fue
diseñado para USA y el SS7 por el ITU-T para
Interconexión en forma
global.
Cuando se inició la
señalización en multifrecuencia se
distinguió entre los procedimientos de
código
de impulsos como el SS5 y los de señales obligadas como el
MFC-R2. En el primer caso la señal tiene un período
de duración fijo y determinado, mientras que en el segundo
a cada paso de mensaje se espera la respuesta de
confirmación por el canal de retorno para cortar la
señal de ida. Esto implica que la
señalización por secuencia obligada requiere de
mayor tiempo y una duración no
determinada.
La señalización por corriente
continua se realiza mediante los Hilos E&M
(Exchange & Múltiplex). Se denomina hilo M al
hilo de transmisión (salida de central) y E al hilo de
recepción (entrada a central). Las señales se
representan aplicando y desconectando potenciales o mediante la
apertura y cierre de un bucle. La tensión es la que
alimenta la central (-48 V). Se dispone de los estados P1 (-48 V
sobre hilo a) y P2 (-48 V sobre hilo b).
La señalización puede ser del
tipo de señales de impulsos o por niveles indicativos de
estados; mientras el primero permite un plan complejo de
señalización el segundo garantiza una
supervisión sencilla de la línea.
Prácticamente, este método
solo se usa en líneas bifilares y se pueden distinguir dos
tipos: el procedimiento de señalización en bucle
(mientras un extremo maneja los potenciales el otro lo hace con
el bucle cerrado o abierto) y la señalización por
un solo hilo (potencial positivo o negativo en cada
sentido).
La señalización multifrecuente
se trata de una codificación que transmite un juego de 2
entre 6 frecuencias, dentro de la banda del canal
telefónico en ambos sentidos: hacia adelante (1380, 1500,
1620, 1740, 1860, 1980 Hz) y hacia atrás (1140, 1020, 900,
780, 660, 540 Hz). Su denominación es DTMF (Dual
Tone MultiFrequecy).
En el sistema de
multiplexación de 30 canales a 2048 kb/s (tramas E1) se
recurre a un concepto mediante el MFC-R2 digital del año
1968. El Intervalo de Tiempo TS:16 de la trama se usa
exclusivamente para información de
señalización de los 30 canales
vocales.
Ambos sistemas de señalización
digital (MFC-R1 y R2) se usan en la actualidad, el primero en USA
y el segundo en Europa y Latinoamérica. Cuando los sistemas de
conmutación son manejados por procesadores se
requiere un concepto distinto al mencionado. Hasta ahora se puede
decir que se tiene una correspondencia entre el canal vocal y el
de señalización; a este método de lo llama
Señalización por Canal Asociado
CAS.
Cuando se trabaja con procesadores la
señalización se transforma totalmente
traduciéndose en un diálogo
entre extremos. No se distingue una correspondencia entre el
canal vocal y el canal de señalización; es
más, la vía de transmisión puede ser
distinta. Así, el canal de señalización pasa
a ser un canal de datos dentro de una red de
señalización.
Figura 11.
Protocolos involucrados en una red
telefónica.
Este tipo de señalización se
denomina Señalización por Canal Común
CCS (La nomenclatura SS7 corresponde al ITU-T y CCS7 a
ANSI). Las principales características que identifican a
la señalización CCS frente a CAS
son:
-Tiempo de conexión
menor.
-Número de mensajes
prácticamente ilimitados.
-Flexibilidad para nuevos
servicios.
-Encaminamiento
alternativo.
-Corrección de errores mediante
retransmisión de tramas.
-La capa 2 utiliza un protocolo de
corrección de error ARQ tipo
go-back-N.
-La capa 3 está prevista para
mensajes en tiempo real de la red telefónica y es del tipo
orientado sin-conexión.
6.2- Sistema de
Señalización SS7.
El SS7 es el sistema de
señalización utilizado en la red PSTN y corresponde
a la interconexión de la red de Telefonía-IP en
iplan con la PSTN. En iplan existen dos componentes que manejan
la SS7: la central de conmutación NEC y el Controlador de
Señalización SC2200 para la red
Telefonía-IP.
Para ver el gráfico
seleccione la opción "Descargar" del menú
superior
Figura 12.
Intercambio de mensajes en el protocolo de
señalización SS7.
Los principales protocolos de la suite SS7,
son:
–MTP-2. Corresponde a la capa 2 del
modelo OSI de 7
capas. Se ocupa del alineamiento de paquete mediante banderas
(Flag) al inicio y final. Permite la detección de
errores mediante un código denominado CRC-16. Realiza el
proceso de numeración secuencial de mensajes e
indicación de retransmisión. Efectúa la
confirmación o rechazo del mensaje para la
retransmisión automática en mensajes con errores.
Los paquetes son numerados en forma secuencial con
módulo-7. Indica también a longitud total del
mensaje transmitido. Con la numeración de paquetes y la
detección de errores, es posible la retransmisión
de mensajes que se ven afectados por
errores.
-MTP-3. Posee una dirección de
punto de acceso que permite identificar a la capa superior (TCAP
o ISUP sobre el protocolo MTP3). En la red PSTN se dispone de las
direcciones de procesador CPU de origen
y destino (14 bits de dirección). Por otro lado,
identifica el enlace de señalización utilizado
cuando existe más de uno. Realiza las funciones de Routing
dentro de la red de señalización
SS7.
–ISUP. Son los mensajes de
señalización propiamente dichos. En la Figura 12 se
muestra el intercambio de mensajes para la apertura y cierre de
una llamada telefónica. Desde el usuario a la central se
utiliza señalización MFC-R2 o DTMF. Los mensajes
típicos de ISUP entre centrales
son:
-IAM (Initial Address
Message). Contiene la información inicial de llamada
para el encaminamiento. Son los primeros dígitos
seleccionados por el usuario.
-SAM (Subsequent Address
Message). Transporta las cifras no enviadas en el mensaje
IAM. Se completa el número del usuario B
llamado.
-ACM (Address Complete
Message). Indica que se ha obtenido en acceso al destino.
SE entrega al usuario A el tono de
llamada.
-ANM (Answer Message).
Indica que el usuario llamado ha respondido. Se cierra el
circuito vocal.
-BLO (Blocking Message).
Permite el bloqueo del canal
útil.
-UBL (Unblocking Message).
Desbloquea el canal útil.
-REL (Release Message).
Permite iniciar la liberación del canal. La
comunicación se cierra.
-RLC (Release Complete
Message). Informa que la liberación ha sido
completada.
-TCAP. Facilita la transferencia de
mensajes en tiempo real entre HLR (Home Location
Register), VLR (Visitor LR), MSC (Mobile Switching
Center), EIR (Equipment ID Register),. Se aplica
también para enlaces con O&M. En tarjetas de
crédito permite verificar la autenticidad y movimientos de
cuenta. Realiza el control de diálogo con el terminal
remoto. Es un servicio de transporte.
La información contiene los
siguientes componentes:
-tipo de mensaje (unidireccional, inicio,
final, intermedio, aborto);
-longitud del mensaje (número de
bytes total);
-identificador de origen y destino de
transacción;
-tipo de componente (retorno de resultado,
reporte de error y de reject) y
-contenido de información
(código de operación, de error, de problema,
parámetros, etc).
Roberto Ares