Protocolos Mgcp, Megaco, Iax, Sccp

Los sistemas de señalización para el transporte de voz han evolucionado desde las redes basadas en conmutación de circuitos a redes basadas en conmutación de paquetes. Diferentes estándares han aparecido para tratar de solventar problemas de direccionamiento, control de admisión, interconexión con redes existentes, intercambio de capacidades, etc. El objetivo del protocolo de VoIP es dividir en paquetes los flujos de audio para transportarlos sobre redes basadas en IP. Los protocolos de las redes IP originalmente no fueron diseñados para el fluido el tiempo real de audio o cualquier otro tipo de medio de comunicación. La PSTN está diseñada para la transmisión de voz, sin embargo tiene sus limitaciones tecnológicas. Es por lo anterior que se crean los protocolos para VoIP, cuyo mecanismo de conexión abarca una serie de transacciones de señalización entre terminales que cargan dos flujos de audio para cada dirección de la conversación.

 Acrónimo de “Media Gateway Contro l Protocol”. Inicialm ente diseñado para simplificar en lo posible la comunicación con terminales como los teléfonos. MGCP utiliza un modelo centralizado (arquitectura cliente * servidor), de tal forma que un teléfono necesita conectarse a un controlador antes de conectarse con otro teléfono, así la comunicación no es directa. Tiene tres componentes un MGC (Media Gateway Controller, también llamado Call Agent), uno o varios MG (Media Gateway) y uno o varios SG (Signaling Gateway), el primero también denominado dispositivo maestro controla al segundo también denominado esclavo. No es un protocolo estándar. MGCP (Media Gateway Control Protocol) tiene su origen en el SGCP (de Cisco y Bellcore), e IPDC. MGCP soporta un control de señalización de llamada escalable, integrando el control de QoS (Quality of  Service, Calidad de Servicio) en el gateway. Su compatibilidad con normas de IETF y con H.323 lo hace ideal para aplicaciones de multimedia sobre redes IP. Este protocolo presenta una arquitectura de control de llamada donde la inteligencia está fuera de las gateways y es manejada por elementos de control de llamada externos, conocidos como Agentes de Llamada. El protocolo MGCP presupone que estos elementos del control de llamada, o Agentes de Llamada, se sincronizan entre sí para enviar órdenes coherentes y respuesta a las gateways. MGCP está definido informalmente en la RFC 3435, y aunque no ostenta el rango de estándar, su sucesor, Megaco está aceptado y definido como una recomendación en la RFC 3015. Un gateway tradicional, cumple con la función de ofrecer conectividad y traducción entre dos redes diferentes e incompatibles como lo son las de Conmutación de Paquetes y las de Conmutación de Circuitos. En esta función, el gateway realiza la conversión del flujo de datos, y además realiza también la conversión de la señalización, bidireccionalmente. MGCP separa conceptualmente estas funciones en los tres elementos previamente señalados. Así, la conversión del contenido multimedia es realizada por el MG, el control de la señalización del lado IP es realizada por el MGC, y el control de la señalización del lado de la red de Conmutación de Circuitos es realizada por el SG. MGCP introduce esta división en los roles con la intención de aliviar a la entidad encargada de transformar el audio para ambos lados, de las tareas de señalización, concentrando en el MGC el procesamiento de la señalización. El control de calidad de servicio QoS se integra en el gateway GW o en el controlador de llamadas MGC.

Un gateway de telefonía es un elemento de red que provee conversión entre las señales de audio transportadas sobre los circuitos telefónicos y los paquetes de datos transportados sobre el internet o sobre otra red de paquetes. MGCP asume una arquitectura de control de llamada, donde la inteligencia del control de la llamada está fuera de los gateways y manejada por un elemento de control de llamada externo. El MGCP asume que estos elementos de control de llamadas o MGC, se sincronizarán entre sí para enviar comandos coherentemente a los gateways que están bajo su control.

