Monografias.com > Computación > Redes
Descargar Imprimir Comentar Ver trabajos relacionados

Telefonía-IP




Enviado por rares



    Protocolos de
    señalización

    1. Abstract
    2. Componentes y
      Protocolos
    3. La suite
      H.323
    4. Variantes en
      H.323
    5. Protocolos MGCP y
      SIP
    6. Otros protocolos de
      señalización

    Abstract

    La TelefoníaIP 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- COMPONENTES Y
    PROTOCOLOS

    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- SUITE
    H.323

    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- VARIANTES
    EN H.323

    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-
    PROTOCOLOS MGCP Y SIP

    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

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter