IAX - Historial de revisiones

SirLouen en 16:43 6 jul 2014

2014-07-06T16:43:06Z

SirLouen: /* Acceso a Invitados */

2012-05-22T20:13:25Z

Acceso a Invitados

SirLouen en 20:10 22 may 2012

2012-05-22T20:10:54Z

SirLouen: /* Funcionamiento Esencial */

2012-05-22T20:06:40Z

Funcionamiento Esencial

SirLouen en 19:58 22 may 2012

2012-05-22T19:58:31Z

SirLouen: /* Configuración General */

2012-05-22T19:28:01Z

Configuración General

SirLouen: /* Configuración General */

2012-05-22T19:15:16Z

Configuración General

SirLouen: /* Parámetros de Configuración */

2012-05-22T19:04:53Z

Parámetros de Configuración

SirLouen en 18:25 22 may 2012

2012-05-22T18:25:01Z

SirLouen en 17:42 22 may 2012

2012-05-22T17:42:06Z

← Revisión anterior		Revisión del 16:43 6 jul 2014
Línea 1:		Línea 1:
	El protocolo IAX fue diseñado para Asterisk por su mismo creador [http://en.wikipedia.org/wiki/Mark_Spencer_%28computer_engineer%29 Mark Spencer] (de ahí recibe sus siglas, Inter Asterisk eXchange, Intercambio entre Asterisk) para suplir múltiples desventajas que el protocolo SIP ofrecía en aquel momento, y que por su naturaleza original, sigue teniendo. Realmente IAX se refiere a IAX2, la segunda versión de este protocolo, dado que el primero fue reemplazado por este. IAX2 está descrito en profundidad en el RFC 5456.		El protocolo IAX fue diseñado para Asterisk por su mismo creador [http://en.wikipedia.org/wiki/Mark_Spencer_%28computer_engineer%29 Mark Spencer] (de ahí recibe sus siglas, Inter Asterisk eXchange, Intercambio entre Asterisk) para suplir múltiples desventajas que el protocolo SIP ofrecía en aquel momento, y que por su naturaleza original, sigue teniendo. Realmente IAX se refiere a IAX2, la segunda versión de este protocolo, dado que el primero fue reemplazado por este. IAX2 está descrito en profundidad en el RFC 5456.
		+
		+	{{Centrar\|{{#Widget:AdSense}}}}

	__TOC__		__TOC__

@@ Línea 124: / Línea 124: @@
 Para poder permitir el acceso a los mismos es necesario eliminar el hecho de la obligatoriedad en la solicitud del Token de Llamada puesto que no se realizaría ninguna autentificación realmente. Además como comentado en el apartado de [[Seguridad]] puede resultar verdaderamente importante limitar el parámetro '''maxcallnumbers_nonvalidated''' a límites que sepamos que nuestra máquina puede controlar, dado que esta libertad de acceso puede suponer un grave contratiempo si no esta bien controlado. Un ejemplo de configuración de un fichero IAX con posibilidades limitadas de acceso a Invitados podría ser así (en formato muy simplificado pero funcional):
-{{Archivo|/etc/asterisk/iax.conf|[general]<br>maxcallnumbers_nonvalidated &#61; 2048<br><br>[guest]<br>type &#61; user<br>requirecalltoken &#61; no}}
+{{Archivo|/etc/asterisk/iax.conf|[general]<br>maxcallnumbers_nonvalidated &#61; 2048<br><br>[guest]<br>type &#61; user<br>requirecalltoken &#61; no<br>context &#61; invitados}}
 == Referencias ==

← Revisión anterior		Revisión del 20:10 22 may 2012
Línea 117:		Línea 117:

	Además también como es posible contemplar en el el protocolo [[SIP]] acerca del [[SIP#Plantillas_de_Configuración_de_Pares\|uso de plantillas]] para configurar múltiples pares de forma más genérica, también es posible, pero ocurre lo mismo, no es algo extendido dado que es muy típico ver ficheros iax.conf, con apenas muy pocos pares configurados (otras máquinas Asterisk que se entrelazan).		Además también como es posible contemplar en el el protocolo [[SIP]] acerca del [[SIP#Plantillas_de_Configuración_de_Pares\|uso de plantillas]] para configurar múltiples pares de forma más genérica, también es posible, pero ocurre lo mismo, no es algo extendido dado que es muy típico ver ficheros iax.conf, con apenas muy pocos pares configurados (otras máquinas Asterisk que se entrelazan).
		+
		+	=== Acceso a Invitados ===
		+
		+	Esta parte forma realmente una sección de [[Seguridad]], pero realmente no deja de ser una funcionalidad más del protocolo IAX
		+
		+	Para poder permitir el acceso a los mismos es necesario eliminar el hecho de la obligatoriedad en la solicitud del Token de Llamada puesto que no se realizaría ninguna autentificación realmente. Además como comentado en el apartado de [[Seguridad]] puede resultar verdaderamente importante limitar el parámetro '''maxcallnumbers_nonvalidated''' a límites que sepamos que nuestra máquina puede controlar, dado que esta libertad de acceso puede suponer un grave contratiempo si no esta bien controlado. Un ejemplo de configuración de un fichero IAX con posibilidades limitadas de acceso a Invitados podría ser así (en formato muy simplificado pero funcional):
		+
		+	{{Archivo\|/etc/asterisk/iax.conf\|[general]<br>maxcallnumbers_nonvalidated = 2048<br><br>[guest]<br>type = user<br>requirecalltoken = no}}

	== Referencias ==		== Referencias ==

@@ Línea 26: / Línea 26: @@
 * MEDIA (este aporta ese aspecto especifico)
 * HANGUP
 [[Image:flujo_IAX_asterisk.png|thumb|Flujo Mensajes IAX<ref>[http://www.voipthink.com/IAX/IAX-example-messages.php Flujo Mensajes IAX], VoipThink, IAX communication example- messages (2010)</ref>|right|200px]]

@@ Línea 1: / Línea 1: @@
 El protocolo IAX fue diseñado para Asterisk por su mismo creador [http://en.wikipedia.org/wiki/Mark_Spencer_%28computer_engineer%29 Mark Spencer] (de ahí recibe sus siglas, Inter Asterisk eXchange, Intercambio entre Asterisk) para suplir múltiples desventajas que el protocolo SIP ofrecía en aquel momento, y que por su naturaleza original, sigue teniendo. Realmente IAX se refiere a IAX2, la segunda versión de este protocolo, dado que el primero fue reemplazado por este. IAX2 está descrito en profundidad en el RFC 5456.
@@ Línea 50: / Línea 47: @@
 Por un lado, hay que considerar que las primeras versiones de IAX, eran algo inseguras, y estaban excesivamente expuestas a los ataques de denegación del servicio (DDoS). Por ello las medidas más clásicamente utilizadas para mitigar este problema, era simplemente, limitar el número de llamadas máximo por cada host que conectase vía IAX a nuestra máquina. Por otro lado, con las versiones mas recientes de IAX2, surgió la idea de utilizar un Token de autentificación para garantizar un paso menos en la posibilidad de ver sufrir nuestra máquina ataques DDoS por máquinas sin autentificar.
-En el caso de requerir por cualquier motivo, el acceso a visitantes (guest) sin autentificar, nuestra máquina quedaría bastante expuesta, pero las últimas revisiones del protocolo protegen aún más ante este problema. En términos generales podemos decir que ha existido demasiada fragmentación de este protocolo surgida a raiz de las diversas actualizaciones del mismo. Pero eventualmente si trabajamos con máquinas de la misma índole (principalmente hablando de máquinas Asterisk, con similares, versiones, etc), la seguridad en este sentido esta bastante mas garantizada que con otros protocolos como [[SIP]], donde los ataques DDoS, por ejemplo, con envíos masivos de mensajes INVITE, suelen ser más comunes.
+En el caso de requerir por cualquier motivo, el acceso a visitantes (guest) sin autentificar, nuestra máquina quedaría bastante expuesta, pero las últimas revisiones del protocolo protegen aún más ante este problema. En términos generales podemos decir que ha existido demasiada fragmentación de este protocolo surgida a raíz de las diversas actualizaciones del mismo. Pero eventualmente si trabajamos con máquinas de la misma índole (principalmente hablando de máquinas Asterisk, con similares, versiones, etc), la seguridad en este sentido esta bastante mas garantizada que con otros protocolos como [[SIP]], donde los ataques DDoS, por ejemplo, con envíos masivos de mensajes INVITE, suelen ser más comunes.
-El segundo problema, surge a raíz de la extensibilidad del protocolo. Este tema esta más que discutido, ya que al ser un protocolo libre, es relativamente accesible su modificación (aun más difícil la actualización del borrador en el RFC del momento. En la actualidad cubre con creces su función, pero, el temor que en un futuro surjan nuevas necesidades, quiza relativas a nuevos medios que requieran mensajes específicos, y siempre comparativamente hablando con los protocolos genéricos SIP, MGCP, etc que se adaptan prácticamente a cualquier protocolo "Out of the Band" (fuera de la banda, que trabaja independientemente al protocolo en si). Para otro bando esto último podría incluso representar, más una inconveniencia que una ventaja pero ahí surge un poco el debate ante esta debilidad.
+El segundo problema, surge a raíz de la extensibilidad del protocolo. Este tema esta más que discutido, ya que al ser un protocolo libre, es relativamente accesible su modificación (aun más difícil la actualización del borrador en el RFC del momento. En la actualidad cubre con creces su función, pero, el temor que en un futuro surjan nuevas necesidades, quizá relativas a nuevos medios que requieran mensajes específicos, y siempre comparativamente hablando con los protocolos genéricos SIP, MGCP, etc que se adaptan prácticamente a cualquier protocolo "Out of the Band" (fuera de la banda, que trabaja independientemente al protocolo en si). Para otro bando esto último podría incluso representar, más una inconveniencia que una ventaja pero ahí surge un poco el debate ante esta debilidad.
 == Parámetros de Configuración ==
-Muy parecido al protocolo [[SIP]] que suele servir de referencia a la hora de configurar el protocolo IAX, muchos de los parametros de configuración general son compartidos. Si sabemos configurar el fichero de configuración del otro protocolo, no tendremos mucha dificultad para configurar este.
+Muy parecido al protocolo [[SIP]] que suele servir de referencia a la hora de configurar el protocolo IAX, muchos de los parámetros de configuración general son compartidos. Si sabemos configurar el fichero de configuración del otro protocolo, no tendremos mucha dificultad para configurar este.
 Hay que considerar que el fichero de configuración especifico esta contenido por regla general en el directorio '''/etc/asterisk/''' y concretamente se trata del '''iax.conf'''.
@@ Línea 62: / Línea 59: @@
 === Configuración General ===
-Dentro del contexto <nowiki>[general]</nowiki> podemos utilizar los siguientes argumentos:
+Dentro del contexto <nowiki>[general]</nowiki> podemos utilizar los siguientes argumentos comunes:
 * '''bindport''': Aqui podemos especificar el puerto especifico al que escuchara nuestra máquina Asterisk para conexiones IAX (puerto UDP), por defecto el 4569.
@@ Línea 70: / Línea 67: @@
 * '''context''': El contexto por defecto al que enviaremos las llamadas dentro del [[Seccion:Dialplan|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.
 * '''encryption''': Permite encriptar la información trasmitida a traves del protocolo IAX. Muy útil como medida de [[Seguridad]] para el sistema.
 * '''transfer''': Ofrece la posibilidad de intercomunicar dos dispositivos IAX sin pasar por la máquina Asterisk
@@ Línea 83: / Línea 83: @@
 Todos los parámetros de seguridad relacionados a los "Call Token" y la concurrencia en llamadas, la debilidad del Protocolo IAX, podemos verlos en el apartado de [[Seguridad]]
 == Referencias ==

@@ Línea 82: / Línea 82: @@
 * '''jitterbuffer''': Creamos un Buffer para mejorar el Jitter de la conversación. En el caso que los dos pares utilicen la funcionalidad de trunking, es fundamental que la opción trunktimestamps este habilitada en ambos sentidos.
-Todos los parámetros de seguridad relacionados a los "Call Token", la debilidad del Protocolo IAX, podemos verlos en el apartado de [[Seguridad]]
+Todos los parámetros de seguridad relacionados a los "Call Token" y la concurrencia en llamadas, la debilidad del Protocolo IAX, podemos verlos en el apartado de [[Seguridad]]
 == Referencias ==

← Revisión anterior		Revisión del 19:15 22 may 2012
Línea 87:		Línea 87:

	* '''dbsecret''': Selecionamos la ruta exacta en nuestra base de datos [[AstDB]] la que apuntan las contraseñas de los usuarios IAX.		* '''dbsecret''': Selecionamos la ruta exacta en nuestra base de datos [[AstDB]] la que apuntan las contraseñas de los usuarios IAX.
		+	* '''auth''': Tipo de Autentificación para el par en concreto, puede tomar valores como "plain", "rsa" o

	== Referencias ==		== Referencias ==

@@ Línea 17: / Línea 17: @@
 IAX tiene dos mecanismos de transportar la información. División en paquetes para cada tramo del medio, incorporando una cabecera por cada paquete, o una característica especial, utilizando sus funciones especificas de "trunking", llevando todos los medios, en un solo paquete con una sola cabecera. Haciendo un análisis de esta funcionalidad, se puede observar como el tiempo de respuesta baja, pero a cambio es necesario que el ancho de banda sea amplio para poder soportar el aumento en tamaño de los paquetes. Si trabajamos con conexiones con muy poco ancho de banda, sería recomendable no utilizar esta capacidad de "trunking".
 Por otro lado, a nivel de mensajes, los mensajes más comunes, con los que trabaja este protocolo son los siguientes:
@@ Línea 41: / Línea 43: @@
 Por último y no la menos importante, la capacidad de incorporar características de seguridad como mejoras desarrolladas para protocolo específicamente en el sistema Asterisk. No es necesario la instalación de añadidos, ni módulos específicos para conseguir este propósito. Todo a través del fichero de configuración especifico de IAX y casi recomendable prescribirlo por regla general. Soporta autenticación de tipo PKI (Public-Key Infraestructure) con claves RSA bastante apropiadas si tratamos de comunicaciones probablemente sometidas a eventuales accesos indebidos.
 == Referencias ==

← Revisión anterior		Revisión del 17:42 22 may 2012
Línea 41:		Línea 41:

	Por último y no la menos importante, la capacidad de incorporar características de seguridad como mejoras desarrolladas para protocolo específicamente en el sistema Asterisk. No es necesario la instalación de añadidos, ni módulos específicos para conseguir este propósito. Todo a través del fichero de configuración especifico de IAX y casi recomendable prescribirlo por regla general. Soporta autenticación de tipo PKI (Public-Key Infraestructure) con claves RSA bastante apropiadas si tratamos de comunicaciones probablemente sometidas a eventuales accesos indebidos.		Por último y no la menos importante, la capacidad de incorporar características de seguridad como mejoras desarrolladas para protocolo específicamente en el sistema Asterisk. No es necesario la instalación de añadidos, ni módulos específicos para conseguir este propósito. Todo a través del fichero de configuración especifico de IAX y casi recomendable prescribirlo por regla general. Soporta autenticación de tipo PKI (Public-Key Infraestructure) con claves RSA bastante apropiadas si tratamos de comunicaciones probablemente sometidas a eventuales accesos indebidos.
−
−	~~=== Subtitulo 2.1 ===~~
−
−	~~Info del Subtitulo 2.1~~
−
−	~~==== Subitutlo 2.1.1 ====~~
−
−	~~Info del Subtitulo 2.1.1~~
−
−	~~=== Subtitulo 2.2 ===~~
−
−	~~Info del Subtitulo 2.2~~

	== Referencias ==		== Referencias ==