Lo que se propuso con MGCP fue sacar el control de la señalización del propio gateway (GW), llevándolo a otro elemento, el ‘media gateway controller’ MGC (que se conoce como ‘softswitch’) que se encargará

del control de los media gateways (MGW). En MGCP se puede decir que se ha separado la "inteligencia" (las funciones de control) de los datos (los contenidos: ‘the media’). Que se trata de un protocolo Maestro/Esclavo. El maestro es el MGC (‘softswitch’ o ‘call agent’) y e l esclavo es el MGW (que puede ser un GW de VoIP, un DSLAM, un

router MPLS, un teléfono IP,...). Esta es precisamente la característica que más choca con la filosofía

(P2P) de SIP. Otra característica interesante es que intenta reproducir el modelo de la PSTN/IN sobre IP (en la Figura se ilustra el escenario típico para un despliegue tipo ‘I nternet Telephony’ que es la aplicación para la que se pensó, al menos en principio esta solución), en contra del modelo distribuido que propone SIP. Controlador de Medios (Media Gateway Controller –MGC-), que proporciona la señalización H.323 o SIP y realiza el mapping entre la señalización de redes tradicionales y las redes de paquetes. Pasarela de Medios (Media Gateway –MC-), que proporciona la adaptación de medios y/o las funciones de transcodificación. Este bloque realiza las funciones de traslación de direcciones, cancelación de eco, envío/recepción de dígitos DMTF, etc. Lo que se propuso con MGCP fue pasar el control de señalización del Gateway al MGC o softswicht, que se encargará del control de los Medias Gateways. Logrando así, a nivel de sistema, desagregar al gatekeeper en sus equivalentes en el mundo SS7. El Softswitch es el principal dispositivo en la capa de control dentro de una arquitectura NGN (Next Generation Network), encargado de proporcionar el control de llamada (señalización y gestión de servicios), procesamiento de llamadas, y otros servicios, sobre una red de conmutación de paquetes (IP). El softswitch actúa como gestor en el momento de interconectar las redes de telefonía tradicional, e incluso las redes inalámbricas 3G con las redes de conmutación de paquetes(IP), buscando como objetivo final lograr la confiabilidad y calidad de servicio similar a la que brinda una red de conmutación de circuitos con un menor precio. Como todas las recientes tecnologías desarrolladas en telecomunicaciones, el softswitch busca la utilización de estándares abiertos para lograr la integración de las redes de próxima generación con la capacidad de transportar voz (Voz sobre IP), datos y multimedia, sobre redes IP. Pudiendo así, considerar al softswitch como una eficiente plataforma de integración para el intercambio de servicios y aplicaciones. Desde el punto de vista de VoIP, se suele considerar al softswitch como el Proxy o elemento de registro en el protocolo SIP o como el Gatekeeper en H.323. También se lo puede asociar cuando se habla de un MGC (Media Gateway Controller) en MGCP y MEGACO.

Diagrama de cisco MGC

Diagrama de descomposición del Gateway e interacción con la PSTN

Diagrama General de un sistema MGCP

