Los sistemas de sealizacin para el transporte de voz han evolucionado desde las redes basadas en conmutacin de circuitos a redes

basadas en conmutacin de paquetes. Diferentes estndares han aparecido para tratar de solventar problemas de direccionamiento, control de admisin, interconexin 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 diseados para el fluido el tiempo real de audio o cualquier otro tipo de medio de comunicacin. La PSTN est diseada para la transmisin de voz, sin embargo tiene sus limitaciones tecnolgicas. Es por lo anterior que se crean los protocolos para VoIP, cuyo mecanismo de conexin abarca una serie de transacciones de sealizacin entre terminales que cargan dos flujos de audio para cada direccin de la conversacin.

Acrnimo de Media Gateway Control Protocol. Inicialmente diseado para simplificar en lo posible la comunicacin con terminales como los telfonos. MGCP utiliza un modelo centralizado (arquitectura cliente * servidor), de tal forma que un telfono necesita conectarse a un controlador antes de conectarse con otro telfono, as la comunicacin no es directa. Tiene tres componentes un MGC (Media Gateway Controller, tambin llamado Call Agent), uno o varios MG (Media Gateway) y uno o varios SG (Signaling Gateway), el primero tambin denominado dispositivo maestro controla al segundo tambin denominado esclavo. No es un protocolo estndar. MGCP (Media Gateway Control Protocol) tiene su origen en el SGCP (de Cisco y Bellcore), e IPDC. MGCP soporta un control de sealizacin 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 estndar, su sucesor, Megaco est aceptado y definido como una recomendacin en la RFC 3015. Un gateway tradicional, cumple con la funcin de ofrecer conectividad y traduccin entre dos redes diferentes e incompatibles como lo son las de Conmutacin de Paquetes y las de Conmutacin de Circuitos. En esta funcin, el gateway realiza la conversin del flujo de datos, y adems realiza tambin la conversin de la sealizacin, bidireccionalmente. MGCP separa conceptualmente estas funciones en los tres elementos previamente sealados. As, la conversin del contenido multimedia es realizada por el MG, el control de la sealizacin del lado IP es realizada por el MGC, y el control de la sealizacin del lado de la red de Conmutacin de Circuitos es realizada por el SG. MGCP introduce esta divisin en los roles con la intencin de aliviar a la entidad encargada de transformar el audio para ambos lados, de las tareas de sealizacin, concentrando en el MGC el procesamiento de la sealizacin. El control de calidad de servicio QoS se integra en el gateway GW o en el controlador de llamadas MGC.

Un gateway de telefona es un elemento de red que provee conversin entre las seales de audio transportadas sobre los circuitos telefnicos 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 sincronizarn entre s para enviar comandos coherentemente a los gateways que estn bajo su control.

Lo que se propuso con MGCP fue sacar el control de la sealizacin del propio gateway (GW), llevndolo 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 el esclavo es el MGW (que puede ser un GW de VoIP, un DSLAM, un router MPLS, un telfono IP,...). Esta es precisamente la caracterstica que ms choca con la filosofa (P2P) de SIP. Otra caracterstica interesante es que intenta reproducir el modelo de la PSTN/IN sobre IP (en la Figura se ilustra el escenario tpico para un despliegue tipo Internet Telephony que es la aplicacin para la que se pens, al menos en principio esta solucin), en contra del modelo distribuido que propone SIP. Controlador de Medios (Media Gateway Controller MGC-), que proporciona la sealizacin H.323 o SIP y realiza el mapping entre la sealizacin de redes tradicionales y las redes de paquetes. Pasarela de Medios (Media Gateway MC-), que proporciona la adaptacin de medios y/o las funciones de transcodificacin. Este bloque realiza las funciones de traslacin de direcciones, cancelacin de eco, envo/recepcin de dgitos DMTF, etc.
Lo que se propuso con MGCP fue pasar el control de sealizacin 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 (sealizacin y gestin de servicios), procesamiento de llamadas, y otros servicios, sobre una red de conmutacin de paquetes (IP). El softswitch acta como gestor en el momento de interconectar las redes de telefona tradicional, e incluso las redes inalmbricas 3G con las redes de conmutacin de paquetes(IP), buscando como objetivo final lograr la confiabilidad y calidad de servicio similar a la que brinda una red de conmutacin de circuitos con un menor precio. Como todas las recientes tecnologas desarrolladas en telecomunicaciones, el softswitch busca la utilizacin de estndares abiertos para lograr la integracin de las redes de prxima generacin 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 integracin 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. Tambin se lo puede asociar cuando se habla de un MGC (Media Gateway Controller) en MGCP y MEGACO.

Diagrama de cisco MGC

Diagrama de descomposicin del Gateway e interaccin 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 cooperacin entre ITU e IETF, existan diversos protocolos que cumplan estas 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 transaccin se expresa por el envo de una transactionRequest por una de las entidades y el envo 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 conexin del protocolo MEGACO es un modelo orientado a objeto. Describe las entidades lgicas u objetos en el seno del MGW que pueden ser controlados por el MGC. Las principales abstracciones utilizadas en este modelo de conexin son las terminaciones (termination) y los contextos (context). El protocolo MEGACO permite el establecimiento de llamadas multipartes a diferencia del protocolo MGCP, que slo permite las llamadas entre dos partes. Una terminacin MEGACO comienza o termina uno o varios flujos. Una terminacin est descrita por un conjunto de propiedades reagrupadas en un conjunto de descriptores incluidos en las instrucciones. Una terminacin tiene una identidad nica (TermiantionId) otorgada en el momento de su creacin por el MGW. Ciertas terminaciones que representan entidades fsicas son semi-permanentes. Un circuito de voz ligado a un MGW es un ejemplo de terminacin semi-permanente. Otras terminaciones representan flujos temporales tales como los flujos RTP que slo existen durante el transcurso de la llamada correspondiente. Se trata de terminaciones temporales. Diagrama general de un sistema MEGACO

Acrnimo de Inter Asterisk eXchange, es un protocolo abierto, que se puede descargar y desarrollar libremente. Realmente IAX se refiere a IAX2, la segunda versin de este protocolo, dado que el primero fue reemplazado por este. No es considerado como un protocolo estndar. Es un protocolo de transporte, que utiliza el puerto UDP 4569 tanto para sealizacin de canal como para RTP (Protocolo de Transporte en tiempo Real). Puede truncar o empaquetar mltiples sesiones dentro de un flujo de datos, as requiere de menos ancho de banda y permite mayor nmero de canales entre terminales. En seguridad, permite la autenticacin, pero no hay cifrado entre terminales. Segn la documentacin (Asterisk 1.4) el IAX puede usar cifrado (aes128), siempre sobre canales con autentificacin MD5. El protocolo IAX fue diseado para Asterisk por su mismo creador Mark Spencer (de ah recibe sus siglas, Inter Asterisk eXchange, Intercambio entre Asterisk) para suplir mltiples desventajas que el protocolo SIP ofreca en aquel momento, y que por su naturaleza original, sigue teniendo. IAX2 est descrito en profundidad en el RFC 5456. En trminos generales, IAX es el mejor protocolo de sealizacin y transporte utilizado entre cualquier mquina Asterisk, y a ser posible entre cualquier dispositivo que tenga algo que ver con una mquina que disponga de nuestro sistema. IAX fue diseado pero hasta 2010 no apareci su implementacin en el RFC que comentbamos al principio. Funcionamiento del IAX

