Retry Dial en Asterisk

Hola.

Aqui estoy de nuevo con otra pequeña aportación para la comunidad, esta vez les voy a mostrar como hacer un plan de marcado de Asterisk a prueba de bombas ( o casi jeje).

En este caso lo que vamos a hacer es trabajar con 2 troncales de 2 operadores SIP. Intentaremos sacar la llamada 3 veces por el primero, y si no lo conseguimos, reintentamos otras 3 veces más con el segundo, es muy sencillo.

 

; Definimos variables. Numero de intentos y proveedores
exten => s,1,Set(INTENTOS=3)
exten => s,n,Set(PROVEEDOR1=SIP/proveedor1)
exten => s,n,Set(PROVEEDOR2=SIP/proveedor2)

Con este parrafo definimos todas las variables que vamos a utilizar. En la primera linea, declaramos una variable llamada INTENTOS que valdrá 3, serán los intentos a realizar para cada proveedor. PROVEEDOR1 y PROVEEDOR2 estan definidos en mi archivo sip.conf.

 

; Intentamos sacar llamada por TRUNK 1
exten => s,n(llamar),Set(REALIZADOS=0)
exten => s,n(dial),Dial(${PROVEEDOR1}/${MACRO_EXTEN},30)
exten => s,n,Set(REALIZADOS=$[${REALIZADOS}+1])
exten => s,n,GotoIf($[${REALIZADOS} < ${INTENTOS}]?dial:proveedor2)

 

Con esto, intentamos sacar la llamada. La primera linea «setea» la variable REALIZADOS en 0 y a continuación se ejecuta el Dial, si ocurre algún problema sigue a la siguiente linea, en la que, incrementamos el valor de REALIZADOS en 1. Abajo comparamos si REALIZADOS es MENOR que INTENTOS, como si que lo es, ejecutará dial (volver a ejecutar de nuevo el Dial()). Esto ocurria 3 veces, a la 3º el plan de marcado seguirá hasta la etiqueta proveedor2.

 

; Reintentamos sacar llamada por TRUNK 2
exten => s,n(proveedor2),Set(REALIZADOS=0)
exten => s,n(redial),Dial(${PROVEEDOR2}/${MACRO_EXTEN},30)
exten => s,n,Set(REALIZADOS=$[${REALIZADOS}+1])
exten => s,n,GotoIf($[${REALIZADOS} < ${INTENTOS}]?redial)
exten => s,n,Goto(ERROR,1)

 

exten => ERROR,1,Playback(beep)

exten => ERROR,n,Hangup

 

En la primera linea volvemos a setear REALIZADOS en 0 y a continuación intentamos marcar de nuevo pero esta vez con $PROVEEDOR2.

Si falla, sigue su camino y incrementa la variable REALIZADOS. El gotoIf hará la misma comparación y mientras REALIZADOS sea menor que INTENTOS (3) seguirá intentandolo.

Si en esta ocasión falla al intentar sacar la llamada 3 veces, irá a parar a ERROR, el cual, hará que en el telefono suene un pitido y colgará.

 

 

 

 

Esto es todo, espero que les sirva.

Un saludo 😀

 

Share

Mysql dialplan Asterisk.

En algunos escenarios, trabajando con Asterisk, tenemos la necesidad de consultar datos de una base de datos, para por ejemplo, dar la posibilidad a un usuario a traves de una página dinámica en PHP activar o desactivar un buzón de voz. Esto como he dicho, se puede conseguir realizando consultas a Mysql desde el mismo dialplan de asterisk.

Es bastante sencillo, con lo que pondré varias lineas a modo de ejemplo:

Utilizaremos la función Noop de asterisk para saber en todo momento como recorre asterisk nuestro pequeño plan de marcado.

Para conseguir esto en asterisk se utiliza la función Mysql.

Lo primero que se tiene que hacer es conectar con el servidor (Mysql) y la base de datos con la que queremos trabajar.

Mysql(connect conex localhost usuario password base_de_datos)

– conex: Esta variable almacenara la sesión de la conexión. (La tendremos que indicar a las futuras consultas de mysql)
– Localhost: Seria la IP o nombre del servidor donde se aloja la base de datos
– Usuario: Aqui se indicaria el usuario de la base de datos
– Password: Password de la base de datos
– base_de_datos: Aqui el nombre de la base de datos con la que vamos a trabajar.

Ejemplo:

Mysql(connect conex localhost myuser mypassword dbasterisk)

Una vez explicado esto, se debe saber que este es el primer punto a realizar.

El segundo punto a realizar seria la consulta.
Lo único que cambia en este caso es la palabra connect por query. Indica a la función mysql que vamos a realizar una consulta.

Mysql(query consulta ${conex} ..CONSULTA MYSQL.. )

– consulta: Variable que retornará el retorno de la consulta
– ${conex}: Variable que indicamos anteriormente para realizar la conexion. Pasandole esta variable hacemos referencia a la conexión establecida anteriormente.
– ..CONSULTA MYSQL.. : Aqui se indicará una consulta Mysql estándar.

Ejemplo:

Mysql(query consulta ${conexion} SELECT dst FROM tabla_1 WHERE id=1 )

Recogeremos los valores del campo dst, cuya tabla es tabla_1 y el valor id sea 1..

Hemos conectado con mysql en el punto 1, hemos realizado la consulta en el punto 2. Ahora nos falta poder «leer» el contenido que nos a retornado dicha consulta.

Para esto utilizamos la función mysql seguida de fetch:

Mysql(fetch asignar ${consulta} var1)

– asignar: Esta variable retornará si la operación tubó exito o no.
– ${consulta}: Es la variable que indicamos anteriormente en la consulta. Le estamos diciendo que nos «extraiga» el resultado de dicha consulta que anteriormente ejecutamos con query.

– var1: Seria la variable a la que se pasaria el valor ya legible. Ahora podriamos utilizar Noop para leer su resultado en la consola de asterisk o para tratarla a lo largo del dialplan.

En el caso de que query nos devuelva más de un registro y queramos acceder al siguiente, podemos utilizar la nueva funcionalidad que SOLAMENTE ESTA DISPONIBLE PARA ASTERISK 1.8.

Mysql(Nextresult sigregistro ${connid})

-Nextresult: Se trata de la nueva funcionalidad agregada por asterisk en la versión 1.8. Permite ir avanzando entre todos los registros «soltados» por mysql. Si la consulta devolvió 4 registros diferentes, podremos acceder a esos 4 haciendo un Nextresult & fetch para cada uno de ellos. Con Nextresult pasamos de registro y con fetch lo rescatamos a una variable.

– sigregistro: Se trata de la variable donde se retornará el puntero al registro. Seria esta variable la que tendriamos que utilizar ahora en fetch.

Ejemplo:

Mysql(fetch asignar ${sigregistro} var1)

Con la linea anterior, el registro pasará a estar disponible desde la variable ${var1}

Una vez hemos terminado con todo lo relaciono con mysql tenemos que «limpiar» todo lo relacionado con la consulta y desconectarnos del servidor mysql.
Se consigue con:

Mysql(clear ${consulta})    # Para limpiar

– ${consulta}: Seria el puntero que indica la consulta anteriormente realizada.

Mysql(disconnect ${conex}) # para desconectar

– ${conex}: Seria el puntero que indica la conexión de la que queremos desconectarnos. (La anteriormente realizada)

Despues de aprender todo lo comentado, dejo a modo de ayuda todo el dialplan referente a las pruebas realizadas.

exten => 111,n,Noop(Vamos a conectar con Mysql)
exten => 111,n,Mysql(connect conex localhost miusuarioasterisk password999 asterisk-tabla)
exten => 111,n,Noop(Resultado de conexion: = ${conex})
exten => 111,n,Noop(Consultamos datos de la DB)
exten => 111,n,Mysql(query consulta ${conex} SELECT dst FROM cdr WHERE dst=123456789)
exten => 111,n,Noop(Resultado de consulta: ${consulta})
exten => 111,n,Noop(Asignamos el resultado de la consulta a var1)
exten => 111,n,Mysql(fetch asignacion ${consulta} var1)
exten => 111,n,Noop(Valor de variable VAR1 es: ${var1})
exten => 111,n,Noop(Limpiamos con clear)
exten => 111,n,Mysql(clear ${consulta})
exten => 111,n,Mysql(Vamos a desconectarnos del servidor Mysql con disconnect)
exten => 111,n,Mysql(disconnect ${conex})
exten => 111,n,Noop(Terminado…monovarlinux.org 😀 :=). Conocimiento libre! . Gracias linux & asterisk por existir)
exten => 111,n,Hangup

Como podeis ver, dicho dialplan se ejecutara al marcar 111. Podran ver todos los mensajes Noop, su salida, en la consola de asterisk, entrando a ella con asterisk -vvvvvvvvvr.

 

Espero que una vez más sirva de utilidad a alguien.
Como siempre, cada dia más y mejores. Conocimiento libre!

Un saludo.

Share

[SIP] Sip-retransmit.txt Spanish. Sip-retransmit en español.

Hola.

Hace unos dias estube pegando un repaso al documento sip-retransmit.txt y solamente lo encontre en ingles, lo leí y lo traducí personalmente, espero que alguien le pueda ayudar.

——————————————————————–
¿Que es el problema de la retransmision SIP? (Sip retransmits)
——————————————————————————-

Algunas veces aparecen mensajes en la consola de asterisk como los siguientes:

– «retrans_pkt» Hanging up call XX77yy – no reply to our critical packet.»
– «retrans_pkt»: Cancelling retransmit of OPTIONs»

El protocolo SIP se basa en peticiones y respuestas a esas peticiones. Ambas partes envian y reciben respuestas a las solicitudes. Algunas de estas partes son esenciales para una comunicación. En una red TCP/IP pueden ocurrir muchas cosas con los paquetes IP. Firewalls, dispositivos NAT (Routers), Session Border controllers y Proxys SIP, pueden provocar una mala señalización y afectar a la llamada.

SIP Establecer Llamada – INVITE – 200 OK – ACK

1 – Invite
2 – 200 OK
3 – ACK

Para iniciar una llamada SIP, se envia una petición INVITE.
El software sip con el que iniciamos la llamada envia una petición invite (al usuario que llama) y espera una respuesta.
Cuando la petición INVITE fué satisfactoria (el usuario se encuentra disponible y demás)el usuario»que es llamado» envia una petición ‘ACK’. Para informar al otro dispositivo que envió la petición INVITE hacia él, que la recibió correctamente.
Se trata de un acuerdo a 3 vias que se repite mientras una llamada transcurre para asegurarse que todos los dispositivos «el usuario que llama» y el «que es llamado» se encuentran encendidos y funcionando.

– La primera respuesta que esperamos a menudo es un ‘100 Trying’.
Este mensaje significa que algún tipo de servidor SIP ha recibido nuestra solicitud
y se asegura que vamos a obtener una respuesta.

Podria ser el otro extremo (el usuario al que llamamos) o un Proxy SIP o SBC que se encarga de las solicitud en nuestro nombre.

– Despues de eso, a menudo se recibe una respuesta de clase 18x,como «Ring 180″ o » 183 Progreso de sesión».
Esto significa que nuestra solicitud ha alcanzado al menos un extremo y alerta al otro dispositivo que ahi una llamada que viene.

– Por último (si todo a ido bien), la otra respuesta que recibimos del otro lado es un «200 OK». Esto es una respuesta positiva. Este mensaje contiene la dirección directa del dispositivo que nos da la respuesta 200 OK.
Recuerde podria haber varios telefonos sonando. La direccion del telefono es especificada en el campo Contact de la Cabecera SIP.

– Para confirmar que podemos «alcanzar» al telefono que respondió nuestra llamada y responder al 200 OK del otro telefono, ahora enviamos un «ACK’ a la dirección de Contacto de la cabecera SIP.
Si este ACK no es alcanzado por el otro telefono (al que llamamos), la llamada fallaria.
Si no podemos enviar un ACK, no podemos enviar nada ni un «colgado limpio».

Cuando una llamada falla la señalización no tiene sentido dejarla activa.

– Si recibimos una respuesta de error a nuestro INVITE, como «Busy» o «Rejected», enviamos un «ACK» a la dirección que enviamos anteriormente el INVITE, para confirmar su respuesta.

Para asegurar el orden de las llamadas, un cliente SIP retransmite mensajes si no se demora demasiado entre la solicitud y respuesta esperada. Podemos retransmitir varias veces durante un tiempo esperando una respuesta. Nosotros transmitidos varias veces esperando un ACK para INVITE. Si obtenemos respuestas múltiples, respondemos con ACK a cada una de ellas para hacerle saber que la respuesta nos llego correctamente.

Si no recibimos un ACK (confirmación del otro lado) a nuestro INVITE, incluso despues de reenviar nuestras peticiones al otro lado, la llamada finalizará con los mensajes citados más arribas.