Megaco o H.248 (nombre dado por la ITU, Media Gateway Control Protocol) define el mecanismo necesario de llamada para permitir a un controlador Media Gateway el control de puertas de enlace para soporte de llamadas de voz/fax entre redes RTC-IP o IP-IP. Este protocolo está definido por la IETF RFC 3525 y es el resultado del trabajo realizado por la IETF y la ITU.  Antes de la cooperación entre ITU e IETF, existían diversos protocolos que cumplían est as funciones; entre ellos se encontraban MDCP y MGCP. H.248 es un complemento a los protocolos H.323 y SIP: se utilizará el H.248 para controlar las Media Gateways y el H.323 o SIP para comunicarse con otro controlador Media Gateway. El protocolo MEGACO permite a estas dos entidades (MGC y MGW) intercambiar transacciones. Cada transacción se expresa por el envío de una transactionRequest por una de las entidades y el envío de una transactionReply por la otra entidad. Una transactionRequest está formada por un conjunto de instrucciones, y una transactionReply contiene el conjunto de respuestas correspondientes. El modelo de conexión del protocolo MEGACO es un modelo orientado a objeto. Describe las entidades lógicas u objetos en el seno del MGW que pueden ser controlados por el MGC. Las principales abstracciones utilizadas en este modelo de conexión son las terminaciones (termination) y los contextos (context). El protocolo MEGACO permite el establecimiento de llamadas multipartes a diferencia del protocolo MGCP, que sólo permite las llamadas entre dos partes. Una terminación MEGACO comienza o termina uno o varios flujos. Una terminación está descrita por un conjunto de propiedades reagrupadas en un conjunto de descriptores incluidos en las instrucciones. Una terminación tiene una identidad única (TermiantionId) otorgada en el momento de su creación por el MGW. Ciertas terminaciones que representan entidades físicas son semi-permanentes. Un circuito de voz ligado a un MGW es un ejemplo de terminación semi-permanente. Otras terminaciones representan flujos temporales tales como los flujos RTP que sólo existen durante el transcurso de la llamada correspondiente. Se trata de terminaciones temporales. Diagrama general de un sistema MEGACO

Acrónimo de “Inter Asterisk eXchange”, es un protocolo abierto, que se puede descargar y desarrollar libremente. Realmente IAX se refiere a IAX2, la segunda versión de este protocolo, dado que el primero fue reemplazado por este. No es considerado como un protocolo estándar. Es un protocolo de transporte, que utiliza el puerto UDP 4569 tanto para señalización de canal como para RTP (Protocolo de Transporte en tiempo Real). Puede truncar o empaquetar múltiples sesiones dentro de un flujo de datos, así  requiere de menos ancho de banda y permite mayor número de canales entre terminales. En seguridad, permite la autenticación, pero no hay cifrado entre terminales. Según la documentación (Asterisk 1.4) el IAX puede usar cifrado (aes128), siempre sobre canales con autentificación MD5. El protocolo IAX fue diseñado para Asterisk por su mismo creador Mark Spencer (de ahí recibe sus siglas, Inter Asterisk eXchange, Intercambio entre Asterisk) para suplir múltiples desventajas que el protocolo SIP ofrecía en aquel momento, y que por su naturaleza original, sigue teniendo. IAX2 está descrito en profundidad en el RFC 5456. En términos generales, IAX es el mejor protocolo de señalización y transporte utilizado entre cualquier máquina Asterisk, y a ser posible entre cualquier dispositivo que tenga algo que ver con una máquina que disponga de nuestro sistema. IAX fue diseñado pero hasta 2010 no apareció su implementación en el RFC que comentábamos al principio. Funcionamiento del IAX

En este sentido, a nivel de señalización IAX es muy similar a la mayoría de los protocolos de señalización no específicos y utilizados para la telefonía IP como los comentados anteriormente. A nivel OSI, puede trabajar tanto con puertos de carácter TCP como UDP, concretamente y por defecto suele trabajar con el 4569. Los mensajes se pasan entre dispositivos en formato Binario, al contrario de otros protocolos más comunes que pueden pasar estos mensajes en formato de texto plano, tampoco supone un hito en la seguridad, pero al menos ya no son tan evidentes. IAX tiene dos mecanismos de transportar la información. División en paquetes para cada tramo del medio, incorporando una cabecera por cada paquete, o una característica especial, utilizando sus funciones específicas de "trunking", llevando todos los medios, en un solo paquete con una sola cabecera. Haciendo un análisis de esta funcionalidad, se puede observar como el tiempo de respuesta baja, pero a cambio es necesario que el ancho de banda sea amplio para poder soportar el aumento en tamaño de los paquetes. Si trabajamos con conexiones con muy poco ancho de banda, sería recomendable no utilizar esta capacidad de "trunking". Hay que entender, que este protocolo originalmente, fue diseñado para conectar dos m áquinas Asterisk entre sí, de la forma más eficiente, segura y fácil de implementar en cualquier escenario posible. Hoy en día existen muy pocas implementaciones y dispositivos que soporten este protocolo, pero ciertos proveedores, y diseñadores de equipos, cada vez más empiezan a incorporar sus desarrollos basados en este protocolo. Hasta cierta medida, podrían considerarse los dispositivos "propietarios" de Asterisk, con la diferencia, que este protocolo puede ser implementado por cualquier PBX del mundo sin coste alguno, ya que es de libre disposición y acceso.