En este sentido, a nivel de sealizacin IAX es muy similar a la mayora de los protocolos de sealizacin no especficos y utilizados para la telefona IP como los comentados anteriormente. A nivel OSI, puede trabajar tanto con puertos de carcter 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 ms 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 informacin. Divisin en paquetes para cada tramo del medio, incorporando una cabecera por cada paquete, o una caracterstica especial, utilizando sus funciones especficas de "trunking", llevando todos los medios, en un solo paquete con una sola cabecera. Haciendo un anlisis 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 tamao de los paquetes. Si trabajamos con conexiones con muy poco ancho de banda, sera recomendable no utilizar esta capacidad de "trunking". Hay que entender, que este protocolo originalmente, fue diseado para conectar dos mquinas Asterisk entre s, de la forma ms eficiente, segura y fcil de implementar en cualquier escenario posible. Hoy en da existen muy pocas implementaciones y dispositivos que soporten este protocolo, pero ciertos proveedores, y diseadores de equipos, cada vez ms empiezan a incorporar sus desarrollos basados en este protocolo. Hasta cierta medida, podran 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 disposicin y acceso.

Mensajes ms 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 sealizacin como los medios para comunicarse entre dos puntos, son multiplexados a travs del mismo puerto, gracias a estas bondades, IAX si podra considerarse, al contrario de SIP en un verdadero protocolo de telefona IP (VoIP, voz sobre IP), dado que fue diseado originalmente para cumplir esta funcin. Otra de las ventajas, es que al solo necesitar una cabecera para la sealizacin que cubre todos los medios, podemos reducir considerablemente el tamao de los paquetes, y en consecuencia, la latencia (tiempo de respuesta), quedara reducida proporcionalmente. No debemos olvidar, que uno de los grandes problemas de protocolos como SIP y MGCP, es que al ser protocolos puros de sealizacin, los medios van a travs de otro protocolo independiente, RTP (Protocolo de transporte en tiempo real), esto significa, problemas sobre todo con los NAT (Network Address Translation - Traduccin de Direccin de Red), y muy especficamente, enormes con los NAT simtricos en los que hay que recurrir a soluciones, que ni siquiera hasta la fecha, estn 100% implementadas en nuestros sistemas Asterisk. Por ello, con la utilizacin de IAX, saltamos estos

problemas ya que al ir todo a travs del mismo canal, y por el mismo puerto, es fcilmente acotable y parametrizable en nuestros NAT, y Cortafuegos. Por ltimo y no la menos importante, la capacidad de incorporar caractersticas de seguridad como mejoras desarrolladas para protocolo especficamente en el sistema Asterisk. No es necesaria la instalacin de aadidos, ni mdulos especficos para conseguir este propsito. Todo a travs del fichero de configuracin especfico de IAX y casi recomendable prescribirlo por regla general. Soporta autenticacin de tipo PKI (Public-Key Infraestructure) con claves RSA (Sistema criptogrfico de clave pblica) 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 denegacin del servicio (Distribute Denial of Service). Por ello las medidas ms clsicamente utilizadas para mitigar este problema, era simplemente, limitar el nmero de llamadas mximo por cada host que conectase va IAX a nuestra mquina. Por otro lado, con las versiones ms recientes de IAX2, surgi la idea de utilizar un Token de autentificacin para garantizar un paso menos en la posibilidad de ver sufrir nuestra mquina ataques DDoS por mquinas sin autentificar. En el caso de requerir por cualquier motivo, el acceso a visitantes (guest) sin autentificar, nuestra mquina quedara bastante expuesta, pero las ltimas revisiones del protocolo protegen an ms ante este problema. En trminos generales podemos decir que ha existido demasiada fragmentacin de este protocolo surgida a raz de las diversas actualizaciones del mismo. Pero eventualmente si trabajamos con mquinas de la misma ndole (principalmente hablando de mquinas Asterisk, con similares, versiones, etc.), la seguridad en este sentido est bastante ms garantizada que con otros protocolos como SIP, donde los ataques DDoS, por ejemplo, con envos masivos de mensajes INVITE, suelen ser ms comunes. El segundo problema, surge a raz de la extensibilidad del protocolo. Este tema est ms que discutido, ya que al ser un protocolo libre, es relativamente accesible su modificacin. Parmetros de configuracin Muy parecido al protocolo SIP que suele servir de referencia a la hora de configurar el protocolo IAX, muchos de los parmetros de configuracin general son compartidos. Si sabemos configurar el fichero de configuracin del otro protocolo, no tendremos mucha dificultad para configurar este. Hay que considerar que el fichero de configuracin especifico esta contenido por regla general en el directorio /etc/asterisk/ y concretamente se trata del iax.conf. Configuracin General Dentro del contexto general podemos utilizar los siguientes argumentos comunes:

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