Otras peticiones SIP —
————————
Otras peticiones SIP son solamente a 2 vías. Petición — Respuesta.
No hay confirmación de recibir el tráfico (ACK).

En asterisk marcamos estas como CRITICAL.

El proceso de calificación —– OPCIONES
———————————–

Si t uañades a tu sip.conf ‘qualify=yes’ para un dispositivo, Asterisk manda opciónes de respuesta cada minuto para el dispositivo y chequea si este responde.

Cada solicitud una vez añadida esta opción a nuestro sip.conf, se envia un numero de veces (para comprender la posible perdida de paquetes) y si no obtenemos respuesta, el dispositivo se considera inalcanzable. A partir de ese momento se envia una nueva solicitud cada decimo de segundo.

¿Por qué sucede esto?
—————————–

Por alguna razón la señalización no funciona como se espera entre el servidor Asterisk y el otro dispositivo. Puede haber muchas razones por qué sucede esto:

– Un dispositivo NAT enmedio de alguna de las 2 rutas

– Un dispositivo NAT mal configurado y no deja pasar mensajes SIP

– Un Firewall bloqueando los mensajes SIP o los redirecciona incorrectamente

– Un middlebox SIP (SBC), que reescribe la cabecera de contacto incorrectamente.

– Un proxy SIP mal configurado que se olvida de añadir cabecera de registro de ruta para asegurarse de la correcta señaliación.

– Perdida de paquetes. IP y UDP son medios de transporte poco fiable.
Si pierdes demasiados paquetes muchos paquetes de retransmisión serán enviados
y la comunicación será imposible. Si esto sucede con la señalización los medios de comunicación serán inservibles de todos modos.

¿Que puedo hacer?
—————————————

Activar la depuración SIP en asterisk (sip set debug on), tratar de comprender la señaliacion y ver si se pierden las respuestas a INVITE o si pierdes los ACK.
Cuando usted sabe lo que sucede, tu has tomado el primer paso para localizar el problema. Vea la lista de arriba e investigue en su red.

Para problemas de NAT o Firewall, ahi varios documentos que le ayudarán. Empiece por leer el fichero ‘sip.conf.sample’ este es parte de Asterisk distribution.

La señalización estándar SIP, incluyendo las retransmisions y contadores de tiempos para ellos. Esta bien documentando en el IETF RFC 3261

Buena suerte para solventar tus problemas SIP.

Saludos.

Share

Asterisk. Audio en un solo sentido llamadas entrantes. Incoming Calls

Hola.

Sigo con mi implementación de asterisk en gentoo y vengo a contar como solucionar un problemita con este…

Actualmente estoy saliendo a la Red Telefonica Básica (RTB), red de telefonia de toda la vida, por un proveedor voip.
Para enrutar llamadas por este, no hubo más problemas. Registrar nuestro asterisk con el proveedor, añadir un canal para este en sip.conf y crear un dialplan para sacar llamadas por ahi y FIN.

El problema no era ese, el problema era al intentar recibir llamadas. Tengo varios numeros DID asignados a varias extensiones de mi asterisk con lo cual es fundamental que puedan entrar llamadas, y estas lo hacian, pero solo tenia audio en 1 sentido (de dentro hacia fuera), el usuario que me llamaba yo no lo podia escuchar, el a mi perfectamente…

*Problema de NAT no era, ya que estaba trabajando fuera de un entorno con NAT
**por lo menos por mi parte, parece ser que por la del operador de números DID no

Lo primero que hice en este caso fué entrar a la consola de asterik:

asterisk -r

Y hacer un debug del protocolo RTP para ver que es lo que estaba pasando con los paquetes….

rtp set debug on

He aqui el resultado:

Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014191, ts 392580221, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026450, ts 392580216, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014192, ts 392580381, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026451, ts 392580376, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014193, ts 392580541, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026452, ts 392580536, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014194, ts 392580701, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026453, ts 392580696, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014195, ts 392580861, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026454, ts 392580856, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014196, ts 392581021, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026455, ts 392581016, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014197, ts 392581181, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026456, ts 392581176, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014198, ts 392581341, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026457, ts 392581336, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014199, ts 392581501, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026458, ts 392581496, len 000160)
Got  RTP packet from    192.168.10.15:16406 (type 08, seq 014200, ts 392581661, len 000160)
Sent RTP packet to      46.19.209.78:17962 (type 08, seq 026459, ts 392581656, len 000160)

