SIP

Para definir y concretar acerca del protocolo SIP (Session Initiation Protocol, o Protocolo de Inicio de Sesiónes), sería viable diseñar una Wiki específica en la que poder detallar todo lo referente al mismo, desde su historia, su(s) RFC(s) (RFC 3261, y sucesivos para numerosas extensiones del mismo), sus usos, proxies y software especifico como Kamailio y OpenSIPS, de hecho Digium difunde cursos específicos sobre este protocolo para su máximo entendimiento y aprovechamiento.

En esta primera aproximación, no vamos a tratar este protocolo con tanta profundidad como quizá exige, pero existe numerosa bibliografía al respecto, y concretamente apunto a una por cercanía con respecto a la idea subyacente de este proyecto de AsteriskWIKI

Digamos que la mayor parte de las conexiones que se realizan entre estaciones, pasarelas y dispositivos de telefonía IP en general, que no contienen Asterisk en esencia, con respecto a nuestra máquina, están basadas en el protocolo SIP.

Conceptos Básicos

Es muy importante tener presentes algunos conceptos básicos sobre el protocolo SIP para poder entender como funciona todo, y en esencia incluso, poder tratar futuros problemas que pudieran derivar de un error de configuración, o incluso, de interconexión entre terminales de cualquier índole.

Relación entre SIP y Asterisk

Existe una mala concepción sobre como funciona realmente el SIP porque es común pensar que es encargado de llevar los datos multimedia, así como los mensajes de sesión conjuntamente. Parte de esta afirmación es cierta, concretamente la segunda parte, dado que este protocolo fue diseñado exclusivamente como sistema de señalización conjuntamente a otro flujo de datos multimedia a través de un protocolo simultáneo (que en Asterisk sería el protocolo RTP, Protocolo de Transporte en Tiempo Real, o Real-Time Tranport Protocol). Además para "complicar" el concepto, durante la trasmisión también interviene un tercer protocolo "familiar" de SIP llamado SDP (Protocolo de Descripción de Sesiones, o Session Description Protocol), redactado en el RFC 4566 y embebido dentro del protocolo SIP por lo que no consumiría más recursos (por ejemplo Puertos a nivel TCP/IP), y se encargaría de enriquecer el mensaje entre sesiones necesario para la trasmisión eficaz entre los dispositivos.

Realmente SIP no es capaz de ofrecer un servicio por si mismo, pero contiene los mensajes primitivos para poder implementar los servicios subyacentes sobre el mismo. Por eso, SIP curiosamente, no tiene nada que ver realmente con la telefonía en si, solo podría considerarse un estándar cualquiera de entendimiento entre dispositivos, algo que realmente todavía no se ha asentado, ya que múltiples dispositivos, aun no siguen los estándares "impuestos" dentro de los RFC, ya que aun no ha madurado hasta la categoría de estándar IEEE.

SIP se popularizo, debido que en el momento de la implementación de servicios de telefonía IP, no existían realmente grandes competidores en este aspecto. Además la seguridad utilizando SIP no prima especialmente, debido a que la trasmisión se realiza con mensajes de texto, y para encriptar la información es fundamental recurrir a extensiones independientes que transforman los mensajes en ambos nodos.

En el año 2010 nació como RFC 5456 un verdadero competidor, IAX, pero demasiado tarde, ya que el mercado de las telecomunicaciones IP (y concretamente dispositivos y productores), ya se había asentado sobre el protocolo SIP.

Funcionamiento Esencial

Flujo Mensajes SIP

SIP en la capa de transporte OSI, puede trabajar tanto con puertos TCP como UDP, y de hecho UDP suele ser elegido regularmente. El puerto de elección más común y estandarizado es el 5060, y como comentábamos con anterioridad, a través del mismo, también se trasmiten los mensajes del protocolo SDP.

Por otro lado, para trabajar con Audio en Asterisk tenemos que utilizar forzosamente el protocolo RTP para llevar el tráfico. Para cada canal de audio es necesario trabajar con un puerto independiente, y esto acarreara aún mas problemas en la seguridad, o en la interoperatividad con nuestro sistema. Veremos soluciones más adelante para salir del paso, ninguna bajo mi criterio, especialmente excepcional.