Mensajes más comunes con los que trabaja este protocolo son: NEW, ACCEPT, ACK, RINGING, ANSWER, MEDIA, HANGUP, CALLTOKEN, AUTHREQ. Ventajas del IAX La principal ventaja de IAX es que tanto la señalización como los medios para comunicarse entre dos puntos, son multiplexados a través del mismo puerto, gracias a estas bondades, IAX si podría considerarse, al contrario de SIP en un verdadero protocolo de telefonía IP (VoIP, voz sobre IP), dado que fue diseñado originalmente para cumplir esta función. Otra de las ventajas, es que al solo necesitar una cabecera para la señalización que cubre todos los medios, podemos reducir considerablemente el tamaño de los paquetes, y en consecuencia, la latencia (tiempo de respuesta), quedaría reducida proporcionalmente. No debemos olvidar, que uno de los grandes problemas de protocolos como SIP y MGCP, es que al ser protocolos puros de señalización, los medios van a través de otro protocolo independiente, RTP (Protocolo de transporte en tiempo real), esto significa, problemas sobre todo con los NAT (Network Address Translation - Traducción de Dirección de Red), y muy específicamente, enormes con los NAT simétricos en los que hay que recurrir a soluciones, que ni siquiera hasta la fecha, están 100% implementadas en nuestros sistemas Asterisk. Por ello, con la utilización de IAX, saltamos estos

problemas ya que al ir todo a través del mismo canal, y por el m ismo puerto, es fácilmente acotable y parametrizable en nuestros NAT, y Cortafuegos. Por último y no la menos importante, la capacidad de incorporar características de seguridad como mejoras desarrolladas para protocolo específicamente en el sistema Asterisk. No es necesaria la instalación de añadidos, ni módulos específicos para conseguir este propósito. Todo a través del fichero de configuración específico de IAX y casi recomendable prescribirlo por regla general. Soporta autenticación de tipo PKI (Public-Key Infraestructure) con claves RSA (Sistema criptográfico de clave pública) bastante apropiadas si tratamos de comunicaciones probablemente sometidas a eventuales accesos indebidos. Problemas de IAX Principalmente existen dos problemas conocidos derivados del protocolo IAX2. Por un lado, hay que considerar que las primeras versiones de IAX, eran algo inseguras, y estaban excesivamente expuestas a los ataques de denegación del servicio (Distribute Denial of Service). Por ello las medidas más clásicamente utilizadas para mitigar este problema, era simplemente, limitar el número de llamadas máximo por cada host que conectase vía IAX a nuestra máquina. Por otro lado, con las versiones más recientes de IAX2, surgió la idea de utilizar un Token de autentificación para garantizar un paso menos en la posibilidad de ver sufrir nuestra máquina ataques DDoS por máquinas sin autentificar. En el caso de requerir por cualquier motivo, el acceso a visitantes (guest) sin autentificar, nuestra máquina quedaría bastante expuesta, pero las últimas revisiones del protocolo protegen aún más ante este problema. En términos generales podemos decir que ha existido demasiada fragmentación de este protocolo surgida a raíz de las diversas actualizaciones del mismo. Pero eventualmente si trabajamos con máquinas de la misma índole (principalmente hablando de máquinas Asterisk, con similares, versiones, etc.), la seguridad en este sentido está bastante más garantizada que con otros protocolos como SIP, donde los ataques DDoS, por ejemplo, con envíos masivos de mensajes INVITE, suelen ser más comunes. El segundo problema, surge a raíz de la extensibilidad del protocolo. Este tema está más que discutido, ya que al ser un protocolo libre, es relativamente accesible su modificación. Parámetros de configuración Muy parecido al protocolo SIP que suele servir de referencia a la hora de configurar el protocolo IAX, muchos de los parámetros de configuración general son compartidos. Si sabemos configurar el fichero de configuración del otro protocolo, no tendremos mucha dificultad para configurar este. Hay que considerar que el fichero de configuración especifico esta contenido por regla general en el directorio /etc/asterisk/ y concretamente se trata del iax.conf. Configuración General Dentro del contexto general podemos utilizar los siguientes argumentos comunes: 