srvlookup: Existe una cuestin que trataremos a continuacin acerca del "emparejamiento" de cabeceras IAX con nuestros correspondientes pares dentro del fichero de configuracin. En el caso que queramos (intentar) este emparejamiento, utilizando los nombres de host en vez de las direcciones IP, sera conveniente activar este parmetro (srvlookup = yes). Pero al depender de "terceros" (bsqueda por DNS SRV), resulta un tanto aleatoria la posibilidad que este parmetro llego a aportar algo verdaderamente de valor) allow/disallow: Esta opcin es aplicable tanto a los pares como a modo general. Seran 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 opcin "disallow = all". Podemos encontrar ms informacin sobre codecs rtcachefriends: Si trabajamos con Asterisk Realtime para configurar IAX (tabla iaxpeers) sera un mtodo 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 Marcacin. En este caso es default, y sera conveniente o definirlo en el fichero de configuracin del Plan de Marcacin 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 especficos:

encryption: Permite encriptar la informacin trasmitida a travs 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 mquina Asterisk

Adicionalmente algunos parmetros especficos 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 lmite de tamao y as poder ajustar este sistema a nuestro ancho de banda, evitando el problema que surga por saturarlo y ser ms ineficiente. trunkmtu: Controlamos la Unidad Mxima de Transferencia de cada unidad de datos enviado a travs de nuestra red. trunkfreq: Podemos ajustar en milisegundos, la frecuencia de envo de paquetes. Ya son parmetros para un ajuste muy a medida de nuestra red y hay que tener cuidado al elegirlos dado que podramos colapsar las comunicaciones. trunktimestamps: Podemos mandar Marcas de Tiempo por cada trunk, y con ello habilitamos otra opcin de IAX jitterbuffer jitterbuffer: Creamos un Buffer para mejorar el Jitter de la conversacin. En el caso que los dos pares utilicen la funcionalidad de trunking, es fundamental que la opcin trunktimestamps este habilitada en ambos sentidos.

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

Configuracin Especfica de los Pares Volvemos a tener varios parmetros "compartidos" entre SIP e IAX, aparte algunos especficos como los que mencionamos a continuacin:

allow/disallow: Mismo uso que en el caso general, pero especficamente para un par en concreto. Podemos encontrar ms informacin 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, especfico para el dispositivo en cuestin. host: Aqui especificamos la direccin a la que nos conectamos si es un peer, en caso de ser un friend/user, podramos especificar la opcin "dynamic" y dejar abierta la posibilidad que cualquier dispositivo se conecte a nuestra mquina sin una IP en concreto. permit/deny: Ms opciones de seguridad, sirve para restringir las redes y mscaras de subred de las cuales dispositivos en las mismas puedan conectar a nuestra mquina. Un ejemplo podria ser permit = 192.168.1.0/255.255.255.0 permitira solo conexiones de dispositivos entrantes cuya IP pertenezca a esta subred. Amplio en Seguridad. mailbox: Si deseamos asociar un Buzn de Voz a un par concreto lo haremos a travs de este parmetro. Por ejemplo 100@ventas asociara el buzn numero 100 dentro del contexto ventas (esto es aplicable al fichero de configuracin voicemail.conf que podremos ampliar en Buzones de Voz. secret: La contrasea de autentificacin en formato texto plano. Es altamente insegura por motivos evidentes. En caso de ser un proveedor, ya que contra nosotros se efecta la autentificacin no resultara tanta inconveniencia (excepto por la inseguridad ante los accesos a nivel fsico/sistema operativo) md5secret: En un intento de aportar algo ms de seguridad al sistema es posible definir esta contrasea en vez de la ofrecida por "secret". El metodo de construccin es a travs un MD5-Hash cuya base es la siguiente: <usuario>:<dominio>:<contrasea>. El "usuario" sera el mismo que el puesto entre corchetes como nombre del par, el "dominio" por defecto sera asterisk o el especificado en el parametro "realm" como vimos en los Parmetros Generales. Y la "contrasea" 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 habra que especificarlo aqu. qualify: Comprueba si el dispositivo es alcanzable con el mensaje OK, y devuelve otro mensaje en funcin de su disponibilidad la otra mquina, adems mide el tiempo de respuesta en el momento del chequeo. username: Una forma de redefinir el usuario de autentificacin, en caso que no queramos utilizar el nombre del dispositivo que se encuentra entre corchetes como comentbamos antes. Al contrario que en SIP que este parmetro ya estaba obsoleto en favor de "defaultuser".

Algunos especficos:

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

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

Es interesante saber, que IAX solo tiene un mtodo de marcacin de tonos DTMF por tanto no existen parmetros especficos para variar este comportamiento. Informacin Genrica sobre los Pares Al igual que es posible ver en el apartado de Tipos de Pares de SIP, pero especficamente destinado a IAX, los mismos criterios se aplican para su configuracin. En este sentido no hay nada especial que ampliar por la tanto la propia referencia anterior hara 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 comn hablar de esto en el entorno del protocolo IAX puesto que por regla general, los Pares de tipo telfono, o punto final de conexin (Softphones incluidos), suelen utilizar el protocolo SIP. Es cierto que cada vez ms dispositivos incorporan el protocolo IAX como venimos observando a lo largo del artculo, pero curiosamente, los ms populares, an siguen siendo reticentes a incorporarlo y an ms chocante, los telfonos presentados por Digium solo ofrecen posibilidades dentro del protocolo IAX lo que resulta un golpe en contra de la popularizacin de este gran protocolo. Adems tambin cmo es posible contemplar en el protocolo SIP acerca del uso de plantillas para configurar mltiples pares de forma ms genrica, tambin es posible, pero ocurre lo mismo, no es algo extendido dado que es muy tpico ver ficheros iax.conf, con apenas muy pocos pares configurados (otras mquinas Asterisk que se entrelazan).

Acceso a Invitados Esta parte forma realmente una seccin de Seguridad, pero realmente no deja de ser una funcionalidad ms 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 realizara ninguna autentificacin realmente. Adems como comentado en el apartado de Seguridad puede resultar verdaderamente importante limitar el parmetro maxcallnumbers_nonvalidated a lmites que sepamos que nuestra mquina puede controlar, dado que esta libertad de acceso puede suponer un grave contratiempo si no est bien controlado. Un ejemplo de configuracin de un fichero IAX con posibilidades limitadas de acceso a Invitados podra ser as (en formato muy simplificado pero funcional):

Acrnimo 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 trfico de datos (flujo de datos de audio en tiempo real) se utiliza RTP/UDP/IP]. SCCP es un protocolo basado en estmulos y diseado como un protocolo de comunicacin para puntos finales hardware y otros sistemas embebidos, con restricciones de procesamiento y memoria significativas. Cisco adquiri la tecnologa SCCP cuando compr la empresa Selsius a finales de los aos 1990. Como una reminiscencia del origen de los actuales telfonos IP Cisco, el nombre por defecto de los telfonos Cisco registrados en un CallManager es SEP (Selsius Ethernet Phone) seguido de su MAC address. SCCP es tambin usado en CSS7 (sealizacin de red) como complemento al conjunto de protocolos de transporte fiable MTP. Principios de la SCCP La capa Parte de Control de la Conexin de Sealizacin 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 informacin a nivel de red Este servicio de transferencia de informacin no est relacionado con la sealizacin (establecimiento, mantenimiento o liberacin) de un circuito de conversacin, sino que es utilizado para acceder a bases de datos que permitan conocer cmo debe evolucionar una llamada bsica 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 (aadiendo la capa de Capacidades de Transaccin -TCAP-) a determinados usuarios de Parte de Aplicacin, como: PAM: Parte de Aplicacin de Mviles. PAOM: Parte de Aplicacin de Operacin y Mantenimiento. PARI: Parte de Aplicacin de Red Inteligente.