Los mensajes clásicos de SIP son los siguientes:

• INVITE
• REGISTER
• ACK
• BYE
• OPTIONS

En la imagen, podemos ver un flujo clásico de mensajes entre un servidor Asterisk y dos teléfonos conectados al mismo.

Problemas derivados de SIP y Asterisk

Siguiendo la linea, existen una serie de problemas que derivan del uso de SIP con nuestra máquina Asterisk, cuando tratamos de acceder al exterior (concretamente a Internet), de manera bidireccional. Supongamos que tenemos un teléfono conectado a nuestro servidor Asterisk, y a su vez, nuestro servidor Asterisk quiere comenzar a trasmitir datos con otro servidor SIP externo, o también la posibilidad que un teléfono fuera de nuestra red local, desea conectar a nuestro servidor Asterisk y trasmitir audio bidireccionálmente con uno de los teléfonos ubicados dentro de la red y también conectado a este servidor en cuestión.

Nos vemos ante dos problemas con sus respectivas soluciones:

• Problemas con el NAT
• Problemas con los puertos

Problemas con el NAT

Si viviéramos en un mundo IPv6 esto eventualmente no sucedería, pero como estamos de alguna forma supeditados al uso de un NAT sobre otro NAT sobre otro NAT, etc, etc dado que poseemos un número excesivamente limitados de direcciones IPv4 nos encontramos ante el primer problema.

Tenemos un Router con conexión a internet, y asignada una dirección IP concreta. Dentro de la red local de ese router, nuestra máquina posee una dirección local. En las cabeceras SIP al enviar el paquete de iniciación de sesión a través del router, el servidor remoto por defecto, registraría nuestro equipo apuntando a la dirección local, y por consiguiente, no existiría una ruta de regreso para seguir la trasmisión de mensajes y que se complete la "transacción" adecuadamente.

Si nuestro router posee funciones "avanzadas" para la gestión del nat, si en nuestra configuración de Asterisk, en el fichero de configuración del protocolo SIP marcamos que nos debemos registrar activando una propiedad especifica (nat=yes), Asterisk implementaría una función exclusiva para resolver este problema forzando el comportamiento descrito en el RFC 3581 y adicionalmente, habilitando el soporte para el RTP Simétrico, aparte que es fundamental que el router posea capacidades de NAT Transveral e implemente los correspondientes ALG

Problemas con los puertos

Este es el escenario más clásico perpetuado por el uso del protocolo RTP, el cual utiliza puertos aleatorios y muy difícilmente controlables (o al menos todo intento de control provoca en última instancia fallos en la comunicación debidos a su relativa aleatoriedad).

Por un lado, nos encontramos lo clásico: necesitamos abrir puertos en nuestro Cortafuegos para permitir el paso de datos por uno o varios determinado en concreto.

Para el caso de SIP/SDP no hay problema, porque si hemos elegido el puerto por defecto 5060, simplemente con abrir este, ya permitiriamos el paso y podríamos ver en nuestro registro de eventos, el intercambio de mensajes satisfactoriamente. Realizamos la llamada, vemos con salen los mensajes ACK, INVITE, OK... suenan los teléfonos, descolgamos y nos damos cuenta de pronto que no hay voz. Los datos RTP estan siendo bloqueados en el Cortafuegos. La pregunta es ¿que puerto debemos desbloquear ahora para permitir el paso?

Existen tres formas de planteárselo:

• Abrir todos los puertos necesarios según configuración en el fichero correspondiente (rtp.conf). A nivel de seguridad es una idea nefasta.
• Utilizar un servidor VPN (Virtual Private Network) al que conectaría nuestro dispositivo remoto, y una vez dentro, ya se establecería la conexión como si formara parte de la red local. La inconveniencia principal esta basada en cuestiones de rendimiento, aunque resulta relativamente popular.
• Trabajar con un servidor STUN RFC 3489. Esta solución es quizá la mas compleja y existen múltiples fuentes de documentación que tratan específicamente sobre ella.