bindport: Aquí podemos especificar el puerto especifico al que escuchara nuestra máquina Asterisk para conexiones IAX (puerto UDP), por defecto el 4569.











srvlookup: Existe una cuestión que trataremos a continuación acerca del "emparejamiento" de cabeceras IAX con nuestros correspondientes pares dentro del fichero de configuración. En el caso que queramos (intentar) este emparejamiento, utilizando los nombres de host en vez de las direcciones IP, sería conveniente activar este parámetro (srvlookup = yes). Pero al depender de "terceros" (búsqueda por DNS SRV), resulta un tanto aleatoria la posibilidad que este parámetro llego a aportar algo verdaderamente de valor) allow/disallow: Esta opción es aplicable tanto a los pares como a modo general. Serían los permisos para poder utilizar todos o determinados codecs. Por defecto se permiten todos y no se restringe ninguno (allow = all), por eso para permitir solo determinados codecs es fundamental primero, "prohibirlos" todos con la opción "disallow = all". Podemos encontrar más información sobre codecs rtcachefriends: Si trabajamos con Asterisk Realtime para configurar IAX (tabla iaxpeers) sería un método de cachear a los pares, para no tener que estar haciendo consultas SQL constantemente. context: El contexto por defecto al que enviaremos las llamadas dentro del Plan de Marcación. En este caso es default, y sería conveniente o definirlo en el fichero de configuración del Plan de Marcación para evitar sorpresas, o cambiarlo a un contexto ya definido y que tengamos controlado. language: El lenguaje utilizado por defecto en el caso que utilicemos Aplicaciones para reproducir un mensaje de audio.

Los específicos: 



encryption: Permite encriptar la información trasmitida a través del protocolo IAX. Muy útil como medida de seguridad para el sistema. transfer: Ofrece la posibilidad de intercomunicar dos dispositivos IAX sin pasar por la máquina Asterisk

Adicionalmente algunos parámetros específicos para el sistema de Trunking: 











trunk: Decidimos si vamos a utilizar esta funcionalidad o no (Yes o No) trunkmaxsize: Con esto podemos decidir que los paquetes tengan un límite de tamaño y así poder ajustar este sistema a nuestro ancho de banda, evitando el problema que surgía por saturarlo y ser más ineficiente. trunkmtu: Controlamos la Unidad Máxima de Transferencia de cada unidad de datos enviado a través de nuestra red. trunkfreq: Podemos ajustar en milisegundos, la frecuencia de envío de paquetes. Ya son parámetros para un ajuste muy a medida de nuestra red y hay que tener cuidado al elegirlos dado que podríamos colapsar las comunicaciones. trunktimestamps: Podemos mandar Marcas de Tiempo por cada trunk, y con ello habilitamos otra opción de IAX jitterbuffer  jitterbuffer: Creamos un Buffer para mejorar el Jitter de la conversación. En el caso que los dos pares utilicen la funcionalidad de trunking, es fundamental que la opción trunktimestamps este habilitada en ambos sentidos.

Todos los parámetros de seguridad relacionados a los "Call Token" y la concurrencia en llamadas, la debilidad del Protocolo IAX, podemos verlos en el apartado de Seguridad

Configuración Específica de los Pares Volvemos a tener varios parámetros "compartidos" entre SIP e IAX, aparte algunos específicos como los que mencionamos a continuación: 