Me pusé a leer de cabo a rabo el fichero sip.conf que trae asterisk de ejemplo y me encuentro con:

;directmedia=yes                ; Asterisk by default tries to redirect the
; RTP media stream to go directly from
; the caller to the callee.  Some devices do not
; support this (especially if one of them is behind a NAT).
; The default setting is YES. If you have all clients
; behind a NAT, or for some other reason want Asterisk to
; stay in the audio path, you may want to turn this off.

Nos dice que asterisk querrá establecer una conexión DIRECTA con el usuario que llama y el usuario que contesta a la llamada. Esto no es soportable por algunos dispositivos,especialmente si estan detrás de NAT…….. Esta opción es interesante cuando nos encontramos en un entorno LAN sin dispositivos NAT por enmedio, ya que la comunicación se hará directamente entre los 2 interlocutores. Si hay dispositivos NAT por enmedio es MUY recomendable desactivar dicha opción. (por defecto directmedia esta en YES)

Ahi tenia la respuesta…directmedia estaba en yes por defecto…. fuí al fichero sip.conf y añadí:

[general]
directmedia=off

Reinicio asterisk con:

asterisk -r
core restart now

……..Realizo la llamada desde el exterior, descuelgo el telefono que suena y olalalal!!!!! funcióna el audio en 2 sentidos..
Si ahora hacemos un: debug de rtp observamos lo siguiente….

Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)
Sent RTP P2P packet to 46.19.209.76:19818 (type 08, len 000160)
Sent RTP P2P packet to 192.168.10.15:16410 (type 08, len 000160)

Esto es todo por hoy, espero que mis cabezazos contra la pared impidan que otros se los de por esto jeje.

Un saludo.

Share

[Asterisk] No se registran los usuarios SIP

Hola.

Ayer publiqué una receta para instalar asterisk en gentoo de un plumazo, ya que me tope con la instalación de asterisk en un pc gentoo.

Horas más tarde esto se complicó un poco y misteriosamente los clientes SIP no conectaban con asterisk :S :S :S .

Estube haciendo las pruebas con Sjphone en la misma máquina que corria Asterisk pero nada…

Lo primero que hicé fué ver si verdaderamente el daemon de asterisk estaba escuchando en el puerto 5060, que lo pude corroborar enseguida:

netstat -tupl:

4257/asterisk
udp        0      0 *:5060                  *:*

Asterisk si estaba escuchando en el puerto 5060, osea todo estaba correcto… o casi todo..

Empecé un fichero ‘sip.conf‘ y ‘extensions.conf‘ totalmente desde 0 pero tampoco era la solución….

Cuando de repente se me ocurrió teclear »dmesg» para ver los mensajes del sistema y me encuentro con esto:

[   88.492694] nf_ct_sip: dropping packetIN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=449 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1000 DPT=5060 LEN=429 UID=0 GID=0
[   88.993099] nf_ct_sip: dropping packetIN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=449 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1000 DPT=5060 LEN=429 UID=0 GID=0
[   89.992296] nf_ct_sip: dropping packetIN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=449 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1000 DPT=5060 LEN=429 UID=0 GID=0
[   91.992871] nf_ct_sip: dropping packetIN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=449 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1000 DPT=5060 LEN=429 UID=0 GID=0

Nf_sip estaba dropeando paquetes con destino al puerto 5060… Entonces supusé que ese era el problema…

LA SOLUCIÓN (1) – La sencilla

echo «blacklist nf_nat_sip» >> /etc/modprobe.d/blacklist.conf

echo «blacklist nf_conntrack_sip» >> /etc/modprobe.d/blacklist.conf

reboot

Esto lo que hará es meter en la «lista negra» blacklist, los modulos nf_nat_sip y nf_conntrack_sip para que el kernel no los carge al inicio del sistema…

Esta solución funcionaria si dichos modulos estan seleccionados en el archivo .config del kernel como modulos…

¿¿La SOLUCIÓN (2)?? – Si NO los tenemos cmo modulos (<M>)

Ir a –> /usr/src/linux

Editar el archivo: .config

Cambiar las lineas:

CONFIG_NF_CONNTRACK_SIP

CONFIG_NF_NAT_SIP

###Por estas:

# CONFIG_NF_CONNTRACK_SIP is not set

# CONFIG_NF_NAT_SIP is not set

Guardar los cambios en .config