Además para mantener los puertos abiertos, y haciendo uso del mensaje OPTIONS de SIP, desde la configuración sip.conf podemos forzarlo a través de un parámetro "multiproposito" (qualify=yes) que realmente se encarga de informar sobre los dispositivos conectados al sistema, entre otros aspectos, su estado, tiempo de respuesta, etc.

Parámetros de Configuración

La relación entre el protocolo SIP y Asterisk se establece a traves del fichero de configuración sip.conf dentro del directorio de configuraciones por defecto /etc/asterisk

La estructura del fichero se categoriza por secciones delimitadas por corchetes. La sección genérica con los valores por defecto se denomina [general] y el resto de las secciones corresponden a todos los puntos SIP que conectan y autentican con Asterisk (teléfonos IP, softphones, proveedores VoIP, pasarelas ATA, etc) y pueden tener nombres genéricos. Un ejemplo de estructura:

Archivo: /etc/asterisk/sip.conf

[general]
...

[proveedorvoip]
...

[telefonooficina]
...

Configuración General

La mayor parte de los parámetros pueden englobarse en la sección general, y servirían como parámetros por defecto aplicables tanto al protocolo SIP como a lo pares de telefonía IP concretos que definamos a continuación (excepto a los valores de autentificación con los mismos como es obvio).

Alguno de los parámetros mas comunes podrían ser los siguientes:

• bindport: Aqui podemos especificar el puerto especifico al que escuchara nuestra máquina Asterisk para conexiones SIP (puerto UDP), por defecto el 5060.
• externhost/externip: En caso que estemos tratando de efectuar conexiones desde fuera de nuestra red local, con un NAT de por medio, podemos forzar el nombre del host o la dirección IP concreta, para que se incluya en las cabeceras SIP, y así poder evitar una parte del problema de trabajar con NAT (con la opción nat=yes que veremos mas adelante).
• allowguest: Permitimos llamadas de invitados, lo recomendable seria ponerlo "allowguest = no" por motivos de seguridad
• realm: Dominio de autentificación, para cuestiones generales en el registro de pares. Ademas curiosamente, los passwords MD5 se construyen en parte siguiendo lo especificado en este parametro. Por defecto el "realm" es "asterisk"
• 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".
• rtcachefriends: Si trabajamos con Asterisk Realtime para configurar SIP (tabla sippeers) 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.
• srvlookup: Existe una cuestión que trataremos a continuación acerca del "emparejamiento" de cabeceras SIP 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, seria 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)
• relaxdtmf: Sirve para que los tonos no sean tan "estrictos", especialmente práctico para llamadas de baja calidad, pero puede probar que se reconozcan tonos incorrectos en contrapartida.

Conexión Multimedia Directa entre Terminales

Por regla general, el escenario más común es la trasmisión de todo el trafico, tanto SIP/SDP como RTP, a través del servidor Asterisk, y a los terminales o dispositivos involucrados en el proceso. O en la otra parte, también existe el escenario de dos terminales que aceptan el protocolo SIP trasmitiéndose toda la información directamente entre los mismos.

Pero existe un escenario, muy especifico, en el que los mensajes SIP/SDP pasan a traves de la máquina Asterisk, pero el trafico RTP va directo entre los terminales. Para ello existe un parámetro concreto en archivo de configuración sip.conf, llamado directmedia=yes gracias al cual, podríamos resultar en este escenario concreto.

Surgirían ciertas inconveniencias (o ventajas si es lo que vamos buscando), por ejemplo, el hecho que al no pasar los medios a través de nuestra máquina Asterisk, funcionalidades que aportan determinados módulos (aplicaciones concretamente), como la grabación o escucha de llamadas en tiempo realidad, quedarían inutilizados dado que ese tráfico estaría fuera del alcance de nuestro sistema.

Además con que uno de los pares, no utilice el mismo códec de trasmisión, al ser forzosa la transcodificación en tiempo real, Asterisk tomaría el control por defecto y no se daría la conexión directa.

Tipos de Pares

Existen tres tipos de Pares dentro de la configuración SIP, considerando estos, como todo elemento que opera a través del protocolo SIP de comunicaciones. Aquí hablamos principalmente de:

• Operadores (S)IP
• Teléfonos (S)IP (también llamados Hardphones)
• Software de telefonía (S)IP (también llamado Softphone)
• Pasarelas ATA, dispositivos que a través del protocolo SIP, entrelazan un sistema Asterisk, con la PSTN

Peer

Cuando conectamos un elemento SIP con el tipo Peer, estamos considerando que se trata de un punto, por el cual tendremos intención de cursar llamadas, es decir, acceder a su Plan de Marcación, pero que esto no podrá producirse a la inversa. Este tipo de configuración es muy típica, cuando nos conectamos a Operadores IP que nos ofrecen servicios de llamadas a través de Internet, o incluso cuando nuestra máquina Asterisk depende de una máquina "superior" que actúa como Operador para la nuestra. Para nosotros, marcas de telecomunicaciones reconocidas, podrían considerarse Peers.

User

En este caso, hablamos de justo lo contrario a un Peer. Como la misma palabra dice, hace referencia a un "usuario" de nuestro sistema. Si nosotros, de alguna forma, somos "operadores", definiríamos como "User" a esas máquinas Asterisk para que puedan acceder a nuestro Dialplan (obviamente, aportando de forma adicional un sistema de autentificación como veremos mas adelante). En este sentido, al nosotros ser Operadores, es muy probable que no necesitemos cursar llamadas a través de todos los usuarios que se conectan a nuestra máquina ya que simplemente ofrecemos el servicio, no lo recibimos. Este tipo de configuración es muy poco común y tenderá a desaparecer en futuras versiones para dar paso a Friend en contrapartida que es más consistente.

Friend

Este término se usa para designar a una conexión bidireccional. Sería la combinación de un User y un Peer. El caso más típico, sería el de un teléfono como extensión dentro de nuestro servidor. Pero también podría ser común en la conexión bidireccional, con una pasarela ATA, que no solo cumple la función de emitir llamadas, sino que a través de un número DDI (Direct Dial-In, algo así como un número de marcación Directa), ofrecido por nuestra operadora, también estaríamos accesibles para recibir llamadas hasta nuestra máquina. De hecho ciertos operadores IP ofrecen ambos servicios así que podríamos "otorgarles" esta comunicación bidireccional.

Configuración Específica de los Pares

Muchos de los parámetros generales pueden considerarse como específicos para un elemento que opera con SIP concreto tenga una propiedad diferente, que el resto que utilizase la configuración general. Lo único especial a tener en consideración para los pares tipo User y tipo Friend es acerca del nombre del contexto (lo que va contenido entre corchetes al principio de la definición de la extensión), es exactamente el nombre de usuario (username) con el que se autentificara el dispositivo al conectar a nuestra máquina. Para el caso de los tipo peers, este dato es meramente informativo, ya que para la autentificación necesitaremos enviar un mensaje REGISTER concreto, como veremos más adelante.

A continuación los parámetros más populares:

• allow/disallow: Mismo uso que en el caso general, pero específicamente para un par en concreto.
• defaultuser: 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 comentabamos antes.
• callerid: Sirve para que nuestro destinatario vea un "Identificador" de llamada especifico cuando llamemos desde este dispositivo
• busylevel: Si queremos limitar el numero de llamadas entrantes que puede recibir nuestro dispositivo hasta que de la señal de "COMUNICANDO".
• call-limit: Numero máximo de llamadas que podemos cursar simultáneamente a través de este dispositivo.
• context: Mismo uso que el caso general, especifico para el dispositivo en cuestión.
• dtmfmode: Hace referencia al modo DTMF que queremos utilizar para este dispositivo en concreto. Las opciones son "inband","rfc2833","info".
• fromuser/fromdomain: Si queremos alterar la cabecera del mensaje SIP en el apartado From: cuando lo enviamos a un servidor por algun motivo concreto del mismo en caso que nos conectemos a este como tipo Peer.
• 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.
• insecure: La misma palabra habla sobre niveles de seguridad en la comunicación. Este es un tema especifico a tratar en el apartado Seguridad. Las opciones son "invite", "port" y "no" (por defecto). Establece el nivel de autentificación y comprobación que se establece entre las máquinas a la hora de realizar la comunicación.
• port: Si el dipositivo utiliza un puerto diferente al 5060 habría que especificarlo aqui.
• qualify: Utilizando el mensaje SIP, OPTIONS, comprueba si el dispositivo es alcanzable, y mide el tiempo de respuesta en el momento del chequeo.
• permit/deny: Más opciones de seguridad, sirve para restringir las redes y mascaras 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 (recordando que SIP envía mensajes de texto durante su comunicación). 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 mas de seguridad al sistema es posible definir esta contraseña en vez de la ofrecida por "secret". El metodo de construcción es a traves un MD5-Hash cuya base es la siguiente: <usuario>:<dominio>:<contraseña>. 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
• nat: Haciendo referencia al apartado anterior que comentabamos acerca del problema con los NAT, este parámetro es el encargado de intentar resolverlo. Existen varias posibilidades adicionales aparte de "yes|no". Considerando que "yes" significa aplicar el modo COmedia y las capacidades de crear una conexión RTP simetrica, y "no" significa no aplicar ninguna de estas dos soluciones, y utilizar el metodo RFC 3581 convencional, como termino intermedio "force_rport", aplica el método RFC 3581, y deshabilita la conexión RTP simetrica, y finalmente "comedia" sería equivalente a utilizar "yes", pero contando exclusivamente que el otro par solicite voluntariamente la posibilidad de aplicar el método COmedia.
• type: Justamente es el tipo de par que comentabamos en el apartado anterior, las posibilidades, "user", "peer" y "friend".

Nombrando los Pares

Partiendo de la base que en Asterisk, una extensión no tiene que estar necesariamente asociada a un dispositivo, por ejemplo a un par podríamos llamarle "telefono-ventas" y ponerle la extensión numero 200. Cuando nos referimos a llamarle, nos referimos literalmente a comunicarnos con el, en este caso a traves del protocolo SIP, y por tanto como podemos avanzar en el apartado Dialplan si queremos hacer que suene este teléfono, lo haríamos con la aplicación especifica de Marcado (Dial) seguido del Nombre del par SIP y no del numero de extensión. Esto es mas facil verlo en la práctica en el apartado antes señalado.

Pero saliendo de este concepto, hay un tema que resulta relativamente interesante desde el punto que concierne a la creación de una estructura de extensiones, fácilmente mantenible en el tiempo, que tenga un compromiso con la seguridad y que eventualmente, pueda existir un seguimiento medianamente decente. Al poder llamar a nuestros dispositivos a voluntad, tendríamos que elegir un sistema que fuera lo suficientemente compensado. Diversos autores ponen en común el mismo sistema: Nombrar las dispositivos por su dirección MAC.

Planteándolo:

• Si elegimos nombrar por numero de extensión del plan de marcación, nos encontramos ante el dilema, que si cambiamos la extensión en el Dialplan entonces también tenemos que hacerlo en el archivo de configuración SIP para seguir preservando este sistema. Si no somos rigurosos, con el tiempo es un autentico desastre (la extensión 200 llama al dispositivo 205, y la extensión 210 llama al dispositivo 203, no tiene ningún sentido).

• Si elegimos nombrar por un dato significativo con respecto al teléfono, por ejemplo, telefono-ventas, es una buena idea a priori, el problema es que asociamos el dispositivo al usuario. En el caso que necesitemos cambiarlo de lugar, volvemos a caer en la misma inconveniencia, tendríamos que cambiarle el nombre del dispositivo. Partiendo por la base de la capacidad de "abstracción" extensión-nombre de peer-usuario nos encontramos entre dos aguas, designando un puesto, y a la vez un usuario.

• En caso de elegir nombrar con un nombre de usuario, sería una buena idea, en el caso que lo que estemos buscando es "portabilidad" de la extensión para un determinado usuario. En este caso por ejemplo, si el usuario harrysmith desea que en el teléfono de ventas entren sus llamadas, accedería a la configuración del mismo, y configuraría el dispositivo con sus credenciales. Lo mismo ocurre para otros dispositivos como softphones. El problema entraña la seguridad dado que por regla general al poder acceder a la configuración de los teléfonos también tiene capacidad de acceder a otros datos que eventualmente podría interesarnos limitar su acceso.