allow/disallow: Mismo uso que en el caso general, pero específicamente para un par en concreto. Podemos encontrar más información sobre codecs callerid: Sirve para que nuestro destinatario vea un "Identificador" de llamada especifico cuando llamemos desde este dispositivo context: Mismo uso que el caso general, específico para el dispositivo en cuestión. host: Aqui especificamos la dirección a la que nos conectamos si es un peer, en caso de ser un friend/user, podríamos especificar la opción "dynamic" y dejar abierta la posibilidad que cualquier dispositivo se conecte a nuestra máquina sin una IP en concreto. permit/deny: Más opciones de seguridad, sirve para restringir las redes y máscaras de subred de las cuales dispositivos en las mismas puedan conectar a nuestra máquina. Un ejemplo podria ser permit = 192.168.1.0/255.255.255.0 permitiría solo conexiones de dispositivos entrantes cuya IP pertenezca a esta subred. Amplio en Seguridad. mailbox: Si deseamos asociar un Buzón de Voz a un par concreto lo haremos a través de este parámetro. Por ejemplo 100@ventas asociaría el buzón numero 100 dentro del contexto ventas (esto es aplicable al fichero de configuración voicemail.conf que podremos ampliar en Buzones de Voz. secret: La contraseña de autentificación en formato texto plano. Es altamente insegura por motivos evidentes. En caso de ser un proveedor, ya que contra nosotros se efectúa la autentificación no resultaría tanta inconveniencia (excepto por la inseguridad ante los accesos a nivel físico/sistema operativo) md5secret: En un intento de aportar algo más de seguridad al sistema es posible definir esta contraseña en vez de la ofrecida por "secret". El metodo de construcción es a través un MD5-Hash cuya base es la siguiente: ::. El "usuario" sería el mismo que el puesto entre corchetes como nombre del par, el "dominio" por defecto sería asterisk o el especificado en el parametro "realm" como vimos en los Parámetros Generales. Y la "contraseña" seria a voluntad. Ejemplo: 100:asterisk:1234 type: El tipo de par IAX, las posibilidades, "user", "peer" y "friend". port: Si el dispositivo utiliza un puerto diferente al 5060 habría que especificarlo aquí. qualify: Comprueba si el dispositivo es alcanzable con el mensaje OK, y devuelve otro mensaje en función de su disponibilidad la otra máquina, además mide el tiempo de respuesta en el momento del chequeo. username: Una forma de redefinir el usuario de autentificación, en caso que no queramos utilizar el nombre del dispositivo que se encuentra entre corchetes como comentábamos antes. Al contrario que en SIP que este parámetro ya estaba obsoleto en favor de "defaultuser".

Algunos específicos: 

dbsecret: Seleccionamos la ruta exacta en nuestra base de datos AstDB la que apuntan las contraseñas de los usuarios IAX.



auth: Tipo de Autentificación para el par en concreto, puede tomar valores como "plain", "rsa" o "md5".

Es interesante saber, que IAX solo tiene un método de marcación de tonos DTMF por tanto no existen parámetros específicos para variar este comportamiento. Información Genérica sobre los Pares Al igual que es posible ver en el apartado de Tipos de Pares de SIP, pero específicamente destinado a IAX, los mismos criterios se aplican para su configuración. En este sentido no hay nada especial que ampliar por la tanto la propia referencia anterior haría las veces explicativas. En este sentido, los pares se comportan de forma muy similar. Por otro lado, con respecto al sistema de nombramiento, ocurre exactamente lo mismo, pero es menos común hablar de esto en el entorno del protocolo IAX puesto que por regla general, los Pares de tipo teléfono, o punto final de conexión (Softphones incluidos), suelen utilizar el protocolo SIP. Es cierto que cada vez más dispositivos incorporan el protocolo IAX como venimos observando a lo largo del artículo, pero curiosamente, los más populares, aún siguen siendo reticentes a incorporarlo y aún más chocante, los teléfonos presentados por Digium solo ofrecen posibilidades dentro del protocolo IAX lo que resulta un golpe en contra de la popularización de este gran protocolo. Además también cómo es posible contemplar en el protocolo SIP acerca del uso de plantillas para configurar múltiples pares de forma más genérica, también es posible, pero ocurre lo mismo, no es algo extendido dado que es muy típico ver ficheros iax.conf, con apenas muy pocos pares configurados (otras máquinas Asterisk que se entrelazan).

Acceso a Invitados Esta parte forma realmente una sección de Seguridad, pero realmente no deja de ser una funcionalidad más del protocolo IAX Para poder permitir el acceso a los mismos es necesario eliminar el hecho de la obligatoriedad en la solicitud del Token de Llamada puesto que no se realizaría ninguna autentificación realmente. Además como comentado en el apartado de Seguridad puede resultar verdaderamente importante limitar el parámetro maxcallnumbers_nonvalidated a límites que sepamos que nuestra máquina puede controlar, dado que esta libertad de acceso puede suponer un grave contratiempo si no está bien controlado. Un ejemplo de configuración de un fichero IAX con posibilidades limitadas de acceso a Invitados podría ser así (en formato muy simplificado pero funcional):

Acrónimo de “Skinny Client Control Protocol”. Es un protocolo propietario de Cisco. Es el protocolo por

defecto para terminales con el servidor Cisco Call Manager PBX que es el similar a Asterisk PBX. El cliente Skinny usa TCP/IP para transmitir y recibir llamadas. Para el audio utiliza RTP, UDP e IP. Los mensajes Skinny son transmitidos sobre TCP y usa el puerto 2000. Para el tráfico de datos (flujo de datos de audio en tiempo real) se utiliza RTP/UDP/IP]. SCCP es un protocolo basado en estímulos y diseñado como un protocolo de comunicación para puntos finales hardware y otros sistemas embebidos, con restricciones de procesamiento y memoria significativas. Cisco adquirió la tecnología SCCP cuando compró la empresa Selsius a finales de los años 1990. Como una reminiscencia del origen de los actuales teléfonos IP Cisco, el nombre por defecto de los teléfonos Cisco registrados en un CallManager es SEP (Selsius Ethernet Phone) seguido de su MAC address. SCCP es también usado en CSS7 (señalización de red) como complemento al conjunto de protocolos de transporte fiable MTP. Principios de la SCCP La capa Parte de Control de la Conexión de Señalización o PCCS (SCCP -Signalling Connection Control Part), se incluye por encima de la Parte de Transferencia de Mensajes (PTM o MTP) de la pila N7 para proporcionar funciones adicionales de servicios de transferencia de información a nivel de red Este servicio de transferencia de información no está relacionado con la señalización (establecimiento, mantenimiento o liberación) de un circuito de conversación, sino que es utilizado para acceder a bases de datos que permitan conocer cómo debe evolucionar una llamada bá sica o un servicio suplementario en un entorno de red. De alguna forma complementa a la MTP para ofrecer servicios puros de capa de Red de OSI.