Parte de Aplicacin de Red Inteligente (PARI o INAP) Como hemos comentado, el protocolo INAP o PARI se basa en operaciones entre entidades fsicas. Cada operacin se refiere a una accin o requisito concreto, e incluye un conjunto de parmetros que son necesarios para interpretarla en un contexto concreto. El principio de codificacin de estas instrucciones se basa en ASN1. A continuacin se comentan algunas de las operaciones tpicas de PARI, la direccin en que puede darse, y los parmetros necesarios. Operacin PARI y parmetros InitialDP Sentido SSF SCF Descripcin y parmetros Indica que una llamada requiere un servicio de Red Inteligente

Connect InitiateCallAttempt ReleaseCall CollectInformation Continue SendChargingInfo

SSF SCF SSF SCF SSF SCF SSF SCF SSF SCF SSF SCF

Especifica el destino al que la llamada debe ser enrutada. Peticin de inicio de llamada Peticin de que la llamada no debe enrutarse, si no liberarse, por una causa Indica que se desea recoger informacin del usuario Indica que debe proseguir el proceso de la llamada Peticin de envo de tarificacin al abonado llamante o llamado, mediante pulsos u otros mecanismos Crea una conexin entre el llamante y la SRF, con objeto de darle una locucin o recoger dgitos. Peticin de suministrar una locucin o tono al llamante. Peticin de informacin al SSF de determinados datos de la llamada (tiempo de conversacin, hora de comienzo, causa de liberacin,...) El SSF proporciona la informacin pedida en la operacin CallInfoRequest Peticin de espaciamiento (con un determinado ratio) de llamadas relacionadas con algn servicio, abonado, etc.

ConnectToResource PlayAnnouncement

SSF SCF SSF SCF IP SCF

CallInfoRequest

SSF SCF

CallInfoReport CallGap

SSF SCF SSF SCF

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 informacin del SCCP pueden ser Orientados o No orientados a la conexin. Los servicios Orientados a la conexin establecen un circuito virtual entre los extremos SCCP, mientras que la informacin en los entornos No orientados a la conexin empieza y acaba en s mismos. El protocolo SCCP proporciona cuatro clases de servicios:

CLASE 0

Descripcin NO orientado a conexin, BASICO. No se establece un circuito virtual, empezando y acabando cada unidad de protocolo en s misma. No se asegura el envo de sucesivas unidades de protocolo por un mismo link de sealizacin (en secuencia).

NO orientado a conexin, con SEGMENTACIN Y SECUENCIA No se establece un circuito virtual, empezando y acabando cada unidad de protocolo en s misma. No se asegura el envo de sucesivas unidades de protocolo por un mismo link de sealizacin (en secuencia).

Orientado a conexin, 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 recuperacin de errores (slo notificacin), siendo estas funciones responsabilidad de la aplicacin superior.

Orientado a conexin, 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 para control de flujo, aunque no se soportan procedimientos de recuperacin de errores (slo notificacin), siendo esta responsabilidad de la aplicacin superior.

BLIBIOGRAFIA 1) Protocolos de Sealizacin para el transporte de Voz sobre redes IP - Jose Ignacio Moreno, Ignacio Soto, David Larrabeiti - Departamento de Ingeniera Telemtica - 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) Monografa - Telecomunicaciones. Link: http://www.monografias.com/trabajos33/telecomunicaciones/telecomunicaciones2.shtml 4) Telefona IP Universidad Politcnica Salesiana. Link: http://dspace.ups.edu.ec/bitstream/123456789/208/2/Capitulo%201.pdf 5) Wikipedia Softswitch. Link: http://es.wikipedia.org/wiki/Softswitch