make && make modules_install && make install

cp arch/x86/boot/bzImage /boot/NOMBREKERNEL

reboot

– – NOMBREKERNEL: se sustituye por la imagen del kernel donde apunte grub (grub.conf)


Con esto desabilitamos totalmente la carga de los modulos CONFIG_NF_CONNTRACK_SIP y CONF_NAT_SIP en el kernel y se solucionaria nuestro problema.

Un saludo y espero que sirva de ayuda.

Bye!

Share

[Asterisk] Asterisk. Peer, User y Friend. Apuntes

Hola.

Lo que hoy publicaré quizá le sirva de ayuda a más de uno.

Son simplemente apuntes de Asterisk para una fácil comprensión de:

User

Peer

Friend

A simple vista parece sencillo:

User: Llamada que se autentifica con nuestra PBX (Centralita).  -Llamada ENTRANTE

Friend: Llamada entrante y saliente. Un usuario de tipo ‘Friend’ podria realizár llamadas y recibir llamadas.

Peer: En principio, es una llamada SALIENTE.

Cuando la llamada hacia nosotros se realiza desde un telefono normal (PSTN normal, linea de telefono normal) y va «directo» hacia nuestro Asterisk, seria Peer, sin duda.

(*) Pero cuando la llamada proviene de algun proxy sip, bien un proveedor sip externo o un terminal IP como pueda ser un Adaptador ATA tambien entraria en la sección de llamada ‘Peer‘.

Los conceptos se podian resumir (sin tener encuenta la excepción (*) ).  En que:

– Los ‘Users‘ son los que nos llaman, y nosotros llamamos a los ‘Peers‘.  Friend seria recibir y enviar llamadas.

Como para algunos puede ser algo confuso, les explicaré mejor esto, con unos ejemplos «»»gráficos»»»».

ejemplo

Perdonar por el pequeño fallo en la imagen ‘rutamos‘, seria «ENRUTAMOS«

En resumen, una llamada saliente siempre es tipo “peer”, una
llamada entrante puede ser tipo “user”, o tipo “peer” cuando la llamada entrante procede de un proxy.

Cuando hablamos de que «provenga de un proxy» puede ser que la llamada venga de un proveedor SIP o que la llamada provenga de un terminal IP como cualquier equipo ATA. (observar ejemplo)

Ojalá les sirva.

Un saludo.

Share

Llamar con Voipcheap o VoipBuster en Linux

Actualmente, ahi mucha gente que esta optando por los operadores de voz Ip, en este tutorial, os voy a explicar como poder llamar con Voipcheap com o VoipBuster desde linux, es muy sencillo.

1. Necesitamos un programa llamado, SjPhone, que es un cliente Voip generico, en el que podemos configurar nuestro proveedor Voip a utilizar.

Podemos bajar el programa pinchando Aquí

2.Una vez bajado el archivo .tar.gz, descomprimimos el fichero:

# tar -zxvf SJphone-1.60-Linux(preview)/SJphoneLnx-1.60.2235.tar.gz

3. Entramos a la carpeta y ejecutamos el fichero del programa y ahora ponemos estos datos:

##################
[BARRA MENU] Phone -> Preferences
[PESTAÑA] Profiles
[BOTON] New
-Una vez dentro:
Escribimos en ProfileName «VoipCheapCom» y Profile type «Call Trough SIP Proxy»
[BOTON] Ok.

Ahora se nos abrirá una ventana con el nombre: «Profile Options»

[PESTAÑA] SIP Proxy
Ahi introducimos lo siguiente:

Proxy Domain: «sip1.voipbuster.com» : «5060»
User Domain: «voipbuster.com»
[CASILLA] «Register With Proxy» -> la desmarcamos
Proxy for NAT: «sip1.voipbuster.com» : «5060»

[PESTAÑA] STUN
Server Address: «stun.voipbuster.com» : «3478»
[BOTON] OK
############

Una vez hecho todo esto, nos aparecerá la ventana principal del programa, vamos a Phone -> Services Y seleccionamos Voipcheapcom.
Ahora nos aparecerá una ventana que nos pide unos datos, introducimos los que tenemos del voipcheapcom y listo, ya podemos llamar perfectamente con linux.

El Numero de telefono a llamar se introduce en el cuadro alargado de arriba, siempre, recordar con el codigo de area, ej: 0034xxxxxxx.

Saludos.
ZaPa.

Share