Sirve como soporte (añadiendo la capa de Capacidades de Transacción -TCAP-) a determinados usuarios de Parte de Aplicación, como: PAM: Parte de Aplicación de Móviles. PAOM: Parte de Aplicación de Operación y Mantenimiento. PARI: Parte de Aplicación de Red Inteligente.

Parte de Aplicación de Red Inteligente (PARI o INAP) Como hemos comentado, el protocolo INAP o PARI se basa en operaciones entre entidades físicas. Cada operación se refiere a una acción o requisito concreto, e incluye un conjunto de parámetros que son necesarios para interpretarla en un contexto concreto. El principio de codificación de estas instrucciones se basa en ASN1. A continuación se comentan algunas de las operaciones típicas de PARI, la dirección en que puede darse, y los parámetros necesarios. Operación PARI y parámetros

Sentido

Descripción y parámetros

InitialDP

SSF ® SCF

Indica que una llamada requiere un servicio de Red Inteligente

Connect

SSF ¬ SCF

Especifica el destino al que la llamada debe ser enrutada.

InitiateCallAttempt

SSF ¬ SCF

Petición de inicio de llamada

ReleaseCall

SSF ¬ SCF

Petición de que la llamada no debe enrutarse, si no liberarse, por una causa

CollectInformation

SSF ¬ SCF