• Para el caso este, definiríamos entonces dispositivos como elementos estáticos, en los que no hay usuarios entrando y saliendo con sus respectivas credenciales. Descartando entonces las anteriores alternativas, surgiría la comentada al principio como más popular, nombrarlos por la dirección MAC (o al menos los últimos pongamos, 8 valores).

De todas formas, para organizaciones relativamente pequeñas, con menos de 50 extensiones, todo esto realmente no cobra una importancia especialmente desmedida, y quizá la primera opción podría considerarse la más versátil.

Sistema de Emparejamiento de Pares

Cuando recibimos un mensaje SIP en nuestra máquina, Asterisk ha de encargarse de buscar dentro del fichero SIP.conf que dispositivo (par) encaja mejor con la cabecera a la que hace referencia la sección "To:" o "From:.

Para ello Asterisk utiliza un sistema llamado "Peer Matching" que opera de la siguiente forma:

Caso Peer

En el caso de ser un tipo Peer al que evidentemente nosotros conectamos, se busca por que coincida la dirección IP y el puerto. El único problema que podemos encontrar aquí es el caso que nuestro proveedor (peer) nos de un hostname en vez de una IP concreta, y aqui entran en juego los registros DNS SRV, parametros como vimos antes tipo srvlookup juegan un rol importante. Es muy común encontrar problemas ya que no solo dependemos de software diferente a Asterisk, sino también de que los servidores de nombres externos hagan bien su papel durante la comunicación.

Es muy común ver múltiples definiciones de peer para un mismo operador IP, considerando que para un hostname concreto, pueden existir varias direcciones IP a las que apunta regularmente. Este método aun siendo muy engorroso, asegura que el Peer Matching se realiza de forma exitosa, y no se quedan llamadas "desemparejadas" (y perdidas en consecuencia) eventualmente.

Caso User

En este caso, busca en el From: el nombre de usuario (puede ser por ejemplo, un número de marcación directa, DDI), y lo asocia al nombre de usuario del peer en cuestión.

Caso Friend

Sería una combinación de ambas. Pero como este tipo de configuración es muy clásica en Teléfonos IP como extensiones de nuestra centralita, realmente el emparejamiento se suele realizar como se da en el caso de un tipo "user". Aunque eventualmente si estamos interconectando dos centrales Asterisk a través del protocolo SIP (aunque mala idea como podemos ver en el apartado IAX), o simplemente una central que soporta el protocolo SIP y nuestro sistema, el emparejamiento se podría realizar a nivel de dirección IP cuando se efectúa la conexión remota y en el "regreso" a nuestra central, el emparejamiento se realizaría a nivel de nombre de usuario.

Plantillas de Configuración de Pares

Dado que es muy común tener múltiples dispositivos compartiendo prácticamente la misma información relativa a los Parámetros Específicos excepto quizá, el nombre de usuario que se define entre corchetes, el buzón de voz asociado, y la contraseña, el resto de los parámetros pueden englobarse en un Meta-Dispositivo tipo Plantilla y luego aplicar la misma en los pares que compartan la misma información.

El par tipo plantilla se establece poniendo el símbolo (!) justo detrás del nombre de usuario entre corchetes. Y luego se aplica a los sucesivos dispositivos, poniendo justo después del nombre de usuario o contexto, el nombre de la plantilla entre paréntesis.

Un sencillo archivo de configuración de ejemplo, aplicando plantillas:

Archivo: /etc/asterisk/sip.conf

[moviles](!)
nat=yes
disallow=all
allow=ulaw

[100](moviles)
secret=1234
[101](moviles)
secret=5678

[102](moviles)
secret=9012

De esta forma reducimos la cantidad de datos en el archivo de configuración de forma muy considerable.

Véase también

• Seguridad

Enlaces Externos

• Kamailio y OpenSIPS los dos SIP Proxy más populares.