Resultado de la API de MediaWiki
This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.
See the complete documentation, or the API help for more information.
{
"batchcomplete": "",
"continue": {
"gapcontinue": "Seccion:Avanzado",
"continue": "gapcontinue||"
},
"warnings": {
"main": {
"*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
},
"revisions": {
"*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
}
},
"query": {
"pages": {
"124": {
"pageid": 124,
"ns": 0,
"title": "Registro Llamadas y Eventos",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "{{ToDo}}\n\nEl registro de llamadas en Asterisk, llamado CDR (Call Detail Record), y de Eventos llamado CEL (Call Event Logging) proveen de m\u00faltiples mecanismos de almacenaje de toda la informaci\u00f3n relativa a las llamadas, con car\u00e1cter entrante y saliente del sistema, espec\u00edficamente dise\u00f1ado para su posible posterior anal\u00edsis.\n\n{{Centrar|{{#Widget:AdSense}}}}\n\n__TOC__ \n\n== Sistema CDR ==\n\nComo ve\u00edamos, CDR, Call Detail Record, es simplemente un registro de todos los pasos que concurren en una llamada, pero con un nivel de detalle bastante reducido. \n\n=== Introducci\u00f3n ===\n\nEste sistema es muy pr\u00e1ctico cuando queremos saber por ejemplo, a quien llaman nuestros usuarios, o quien los llama, y otros datos relativos a las mismas, como el tiempo establecido, resultado de la llamada (si estaba ocupada o no disponible, o si fue contestada), etc. Es muy similar en cierto sentido al sistema de Est\u00e1disticas aplicable a las [[Colas]] seg\u00fan puede verse con aplicaciones como [[Asternic Stats]] para el manejo de las mismas. Pero es bastante limitado en lo que se refiere a controlar el flujo de la llamada, ya que la cantidad de informaci\u00f3n que registra es bastante escueta.\n\nPero en este caso, se aplica para el 100% de las llamadas entrantes y salientes, e inclusive llamadas que se realicen dentro de la m\u00e1quina Asterisk. Los usos m\u00e1s t\u00edpicos que suelen darse para este sistema son:\n\n[[Image:a2billing.png|thumb|Sistema A2Billing de Facturaci\u00f3n|right|200px]] \n\n* Control de Llamadas\n* Sistemas de Facturaci\u00f3n a Terceros <ref>[http://www.asterisk2billing.org/ A2Billing] es un sistema de Facturaci\u00f3n para Asterisk de Star2billing S.L.</ref>\n* An\u00e1lisis y Depuraci\u00f3n del Sistema\n* Estad\u00edsticas varias.\n\nPara el sistema CDR existen m\u00faltiples formas de almacenamiento, principalmente las que hemos comentado, ficheros de texto plano, y diversos tipos de Bases de Datos que hacen referencia:\n\n* Por defecto, se almacena en un fichero llamado master.csv dentro del directorio /var/log/asterisk/cdr-csv/ en formato como su extensi\u00f3n indica, CSV (Comma-Separated Values, valores separados por comas), siempre que este activada la funci\u00f3n de almacenamiento de los CDR en su fichero principal de configuraci\u00f3n '''cdr.conf'''\n* Es posible Almacenar en Bases de Datos MySQL (fichero de configuraci\u00f3n '''cdr_mysql.conf''')\n* En BBDD de Tipo PostgreSQL (fichero '''cdr_pgsql.conf''').\n* Tambi\u00e9n en bases de datos SQLite (fichero '''cdr_sqlite3_custom.conf''')\n* Con un Driver ODBC parecido al sistema visto en [[Asterisk Realtime]] (Fichero '''cdr_odbc.conf''')\n* Podemos pasar al [[AMI]] informaci\u00f3n de lectura sobre el CDR (fichero '''cdr_manager.conf''')\n\nLos problemas del sistema CDR surgen debido a que solo se almacena un solo registro CDR con toda la informaci\u00f3n por llamada. Esto quiere decir, que en el caso que ocurran los siguients posibles casos, la llamada no se registrar\u00eda en condiciones:\n\n* Llamadas transferidas\n* Llamadas aparcadas \n* Sistemas de Conferencias\n* Llamadas puestas en Espera\n\n=== Configuraci\u00f3n Ficheros CSV ===\n\nPara poder configurar CDR, el fichero principal es llamado '''cdr.conf''' situado en el mismo directorio que el resto de los ficheros de configuraci\u00f3n '''/etc/asterisk/'''.\n\nLa estructura del mismo es relativamente b\u00e1sica, un contexto <nowiki>[general]</nowiki> como casi todos los m\u00f3dulos de Asterisk, y luego los siguientes contextos que hacen referencias a partes especificas, en este caso los dos m\u00e1s comunes son <nowiki>[csv]</nowiki> que hace referencia al fichero Master.CSV que comentabamos anteriormente, y <nowiki>[radius]</nowiki> para almecenamiento utilizando un servidor RADIUS para la autentificaci\u00f3n, pero en esencia un fichero CSV para el amacenaje.\n\n==== Configuraci\u00f3n General ====\n\nAqu\u00ed se especifican todos los par\u00e1metros que afectar al modo general de almacenaje utilizando este sistema:\n\n* '''enable''': B\u00e1sicamente activa la funcionalidad de registro CDR\n* '''unanswered''': Registra las llamadas no atendidas tambi\u00e9n\n* '''endbeforehexten''': En caso que llegemos a la [[Introducci\u00f3n Dialplan#Extensiones Especiales|extensi\u00f3n especial]], '''h''' parar\u00eda el registro CDR en el fichero\n* '''initiatedseconds''': En caso de utilizar un sistema de Facturaci\u00f3n, es pr\u00e1ctico para redondear el tiempo a nivel de segundos hacia arriba para facilitar el c\u00e1lculo del importe\n* '''batch''': Permite registrar la informaci\u00f3n en bloques, en vez de registrarla de un golpe al finalizar la conversaci\u00f3n. El riesgo es que si Asterisk se bloquea durante el proceso de una llamada escribiendo en el fichero, este estar\u00eda abierto y podr\u00eda perderse informaci\u00f3n.\n* '''size''': Si utilizamos el modo '''batch''', aqu\u00ed especificar\u00edamos el numero de registros CDR antes de lanzar un bloque (batch) a nuestro fichero.\n* '''time''': Tambi\u00e9n es posible lanzar un bloque por segundos, en este caso, ser\u00eda el n\u00famero de segundos antes de conformar un bloque y lanzarlo al fichero.\n* '''scheduleronly''': En caso que queramos que se genere un proceso espec\u00edfico para realizar la gesti\u00f3n de copia en bloque, o si queremos utilizar el propio proceso que controla el sistema de gesti\u00f3n de los bloques. \n* '''safeshutdown''': En caso que el sistema se detenga, paraliza esto, hasta que todos los registros CDR hayan sido grabados en el fichero.\n\n==== Configuraci\u00f3n Espec\u00edfica ====\n\nTanto para la copia directa en nuestra m\u00e1quina o utilizando un sistema RADIUS existen una serie de par\u00e1metros espec\u00edficos comunes y concretos de cada m\u00e9todo:\n\n* '''usegmtime''': Sirve para registrar los eventos en el huso GMT exclusivamente\n* '''loguiqueid''': Para registrar en cada evento, un identificador unico\n* '''accountlog''': En caso que queramos tener un registro independiente para cada c\u00f3digo de cuenta, esto es especifico para temas relativos a Facturaci\u00f3n\n\nY concretamente para el sistema RADIUS especificamos el fichero de configuraci\u00f3n del cliente que har\u00e1 la autentificaci\u00f3n con '''radiuscfg => ''' <ref>[http://developer.berlios.de/projects/radiusclient-ng/ Radius Client NG], Maxim Sobolev (2003)</ref>\n\n=== Configuraci\u00f3n Bases de Datos ===\n\nComo vimos en la secci\u00f3n anterior existen m\u00faltitud de formas de almacenaje dentro de posibles bases de Datos. Hay que considerar como vimos en el sistema [[Asterisk Realtime]], la mayor\u00eda de las adaptaciones para bases de datos espec\u00edficas como PostgreSQL y MySQL es posible que caigan en la obsolescencia debido a que la genericidad que ofrecen los driver ODBC ha superado ampliamente a estas alturas a esas adaptaciones personalizadas.\n\nLa ventaja general que tiene la escritura en base de datos, es la mayor dificultad o casi imposibilidad en la corrupci\u00f3n de la informaci\u00f3n como ocurre en el caso del fichero CSV.\n\n==== Configuraci\u00f3n ODBC ====\n\nEn terminos generales, el sistema de interfaz de nuestra m\u00e1quina Asterisk con un Driver ODBC se realizar\u00eda utilizando los siguientes ficheros de configuracion:\n\n* '''cdr_adaptive_odbc.conf''': Es la evoluci\u00f3n del antiguo cdr_odbc.conf que incorpora funciones adicionales para poder registrar la informaci\u00f3n a medida que deseemos volcar en nuestra base de datos valiendonos de la aplicaci\u00f3n Set dentro del Plan de Marcaci\u00f3n. A este sistema se le denomina CDR Adaptativo.\n* '''res_odbc.conf''': Es b\u00e1sicamente el fichero que establece la conexi\u00f3n directa entre el driver y Asterisk, especificando un DSN concreto.\n\nEl CDR Adaptativo surgi\u00f3 a partir de la versi\u00f3n 1.6 como una gran mejora, y se basa en la premisa que tenemos intenci\u00f3n de registrar en una base de datos, determinados aspectos concretos de una llamada. Para ello har\u00edamos referencia a la [[Funciones|funci\u00f3n CDR]] y seg\u00fan que parametro le pasemos, registraremos una informaci\u00f3n u otra en consecuencia. Adem\u00e1s podr\u00edamos crear nuevos campos dentro de la tabla, lo que convertir\u00eda al sistema CDR en un mecanismo mucho m\u00e1s vers\u00e1til.\n\nPor ejemplo en el Plan de Marcaci\u00f3n podriamos definir la siguiente ejecuci\u00f3n, en el caso que la extensi\u00f3n realice una llamada por una extensi\u00f3n concreta que llama a m\u00f3viles, podriamos establecer un campo adicional en nuestra base de datos, llamado coste_minuto, e ir asignandole un valor un otro dependiendo la extensi\u00f3n que haya tomado nuestro usuario para calcular el importe de la llamada (multiplicando la duraci\u00f3n de la misma, por la variable coste_minimo en funci\u00f3n de lo elegido:\n\n{{Archivo|/etc/asterisk/extensions.conf| ; Llamadas a Moviles<br>exten => _6XXXXXXXX,1,Set(CDR(coste_minuto)=0.05)}}\n\nLa estructura del fichero cdr_adaptive_odbc.conf esta basada en la definici\u00f3n de contextos por cada tabla a la que queramos hacer referencia del registro de llamadas. El contexto lo definimos con un nombre cualquiera descriptivo para la conexi\u00f3n, ejemplo <nowiki>[odbc_cdr]</nowiki>. Luego podemos definir los siguientes par\u00e1metros especificos:\n\n* '''connection''': El nombre del contexto dentro de res_odbc.conf al que queremos hacer referencia, tenemos m\u00e1s informaci\u00f3n de este fichero dentro del apartado [[Asterisk Realtime]].\n* '''table''': La tabla de la base de datos SQL donde vamos a almacenar la informaci\u00f3n\n* '''usegmtime''': Si queremos utilizar el tiempo en el huso GMT por defecto.\n\n==== Configuraci\u00f3n MySQL / PostgreSQL ====\n\nEn este caso, como comentaba antes, la mayor\u00eda de las soluciones \"a medida\" para diferentes bases de datos estan quedando obsoletas en favor de los Drivers ODBC y m\u00e1s en este caso, el sistema ODBC Adaptativo que incorpora funcionalidades muy superiores.\n\nEn caso de MySQL, tenemos el fichero cdr_mysql.conf, y para PostgreSQL, el fichero cdr_pgsql.conf, cuya configuraci\u00f3n de ambos se basa en un \u00fanico contexto <nowiki>[global]</nowiki> y dentro de este los siguientes par\u00e1metros espec\u00edficos:\n\n* '''hostname''': Direcci\u00f3n IP del servidor MySQL\n* '''dbname''': Nombre de la base de datos contenida en el servidor MySQL\n* '''table''': Nombre de la tabla a la que haremos referencia\n* '''user''': Usuario de la base de datos\n* '''password''': Contrase\u00f1a del usuario de la base de datos\n* '''port''': Puerto de la base de datos MySQL si es diferente al est\u00e1ndar 3306.\n\nPara el caso de las bases de datos, necesitaremos crear una tabla como la siguiente, donde se almacenar\u00e1 toda la informaci\u00f3n SQL:\n\n{{Database|cdr|CREATE TABLE cdr (<br>calldate datetime NOT NULL default '0000-00-00 00:00:00',<br>clid varchar(80) NOT NULL default <nowiki>''</nowiki>,<br>src varchar(80) NOT NULL default <nowiki>''</nowiki>,<br>\ndst varchar(80) NOT NULL default <nowiki>''</nowiki>,<br>dcontext varchar(80) NOT NULL default <nowiki>''</nowiki>, <br>channel varchar(80) NOT NULL default <nowiki>''</nowiki>,<br>dstchannel varchar(80) NOT NULL default <nowiki>''</nowiki>,<br> lastapp varchar(80) NOT NULL default <nowiki>''</nowiki>,<br>lastdata varchar(80) NOT NULL default <nowiki>''</nowiki>,<br>duration int(11) NOT NULL default '0',<br>billsec int(11) NOT NULL default '0',<br>disposition varchar(45) NOT NULL default <nowiki>''</nowiki>,<br>amaflags int(11) NOT NULL default '0',<br>accountcode varchar(20) NOT NULL default <nowiki>''</nowiki>,<br>uniqueid varchar(32) NOT NULL default <nowiki>''</nowiki>,<br>userfield varchar(255) NOT NULL default <nowiki>''</nowiki><br>);}}\n\nEsta estructura, tambi\u00e9n es valido para otros sistemas, como el Driver ODBC, en caso que sea la configuraci\u00f3n estandar y no vayamos a usar campos adicionales espec\u00edficos del sistema Adaptativo.\n\n==== Configuraci\u00f3n SQLite ====\n\nPor otro lado existe la posibilidad de almacenar en un sistema de Base de Datos m\u00e1s b\u00e1sico para m\u00e1quinas que no hacen un uso especialmente intensivo de este recurso, como es el caso de SQLite, un tipo de base de datos transaccional que esta basada en uno o varios ficheros localizados, y requiere un bajo nivel de configuraci\u00f3n (por no decir nulo). En contrapartida hay que saber que este tipo de Base de Datos es muy limitada (porque en esencia no deja de ser un \u00fanico fichero), y suele ser utilizada para instalaciones, literalmente, de andar por casa (de hecho por ejemplo uno de los sistemas que utilice una base de datos SQL es el sistema de almacenamiento online Dropbox <ref>[https://www.dropbox.com DropBox], Dropbox Inc.</ref> para el software que proporciona en el lado '''Cliente'''. Esto es importante, dado que aunque sea un sistema de base de datos como otros aqu\u00ed vistos es muy posible que si estemos haciendo un uso intensivo del mismo, tengamos la necesidad de cambiar lo antes posible\n\nLa ventaja es que en su fichero de configuraci\u00f3n '''cdr_sqlite3_custom.conf''' podemos especificar que campos vamos a registrar a voluntad, lo que podr\u00eda ser pr\u00e1ctico en caso que deseemos utilizar este sistema de base de datos para uno fin muy espec\u00edfico. Solamente es posible guardar un solo fichero llamado Master.db y una tabla contenida en el mismo en estos momentos.\n\nLa estructura de este fichero es muy b\u00e1sica:\n\nEn primer lugar definimos un \u00fanico contexto llamado <nowiki>[master] </nowiki>, y dentro de este, definimos los siguientes par\u00e1metros:\n* '''table => cdr''': ser\u00eda como queremos llamarle a la tabla, en este caso le llamaremos '''cdr'''\n* '''columns =>''': Las columnas soportadas, son: calldate, clid, dcontext, channel, dstchannel, lastapp, lastdata, duration, billsec, disposition, amaflags, accountcode, uniqueid, userfield, test\n* '''values =>''': Los valores registrados por defecto por la [[Funciones#CDR|Funci\u00f3n CDR]].\n\n== Sistema CEL ==\n\nSeg\u00fan visto anteriormente, CEL, Call Event Logging, es una evoluci\u00f3n de CDR, surgida a partir de la versi\u00f3n 1.8, dando aun superior soporte al anterior intento basado en el CDR Adaptativo, y dise\u00f1ada para poder tener control no solo de los pasos de la llamada, sino de los eventos a nivel interno que van surgiendo en el flujo de una llamada dentro de nuestro [[:Seccion:Dialplan|Plan de Marcaci\u00f3n]]. Es posible que el sistema CDR quede obsoleto con el tiempo en favor a CEL, dado que es capaz de recibir y manipular la misma cantidad de informaci\u00f3n que CDR, pero incluso con mayor detalle a voluntad, aunque el primero, podr\u00eda aun conservarse para sistemas que tampoco requieran un nivel de detalle tan excesivo, dada que su facilidad de interpretaci\u00f3n.\n\nLa estructura de almacenamiento es equivalente a la de CDR, con ficheros CSV, o con Bases de Datos. Hay que considerar la posible cantidad ingente de informacion que es capaz de almacenar CEL por tanto la versi\u00f3n en ficheros de texto puede ser bastante negativa y en la mayor parte de los casos que vayamos a hacer un uso aceptable (ni siquiera intensivo) del sistema, deber\u00edaos optar por la opci\u00f3n de registro en Bases de Datos.\n\nLos ficheros de configuraci\u00f3n est\u00e1ndar son:\n\n* Para ficheros de texto, ser\u00eda '''cel.conf''', aplicable tambi\u00e9n para el caso de registro de eventos a la interfaz [[AMI]] y para realizar la autentificaci\u00f3n a traves de un servidor RADIUS\n* Para el caso de bases de datos PostgreSQL, ser\u00eda '''cel_pgsql.conf'''.\n* En caso de querer utilizar la base de datos SQLite, '''cel_sqlite3_custom.conf''' (solo soporta la versi\u00f3n 3, excepto que posibles versiones superiores, fueran retrocompatibles)\n* Si queremos utilizar un driver ODBC, '''cel_odbc.conf''' opci\u00f3n m\u00e1s recomendada entre todas las posibles aqu\u00ed listadas.\n\nCuriosamente para MySQL no existe todav\u00eda una integraci\u00f3n especifica, lo que indica en gran medida dado que este sistema de registro de Eventos todav\u00eda no es tan popular, que se tenga previsto preservar la conexi\u00f3n con el driver ODBC que resulta m\u00e1s gen\u00e9rico.\n\nEn caso de CEL tambi\u00e9n podemos tener personalizaciones de eventos, al igual que con CDR Adaptativo, la funci\u00f3n que se encarga de esta cuesti\u00f3n ser\u00eda CELGenUserEvent\n\n\n== Referencias ==\n\n<references />\n\n== V\u00e9ase tambi\u00e9n ==\n\n* [[Asterisk Realtime]]\n* [[CDR-Stats]]\n\n== Enlaces Externos ==\n\n* [http://www.cdr-stats.org CDR-Stats] es una interfaz web para la gesti\u00f3n de CDR en Python.\n* [http://www.sqlite.org/ SQLite], p\u00e1gina oficial de este b\u00e1sico motor de Base de Datos\n\n[[Categor\u00eda:Avanzado\u200f\u200e]]"
}
]
},
"53": {
"pageid": 53,
"ns": 0,
"title": "SIP",
"revisions": [
{
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "Para definir y concretar acerca del protocolo SIP (Session Initiation Protocol, o Protocolo de Inicio de Sesi\u00f3nes), ser\u00eda viable dise\u00f1ar una Wiki espec\u00edfica 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 [http://www.kamailio.org Kamailio] y [http://www.opensips.org OpenSIPS], de hecho Digium difunde cursos espec\u00edficos sobre este protocolo para su m\u00e1ximo entendimiento y aprovechamiento.\n\nEn esta primera aproximaci\u00f3n, no vamos a tratar este protocolo con tanta profundidad como quiz\u00e1 exige, pero existe numerosa bibliograf\u00eda al respecto, y concretamente apunto a una por cercan\u00eda con respecto a la idea subyacente de este proyecto de AsteriskWIKI <ref>[https://forja.rediris.es/docman/view.php/555/853/Intro-voip-uca.pdf Introducci\u00f3n a la telefon\u00eda IP utilizando est\u00e1ndares.], Fabi\u00e1n Sell\u00e9s Rosa (2009), Proyecto Fin de Carrera Universidad de C\u00e1diz</ref>\n\n{{Centrar|{{#Widget:AdSense}}}}\n\n__TOC__ \n\nDigamos que la mayor parte de las conexiones que se realizan entre estaciones, pasarelas y dispositivos de telefon\u00eda IP en general, que no contienen Asterisk en esencia, con respecto a nuestra m\u00e1quina, est\u00e1n basadas en el protocolo SIP.\n\n== Conceptos B\u00e1sicos ==\n\nEs muy importante tener presentes algunos conceptos b\u00e1sicos 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\u00f3n, o incluso, de interconexi\u00f3n entre terminales de cualquier \u00edndole.\n\n=== Relaci\u00f3n entre SIP y Asterisk ===\n\nExiste una mala concepci\u00f3n sobre como funciona realmente el SIP porque es com\u00fan pensar que es encargado de llevar los datos multimedia, as\u00ed como los mensajes de sesi\u00f3n conjuntamente. Parte de esta afirmaci\u00f3n es cierta, concretamente la segunda parte, dado que este protocolo fue dise\u00f1ado exclusivamente como sistema de se\u00f1alizaci\u00f3n conjuntamente a otro flujo de datos multimedia a trav\u00e9s de un protocolo simult\u00e1neo (que en Asterisk ser\u00eda el protocolo RTP, Protocolo de Transporte en Tiempo Real, o Real-Time Tranport Protocol). Adem\u00e1s para \"complicar\" el concepto, durante la trasmisi\u00f3n tambi\u00e9n interviene un tercer protocolo \"familiar\" de SIP llamado SDP (Protocolo de Descripci\u00f3n de Sesiones, o Session Description Protocol), redactado en el RFC 4566 y embebido dentro del protocolo SIP por lo que no consumir\u00eda m\u00e1s recursos (por ejemplo Puertos a nivel TCP/IP), y se encargar\u00eda de enriquecer el mensaje entre sesiones necesario para la trasmisi\u00f3n eficaz entre los dispositivos.\n\nRealmente 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\u00eda en si, solo podr\u00eda considerarse un est\u00e1ndar cualquiera de entendimiento entre dispositivos, algo que realmente todav\u00eda no se ha asentado, ya que m\u00faltiples dispositivos, aun no siguen los est\u00e1ndares \"impuestos\" dentro de los RFC, ya que aun no ha madurado hasta la categor\u00eda de est\u00e1ndar IEEE.\n\nSIP se popularizo, debido que en el momento de la implementaci\u00f3n de servicios de telefon\u00eda IP, no exist\u00edan realmente grandes competidores en este aspecto. Adem\u00e1s la seguridad utilizando SIP no prima especialmente, debido a que la trasmisi\u00f3n se realiza con mensajes de texto, y para encriptar la informaci\u00f3n es fundamental recurrir a extensiones independientes que transforman los mensajes en ambos nodos.\n\nEn el a\u00f1o 2010 naci\u00f3 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\u00eda asentado sobre el protocolo SIP.\n\n=== Funcionamiento Esencial ===\n\n[[Image:flujo_sip_asterisk.png|thumb|Flujo Mensajes SIP<ref>[http://www.panoramisk.com/101/asterisk-and-voice-transport/en/ Flujo Mensajes SIP], Alexandre Chauvin-Hameau (2007)</ref>|right|200px]] \n\nSIP 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\u00f3n m\u00e1s com\u00fan y estandarizado es el 5060, y como coment\u00e1bamos con anterioridad, a trav\u00e9s del mismo, tambi\u00e9n se trasmiten los mensajes del protocolo SDP.\n\nPor otro lado, para trabajar con Audio en Asterisk tenemos que utilizar forzosamente el protocolo RTP para llevar el tr\u00e1fico. Para cada canal de audio es necesario trabajar con un puerto independiente, y esto acarreara a\u00fan mas problemas en la seguridad, o en la interoperatividad con nuestro sistema. Veremos soluciones m\u00e1s adelante para salir del paso, ninguna bajo mi criterio, especialmente excepcional.\n\nLos mensajes cl\u00e1sicos de SIP son los siguientes:\n\n* INVITE\n* REGISTER\n* ACK\n* BYE\n* OPTIONS\n\nEn la imagen, podemos ver un flujo cl\u00e1sico de mensajes entre un servidor Asterisk y dos tel\u00e9fonos conectados al mismo.\n\n=== Problemas derivados de SIP y Asterisk ===\n\nSiguiendo la linea, existen una serie de problemas que derivan del uso de SIP con nuestra m\u00e1quina Asterisk, cuando tratamos de acceder al exterior (concretamente a Internet), de manera bidireccional. Supongamos que tenemos un tel\u00e9fono conectado a nuestro servidor Asterisk, y a su vez, nuestro servidor Asterisk quiere comenzar a trasmitir datos con otro servidor SIP externo, o tambi\u00e9n la posibilidad que un tel\u00e9fono fuera de nuestra red local, desea conectar a nuestro servidor Asterisk y trasmitir audio bidireccion\u00e1lmente con uno de los tel\u00e9fonos ubicados dentro de la red y tambi\u00e9n conectado a este servidor en cuesti\u00f3n.\n\nNos vemos ante dos problemas con sus respectivas soluciones:\n\n* Problemas con el NAT\n* Problemas con los puertos\n\n==== Problemas con el NAT ====\n\nSi vivi\u00e9ramos en un mundo IPv6 esto eventualmente no suceder\u00eda, 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\u00famero excesivamente limitados de direcciones IPv4 nos encontramos ante el primer problema.\n\nTenemos un Router con conexi\u00f3n a internet, y asignada una direcci\u00f3n IP concreta. Dentro de la red local de ese router, nuestra m\u00e1quina posee una direcci\u00f3n local. En las cabeceras SIP al enviar el paquete de iniciaci\u00f3n de sesi\u00f3n a trav\u00e9s del router, el servidor remoto por defecto, registrar\u00eda nuestro equipo apuntando a la direcci\u00f3n local, y por consiguiente, no existir\u00eda una ruta de regreso para seguir la trasmisi\u00f3n de mensajes y que se complete la \"transacci\u00f3n\" adecuadamente.\n\nSi nuestro router posee funciones \"avanzadas\" para la gesti\u00f3n del nat, si en nuestra configuraci\u00f3n de Asterisk, en el fichero de configuraci\u00f3n del protocolo SIP marcamos que nos debemos registrar activando una propiedad especifica (nat=yes), Asterisk implementar\u00eda una funci\u00f3n exclusiva para resolver este problema forzando el comportamiento descrito en el RFC 3581 y adicionalmente, habilitando el soporte para el RTP Sim\u00e9trico, aparte que es fundamental que el router posea capacidades de NAT Transveral e implemente los correspondientes ALG <ref>[http://www.voip-info.org/wiki/view/Asterisk+sip+nat Articulo sobre la funcion nat de SIP], Olle E. Johansson (Septiembre 2003)</ref> \n\n==== Problemas con los puertos ====\n\nEste es el escenario m\u00e1s cl\u00e1sico perpetuado por el uso del protocolo RTP, el cual utiliza puertos aleatorios y muy dif\u00edcilmente controlables (o al menos todo intento de control provoca en \u00faltima instancia fallos en la comunicaci\u00f3n debidos a su relativa aleatoriedad).\n\nPor un lado, nos encontramos lo cl\u00e1sico: necesitamos abrir puertos en nuestro Cortafuegos para permitir el paso de datos por uno o varios determinado en concreto.\n\nPara 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\u00edamos 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\u00e9fonos, descolgamos y nos damos cuenta de pronto que no hay voz. Los datos RTP estan siendo bloqueados en el Cortafuegos. La pregunta es \u00bfque puerto debemos desbloquear ahora para permitir el paso?\n\nExisten tres formas de plante\u00e1rselo:\n\n* Abrir todos los puertos necesarios seg\u00fan configuraci\u00f3n en el fichero correspondiente (rtp.conf). A nivel de seguridad es una idea nefasta.\n* Utilizar un servidor VPN (Virtual Private Network) al que conectar\u00eda nuestro dispositivo remoto, y una vez dentro, ya se establecer\u00eda la conexi\u00f3n como si formara parte de la red local. La inconveniencia principal esta basada en cuestiones de rendimiento, aunque resulta relativamente popular.\n* Trabajar con un servidor STUN RFC 3489. Esta soluci\u00f3n es quiz\u00e1 la mas compleja y existen m\u00faltiples fuentes de documentaci\u00f3n que tratan espec\u00edficamente sobre ella.<ref>[http://www.astricon.net/2008/glendale/web/presentations/astricon-stun-turn-ice_SPerreault.pdf Presentaci\u00f3n sobre STUN], Simon Perreault, Viagenie (Astricon, 2008)</ref> \n\nAdem\u00e1s para mantener los puertos abiertos, y haciendo uso del mensaje OPTIONS de SIP, desde la configuraci\u00f3n sip.conf podemos forzarlo a trav\u00e9s de un par\u00e1metro \"multiproposito\" ('''qualify=yes''') que realmente se encarga de informar sobre los dispositivos conectados al sistema, entre otros aspectos, su estado, tiempo de respuesta, etc.\n\n== Par\u00e1metros de Configuraci\u00f3n ==\n\nLa relaci\u00f3n entre el protocolo SIP y Asterisk se establece a traves del fichero de configuraci\u00f3n sip.conf dentro del directorio de configuraciones por defecto /etc/asterisk\n\nLa estructura del fichero se categoriza por secciones delimitadas por corchetes. La secci\u00f3n gen\u00e9rica 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\u00e9fonos IP, softphones, proveedores VoIP, pasarelas ATA, etc) y pueden tener nombres gen\u00e9ricos. Un ejemplo de estructura:\n\n{{ Archivo| /etc/asterisk/sip.conf| [general]<br>\n...<br><br> [proveedorvoip] <br>...<br><br> [telefonooficina]<br> ... }}\n\n=== Configuraci\u00f3n General ===\n\nLa mayor parte de los par\u00e1metros pueden englobarse en la secci\u00f3n general, y servir\u00edan como par\u00e1metros por defecto aplicables tanto al protocolo SIP como a lo pares de telefon\u00eda IP concretos que definamos a continuaci\u00f3n (excepto a los valores de autentificaci\u00f3n con los mismos como es obvio).\n\nAlguno de los par\u00e1metros mas comunes podr\u00edan ser los siguientes:\n\n* '''bindport''': Aqui podemos especificar el puerto especifico al que escuchara nuestra m\u00e1quina Asterisk para conexiones SIP (puerto UDP), por defecto el 5060.\n* '''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\u00f3n IP concreta, para que se incluya en las cabeceras SIP, y as\u00ed poder evitar una parte del problema de trabajar con NAT (con la opci\u00f3n nat=yes que veremos mas adelante).\n* '''allowguest''': Permitimos llamadas de invitados, lo recomendable seria ponerlo \"allowguest = no\" por motivos de seguridad \n* '''realm''': Dominio de autentificaci\u00f3n, 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\"\n* '''allow/disallow''': Esta opci\u00f3n es aplicable tanto a los pares como a modo general. Ser\u00edan 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\u00f3n \"disallow = all\". Podemos encontrar mas informaci\u00f3n sobre [[Codecs y Formatos|Codecs]]\n* '''rtcachefriends''': Si trabajamos con [[Asterisk Realtime]] para configurar SIP (tabla sippeers) ser\u00eda un m\u00e9todo de cachear a los pares, para no tener que estar haciendo consultas SQL constantemente.\n* '''context''': El contexto por defecto al que enviaremos las llamadas dentro del [[Seccion:Dialplan|Plan de Marcaci\u00f3n]]. En este caso es default, y ser\u00eda conveniente o definirlo en el fichero de configuraci\u00f3n del Plan de Marcaci\u00f3n para evitar sorpresas, o cambiarlo a un contexto ya definido y que tengamos controlado.\n* '''language''': El lenguaje utilizado por defecto en el caso que utilicemos Aplicaciones para reproducir un mensaje de audio.\n* '''srvlookup''': Existe una cuesti\u00f3n que trataremos a continuaci\u00f3n acerca del \"emparejamiento\" de cabeceras SIP con nuestros correspondientes pares dentro del fichero de configuraci\u00f3n. En el caso que queramos (intentar) este emparejamiento, utilizando los nombres de host en vez de las direcciones IP, seria conveniente activar este par\u00e1metro (srvlookup = yes). Pero al depender de \"terceros\" (b\u00fasqueda por DNS SRV), resulta un tanto aleatoria la posibilidad que este par\u00e1metro llego a aportar algo verdaderamente de valor)\n* '''relaxdtmf''': Sirve para que los tonos no sean tan \"estrictos\", especialmente pr\u00e1ctico para llamadas de baja calidad, pero puede probar que se reconozcan tonos incorrectos en contrapartida.\n\n=== Conexi\u00f3n Multimedia Directa entre Terminales ===\n\nPor regla general, el escenario m\u00e1s com\u00fan es la trasmisi\u00f3n de todo el trafico, tanto SIP/SDP como RTP, a trav\u00e9s del servidor Asterisk, y a los terminales o dispositivos involucrados en el proceso. O en la otra parte, tambi\u00e9n existe el escenario de dos terminales que aceptan el protocolo SIP trasmiti\u00e9ndose toda la informaci\u00f3n directamente entre los mismos.\n\nPero existe un escenario, muy especifico, en el que los mensajes SIP/SDP pasan a traves de la m\u00e1quina Asterisk, pero el trafico RTP va directo entre los terminales. Para ello existe un par\u00e1metro concreto en archivo de configuraci\u00f3n sip.conf, llamado '''directmedia=yes''' gracias al cual, podr\u00edamos resultar en este escenario concreto.\n\nSurgir\u00edan ciertas inconveniencias (o ventajas si es lo que vamos buscando), por ejemplo, el hecho que al no pasar los medios a trav\u00e9s de nuestra m\u00e1quina Asterisk, funcionalidades que aportan determinados m\u00f3dulos (aplicaciones concretamente), como la grabaci\u00f3n o escucha de llamadas en tiempo realidad, quedar\u00edan inutilizados dado que ese tr\u00e1fico estar\u00eda fuera del alcance de nuestro sistema.\n\nAdem\u00e1s con que uno de los pares, no utilice el mismo c\u00f3dec de trasmisi\u00f3n, al ser forzosa la transcodificaci\u00f3n en tiempo real, Asterisk tomar\u00eda el control por defecto y no se dar\u00eda la conexi\u00f3n directa.\n\n=== Tipos de Pares ===\n\nExisten tres tipos de Pares dentro de la configuraci\u00f3n SIP, considerando estos, como todo elemento que opera a trav\u00e9s del protocolo SIP de comunicaciones. Aqu\u00ed hablamos principalmente de:\n\n* Operadores (S)IP\n* Tel\u00e9fonos (S)IP (tambi\u00e9n llamados Hardphones)\n* Software de telefon\u00eda (S)IP (tambi\u00e9n llamado Softphone)\n* Pasarelas ATA, dispositivos que a trav\u00e9s del protocolo SIP, entrelazan un sistema Asterisk, con la PSTN\n\n==== Peer ====\n\nCuando conectamos un elemento SIP con el tipo Peer, estamos considerando que se trata de un punto, por el cual tendremos intenci\u00f3n de cursar llamadas, es decir, acceder a su Plan de Marcaci\u00f3n, pero que esto no podr\u00e1 producirse a la inversa. Este tipo de configuraci\u00f3n es muy t\u00edpica, cuando nos conectamos a Operadores IP que nos ofrecen servicios de llamadas a trav\u00e9s de Internet, o incluso cuando nuestra m\u00e1quina Asterisk depende de una m\u00e1quina \"superior\" que act\u00faa como Operador para la nuestra. Para nosotros, marcas de telecomunicaciones reconocidas, podr\u00edan considerarse Peers.\n\n==== User ====\n\nEn 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\u00edamos como \"User\" a esas m\u00e1quinas Asterisk para que puedan acceder a nuestro Dialplan (obviamente, aportando de forma adicional un sistema de autentificaci\u00f3n como veremos mas adelante). En este sentido, al nosotros ser Operadores, es muy probable que no necesitemos cursar llamadas a trav\u00e9s de todos los usuarios que se conectan a nuestra m\u00e1quina ya que simplemente ofrecemos el servicio, no lo recibimos. Este tipo de configuraci\u00f3n es muy poco com\u00fan y tender\u00e1 a desaparecer en futuras versiones para dar paso a Friend en contrapartida que es m\u00e1s consistente.\n\n==== Friend ====\n\nEste t\u00e9rmino se usa para designar a una conexi\u00f3n bidireccional. Ser\u00eda la combinaci\u00f3n de un User y un Peer. El caso m\u00e1s t\u00edpico, ser\u00eda el de un tel\u00e9fono como extensi\u00f3n dentro de nuestro servidor. Pero tambi\u00e9n podr\u00eda ser com\u00fan en la conexi\u00f3n bidireccional, con una pasarela ATA, que no solo cumple la funci\u00f3n de emitir llamadas, sino que a trav\u00e9s de un n\u00famero DDI (Direct Dial-In, algo as\u00ed como un n\u00famero de marcaci\u00f3n Directa), ofrecido por nuestra operadora, tambi\u00e9n estar\u00edamos accesibles para recibir llamadas hasta nuestra m\u00e1quina. De hecho ciertos operadores IP ofrecen ambos servicios as\u00ed que podr\u00edamos \"otorgarles\" esta comunicaci\u00f3n bidireccional.\n\n=== Configuraci\u00f3n Espec\u00edfica de los Pares ===\n\nMuchos de los par\u00e1metros generales pueden considerarse como espec\u00edficos para un elemento que opera con SIP concreto tenga una propiedad diferente, que el resto que utilizase la configuraci\u00f3n general. Lo \u00fanico especial a tener en consideraci\u00f3n 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\u00f3n de la extensi\u00f3n), es exactamente el nombre de usuario (username) con el que se autentificara el dispositivo al conectar a nuestra m\u00e1quina. Para el caso de los tipo peers, este dato es meramente informativo, ya que para la autentificaci\u00f3n necesitaremos enviar un mensaje REGISTER concreto, como veremos m\u00e1s adelante.\n\nA continuaci\u00f3n los par\u00e1metros m\u00e1s populares:\n\n* '''allow/disallow''': Mismo uso que en el caso general, pero espec\u00edficamente para un par en concreto. Podemos encontrar m\u00e1s informaci\u00f3n sobre [[Codecs y Formatos|Codecs]]\n* '''defaultuser''': Una forma de redefinir el usuario de autentificaci\u00f3n, en caso que no queramos utilizar el nombre del dispositivo que se encuentra entre corchetes como comentabamos antes.\n* '''callerid''': Sirve para que nuestro destinatario vea un \"Identificador\" de llamada especifico cuando llamemos desde este dispositivo\n* '''busylevel''': Si queremos limitar el numero de llamadas entrantes que puede recibir nuestro dispositivo hasta que de la se\u00f1al de \"COMUNICANDO\".\n* '''call-limit''': Numero m\u00e1ximo de llamadas que podemos cursar simult\u00e1neamente a trav\u00e9s de este dispositivo.\n* '''context''': Mismo uso que el caso general, especifico para el dispositivo en cuesti\u00f3n.\n* '''dtmfmode''': Hace referencia al modo [[DTMF]] que queremos utilizar para este dispositivo en concreto. Las opciones son \"inband\",\"rfc2833\",\"info\".\n* '''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.\n* '''host''': Aqui especificamos la direcci\u00f3n a la que nos conectamos si es un peer, en caso de ser un friend/user, podr\u00edamos especificar la opci\u00f3n \"dynamic\" y dejar abierta la posibilidad que cualquier dispositivo se conecte a nuestra m\u00e1quina sin una IP en concreto.\n* '''insecure''': La misma palabra habla sobre niveles de seguridad en la comunicaci\u00f3n. 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\u00f3n y comprobaci\u00f3n que se establece entre las m\u00e1quinas a la hora de realizar la comunicaci\u00f3n.\n* '''port''': Si el dipositivo utiliza un puerto diferente al 5060 habr\u00eda que especificarlo aqui.\n* '''qualify''': Utilizando el mensaje SIP, OPTIONS, comprueba si el dispositivo es alcanzable, y mide el tiempo de respuesta en el momento del chequeo.\n* '''permit/deny''': M\u00e1s opciones de seguridad, sirve para restringir las redes y mascaras de subred de las cuales dispositivos en las mismas puedan conectar a nuestra m\u00e1quina. Un ejemplo podria ser '''permit = 192.168.1.0/255.255.255.0''' permitir\u00eda solo conexiones de dispositivos entrantes cuya IP pertenezca a esta subred. Amplio en [[Seguridad]].\n* '''mailbox''': Si deseamos asociar un Buz\u00f3n de Voz a un par concreto lo haremos a trav\u00e9s de este par\u00e1metro. Por ejemplo 100@ventas asociar\u00eda el buz\u00f3n numero 100 dentro del contexto ventas (esto es aplicable al fichero de configuraci\u00f3n voicemail.conf que podremos ampliar en [[Buzones de Voz]].\n* '''secret''': La contrase\u00f1a de autentificaci\u00f3n en formato texto plano. Es altamente insegura por motivos evidentes (recordando que SIP env\u00eda mensajes de texto durante su comunicaci\u00f3n). En caso de ser un proveedor, ya que contra nosotros se efect\u00faa la autentificaci\u00f3n no resultar\u00eda tanta inconveniencia (excepto por la inseguridad ante los accesos a nivel f\u00edsico/sistema operativo)\n* '''md5secret''': En un intento de aportar algo mas de seguridad al sistema es posible definir esta contrase\u00f1a en vez de la ofrecida por \"secret\". El metodo de construcci\u00f3n es a traves un MD5-Hash cuya base es la siguiente: <usuario>:<dominio>:<contrase\u00f1a>. El \"usuario\" ser\u00eda el mismo que el puesto entre corchetes como nombre del par, el \"dominio\" por defecto ser\u00eda asterisk o el especificado en el parametro \"realm\" como vimos en los Par\u00e1metros Generales. Y la \"contrase\u00f1a\" seria a voluntad. Ejemplo: '''100:asterisk:1234'''\n* '''nat''': Haciendo referencia al apartado anterior que comentabamos acerca del problema con los NAT, este par\u00e1metro es el encargado de intentar resolverlo. Existen varias posibilidades adicionales aparte de \"yes|no\". Considerando que \"yes\" significa aplicar el modo COmedia <ref>[http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/sip_cg-com_fork_mlpp.html Connection-Oriented Media Enhancements], Cisco Systems (2002)</ref> y las capacidades de crear una conexi\u00f3n 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\u00e9todo RFC 3581, y deshabilita la conexi\u00f3n RTP simetrica, y finalmente \"comedia\" ser\u00eda equivalente a utilizar \"yes\", pero contando exclusivamente que el otro par solicite voluntariamente la posibilidad de aplicar el m\u00e9todo COmedia.\n* '''type''': Justamente es el tipo de par que comentabamos en el apartado anterior, las posibilidades, \"user\", \"peer\" y \"friend\".\n\n=== Nombrando los Pares ===\n\nPartiendo de la base que en Asterisk, una extensi\u00f3n no tiene que estar necesariamente asociada a un dispositivo, por ejemplo a un par podr\u00edamos llamarle \"telefono-ventas\" y ponerle la extensi\u00f3n 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 [[:Seccion:Dialplan|DialPlan]] si queremos hacer que suene este tel\u00e9fono, lo har\u00edamos con la aplicaci\u00f3n especifica de Marcado ([[Aplicaciones B\u00e1sicas|Dial]]) seguido del '''Nombre''' del par SIP y no del numero de extensi\u00f3n. Esto es mas facil verlo en la pr\u00e1ctica en el apartado antes se\u00f1alado.\n\nPero saliendo de este concepto, hay un tema que resulta relativamente interesante desde el punto que concierne a la creaci\u00f3n de una estructura de extensiones, f\u00e1cilmente 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\u00edamos que elegir un sistema que fuera lo suficientemente compensado. Diversos autores ponen en com\u00fan el mismo sistema: Nombrar las dispositivos por su direcci\u00f3n MAC. \n\nPlante\u00e1ndolo:\n\n* Si elegimos nombrar por numero de extensi\u00f3n del plan de marcaci\u00f3n, nos encontramos ante el dilema, que si cambiamos la extensi\u00f3n en el [[:Seccion:Dialplan|DialPlan]] entonces tambi\u00e9n tenemos que hacerlo en el archivo de configuraci\u00f3n SIP para seguir preservando este sistema. Si no somos rigurosos, con el tiempo es un autentico desastre (la extensi\u00f3n 200 llama al dispositivo 205, y la extensi\u00f3n 210 llama al dispositivo 203, no tiene ning\u00fan sentido).\n\n* Si elegimos nombrar por un dato significativo con respecto al tel\u00e9fono, 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\u00edamos que cambiarle el nombre del dispositivo. Partiendo por la base de la capacidad de \"abstracci\u00f3n\" extensi\u00f3n-nombre de peer-usuario nos encontramos entre dos aguas, designando un puesto, y a la vez un usuario.\n\n* En caso de elegir nombrar con un nombre de usuario, ser\u00eda una buena idea, en el caso que lo que estemos buscando es \"portabilidad\" de la extensi\u00f3n para un determinado usuario. En este caso por ejemplo, si el usuario '''harrysmith''' desea que en el tel\u00e9fono de ventas entren sus llamadas, acceder\u00eda a la configuraci\u00f3n del mismo, y configurar\u00eda el dispositivo con sus credenciales. Lo mismo ocurre para otros dispositivos como softphones. El problema entra\u00f1a la seguridad dado que por regla general al poder acceder a la configuraci\u00f3n de los tel\u00e9fonos tambi\u00e9n tiene capacidad de acceder a otros datos que eventualmente podr\u00eda interesarnos limitar su acceso.\n\n* Para el caso este, definir\u00edamos entonces dispositivos como elementos est\u00e1ticos, en los que no hay usuarios entrando y saliendo con sus respectivas credenciales. Descartando entonces las anteriores alternativas, surgir\u00eda la comentada al principio como m\u00e1s popular, nombrarlos por la direcci\u00f3n MAC (o al menos los \u00faltimos pongamos, 8 valores).\n\nDe todas formas, para organizaciones relativamente peque\u00f1as, con menos de 50 extensiones, todo esto realmente no cobra una importancia especialmente desmedida, y quiz\u00e1 la primera opci\u00f3n podr\u00eda considerarse la m\u00e1s vers\u00e1til.\n\n=== Sistema de Emparejamiento de Pares ===\n\nCuando recibimos un mensaje SIP en nuestra m\u00e1quina, 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\u00f3n '''\"To:\"''' o '''\"From:'''.\n\nPara ello Asterisk utiliza un sistema llamado \"Peer Matching\" que opera de la siguiente forma:\n\n==== Caso Peer ====\n\nEn el caso de ser un tipo Peer al que evidentemente nosotros conectamos, se busca por que coincida la direcci\u00f3n IP y el puerto. El \u00fanico problema que podemos encontrar aqu\u00ed 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\u00fan encontrar problemas ya que no solo dependemos de software diferente a Asterisk, sino tambi\u00e9n de que los servidores de nombres externos hagan bien su papel durante la comunicaci\u00f3n.\n\nEs muy com\u00fan ver m\u00faltiples 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\u00e9todo 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.\n\n==== Caso User ====\n\nEn este caso, busca en el '''From: ''' el nombre de usuario (puede ser por ejemplo, un n\u00famero de marcaci\u00f3n directa, DDI), y lo asocia al nombre de usuario del peer en cuesti\u00f3n.\n\n==== Caso Friend ====\n\nSer\u00eda una combinaci\u00f3n de ambas. Pero como este tipo de configuraci\u00f3n es muy cl\u00e1sica en Tel\u00e9fonos 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\u00e9s 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\u00eda realizar a nivel de direcci\u00f3n IP cuando se efect\u00faa la conexi\u00f3n remota y en el \"regreso\" a nuestra central, el emparejamiento se realizar\u00eda a nivel de nombre de usuario.\n\n=== Plantillas de Configuraci\u00f3n de Pares ===\n\nDado que es muy com\u00fan tener m\u00faltiples dispositivos compartiendo pr\u00e1cticamente la misma informaci\u00f3n relativa a los Par\u00e1metros Espec\u00edficos excepto quiz\u00e1, el nombre de usuario que se define entre corchetes, el buz\u00f3n de voz asociado, y la contrase\u00f1a, el resto de los par\u00e1metros pueden englobarse en un Meta-Dispositivo tipo Plantilla y luego aplicar la misma en los pares que compartan la misma informaci\u00f3n.\n\nEl par tipo plantilla se establece poniendo el s\u00edmbolo (!) justo detr\u00e1s del nombre de usuario entre corchetes. Y luego se aplica a los sucesivos dispositivos, poniendo justo despu\u00e9s del nombre de usuario o contexto, el nombre de la plantilla entre par\u00e9ntesis.\n\nUn sencillo archivo de configuraci\u00f3n de ejemplo, aplicando plantillas:\n\n{{Archivo|/etc/asterisk/sip.conf|[moviles](!)<br>nat=yes<br>disallow=all<br>allow=ulaw<br>\n[100](moviles)<br>secret=1234<br>\n[101](moviles)<br>secret=5678<br>\n[102](moviles)<br>secret=9012}}\n\nDe esta forma reducimos la cantidad de datos en el archivo de configuraci\u00f3n de forma muy considerable.\n\n== Referencias ==\n\n<references />\n\n== V\u00e9ase tambi\u00e9n ==\n\n* [[Seguridad]]\n\n== Enlaces Externos ==\n\n* [http://www.kamailio.org Kamailio] y [http://www.opensips.org OpenSIPS] los dos SIP Proxy m\u00e1s populares.\n* [http://www.boizu.com Llamadas Gratis Internacionales Online] \n\n[[Category:General]]"
}
]
}
}
}
}