Indica que se desea recoger información del usuario

Continue

SSF ¬ SCF

Indica que debe proseguir el proceso de la llamada

SendChargingInfo

SSF ¬ SCF

Petición de envío de tarificación al abonado llamante o llamado, mediante pulsos u otros mecanismos

ConnectToResource

SSF ¬ SCF

Crea una conexión entre el llamante y la SRF, con objeto de darle una locución o recoger dígitos.

PlayAnnouncement

SSF ¬ SCF

Petición de suministrar una locución o tono al llamante.

IP ¬ SCF CallInfoRequest

SSF ¬ SCF

Petición de información al SSF de determinados datos de la llamada (tiempo de conversación, hora de comienzo, causa de liberación,...)

CallInfoReport

SSF ® SCF

El SSF proporciona la información pedida en la operación CallInfoRequest

CallGap

SSF ¬ SCF

Petición de espaciamiento (con un determinado ratio) de llamadas relacionadas con algún servicio, abonado, etc.

PRINCIPIOS DE LA SCCP Servicios ofrecidos por la SCCP El SCCP, junto con la Parte de Transferencia de Mensajes, forma una pila de protocolo, equivalente al Nivel de Red OSI. Los servicios de transferencia de información del SCCP pueden ser Orientados o No orientados a la conexión. Los servicios Orientados a la conexión establecen un circuito virtual entre los extremos SCCP, mientras que la información en los entornos No orientados a la conexión empieza y acaba en sí mismos. El protocolo SCCP proporciona cuatro clases de servicios:

CLASE

Descripción

0

NO orientado a conexión, BASICO. No se establece un circuito virtual, empezando y acabando cada unidad de protocolo en sí misma. No se asegura el envío de sucesivas unidades de protocolo por un mismo link de señalización (en secuencia).

1

NO orientado a conexión, con SEGMENTACIÓN Y SECUENCIA No se establece un circuito virtual, empezando y acabando cada unidad de protocolo en sí misma. No se asegura el envío de sucesivas unidades de protocolo por un mismo link de señalización (en secuencia).

2

Orientado a conexión, BASICO. Se establece un circuito virtual entre los extremos SCCP que se identifica mediante una referencia. No se realiza control de flujo ni se soportan procedimientos de recuperación de errores (sólo notificación), siendo estas funciones responsabilidad de la aplicación superior.

3

Orientado a conexión, con CONTROL DE FLUJO. Se establece un circuito virtual entre los extremos SCCP que se identifica mediante una referencia. Se numeran las unidades de protocolo de datos par a control de flujo, aunque no se soportan procedimientos de recuperación de errores (sólo notificación), siendo esta responsabilidad de la aplicación superior.

BLIBIOGRAFIA 1) Protocolos de Señalización para el transporte de Voz sobre redes IP - Jose Ignacio Moreno, Ignacio Soto, David Larrabeiti - Departamento de Ingeniería Telemática - Universidad Carlos III de Madrid. Link: http://www.it.uc3m.es/~jmoreno/articulos/protocolssenalizacion.pdf  2) Wikipedia – MGCP. Link: http://es.wikipedia.org/wiki/MGCP 3) Monografía - Telecomunicaciones. Link: http://www.monografias.com/trabajos33/telecomunicaciones/telecomunicaciones2.shtml 4) Telefonía IP – Universidad Politécnica Salesiana. Link: http://dspace.ups.edu.ec/bitstream/123456789/208/2/Capitulo%201.pdf  5) Wikipedia – Softswitch. Link: http://es.wikipedia.org/wiki/Softswitch