Hola, estoy probando este escenario:
Asterisk genera una llamada SIP a alguna extensión de OpenSer. Todo correcto aún en el caso de que se cree un LoopBack en Asterisk:
- Asterisk llama a sip:500@openser.dominio.org - OpenSer recibe la llamada y la vuelve a encaminar a Asterisk con rewriteuri. - Asterisk la recibe, avisa de "482: Loop Detected" pero la recibe y se establece la comunicación. - Por supuesto, puesto que Asterisk tiene un SIP cutre, el siguiente BYE no respeta el "Record-Route" y no pasa por OpenSer, en fin...
Este es el log de Asterisk:
----------------------------------------------------------------------------------------- -- Executing [KK_500@default:1] Dial("OSS/dsp", "SIP/openser/500") in new stack -- Called openser/500 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding OSS/dsp to 'Local/500@entrantes-openser' (thanks to SIP/openser-08351810) -- Executing [500@entrantes-openser:1] Playback("Local/500@entrantes-openser-e11e,2", "demo-congrats") in new stack -- Local/500@entrantes-openser-e11e,1 answered OSS/dsp -----------------------------------------------------------------------------------------
Pero ahora me da por poner un simple alias: 888 -> 500.
- En Asterisk hago una llamada a 888@openser.dominio.org. - OpenSer encuentra un alias de 888 a 500 y reescribe el URI. - Entonces de nuevo OpenSer reescribe el URI y encamina al Asterisk. - Pero ahora Asterisk se vuelve loco del todo, avisando decenas de veces de "LoopBack".
Ahora en Asterisk leo:
----------------------------------------------------------------------------------------- -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-870f,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-870f,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-8f00,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-8f00,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-0823aed8) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-71d9,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-71d9,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50) -----------------------------------------------------------------------------------------
En fin, me gustaría preguntaros por vuestras experiencias exprimiendo el stack SIP de Asterisk. ¿Por qué demonios me permite loopback directo pero no lo permite si es un alias? ¿acaso se fija en el "To:" por alguna razón?
Saludos y gracias por cualquier aclaración.
El Lunes, 27 de Agosto de 2007, Iñaki Baz Castillo escribió:
En fin, me gustaría preguntaros por vuestras experiencias exprimiendo el stack SIP de Asterisk. ¿Por qué demonios me permite loopback directo pero no lo permite si es un alias? ¿acaso se fija en el "To:" por alguna razón?
Leo en: http://www.voip-info.org/wiki/view/Asterisk+at+large
"I don't think that Asterisk is quite ready to support all live deployment scenarios that include a 3rd party SIP proxy. One problem I ran into was Asterisk does not handle looped back calls.
For example a call comes in over PSTN to Asterisk, Asterisk forwards to your SIP registrar proxy, Registrar does a lookup on the SIP address and finds that the user is register'd to an analogue phone. If the SIP registrar redirected using a 3xx response the * will play along happily, but if the proxy wishes to stay in the loop (maybe you have a billing application running on it) it would add a Record-Route header to the SIP request , to say it wishes to receive all subsequent messages for this call, and then proxy back to the *. The * will ignore this INVITE totally. If the user had been registered to a proper SIP end point then the loop back wouldn't have happened and this works a treat."
Pero realmente NO es mi caso puesto que mi OpenSer no le responde a Asterisk con un redirect, simplemente OpenSer hace un append_branch y modifica el URI actual para que sea una extensión del Asterisk.
El Lunes, 27 de Agosto de 2007, Iñaki Baz Castillo escribió:
Pero ahora me da por poner un simple alias: 888 -> 500.
- En Asterisk hago una llamada a 888@openser.dominio.org.
- OpenSer encuentra un alias de 888 a 500 y reescribe el URI.
- Entonces de nuevo OpenSer reescribe el URI y encamina al Asterisk.
- Pero ahora Asterisk se vuelve loco del todo, avisando decenas de
veces de "LoopBack".
Buenas, primeramente pido disculpas porque al final he mandado un correo sobre este tema también a la lista de Asterisk (y hacer cross-posting es malo malo).
Bueno, finalmente he entendido que Asterisk **no** soporta LoopBack. La única ÑAPA que soporta es que Asterisk haga una llamada (p.ej. a sip:500@dominio.org), que esta llamada llegue a un proxy SIP el cual **sin modificar la extensión y dominio** la mande de vuelta a Asterisk de nuevo. En ese caso Asterisk avisa de "Loop back detected" pero hace la chapuza de "unir" los dos canales (el saliente y el entrante), pero ojo, no es un bridge ya que se carga los "Record-Route" que hayan podido incluir el proxy SIP y demás.
Lo de arriba no es más que una ñapa barata y se demuestra que no sirve de nada ya que en el caso de que un proxy SIP que recibe una llamada de Asterisk modifique el username/extensión y lo envíe de vuelta a Asterisk entonces éste último "falla", detecta el "Loop back", avisa de ello y trata de juntar los dos canales, pero **ojo**, sólo tiene en cuenta la URI ORIGINAL que él generó y no la modificada por el proxy SIP.
Como apunte optimista he encontrado un reporte en bugs.digium.com en el que Ollej y otros están creando un parche:
"allow SIP Spiral to work instead of causing a '482 Loop Detected' condition" http://bugs.digium.com/view.php?id=7403
Ahora mi pregunta sería:
Yo pretendía tener un Asterisk para llamadas entrantes vía PSTN y salientes vía PSTN/Voip/GSM... También quería mi sistema de forwarding que ya tengo implementado en OpenSer, es decir, que si Asterisk llama a sip:200@openser.domain.org y OpenSer tiene un forwarding a un número de móvil y hace un "append_branch()" (modificando el URI) que entonces esa llamada fuese de vuelta a Asterisk el cuál la sacase al exterior. Ahora veo que no puedo hacer eso debido a la limitación que explico arriba de Asterisk.
¿Alguna sugerencia sobre cómo abordar esta fatalidad que me ha tocado? Las opciones que veo son:
- Usar 2 Asterisk, uno para entrantes y otro para salientes y comunicarlos por IAX o SIP (bendita chapuza).
- Olvidarme de mi bonito forwarding e implementar un ReDirect en OpenSer que Asterisk sí soporta (no no y no, no me gusta).
- Otras...
En fin, saludos y gracias por aguantar el tostón.
Hola,
El Lunes, 27 de Agosto de 2007, Iñaki Baz Castillo escribió:
Pero ahora me da por poner un simple alias: 888 -> 500.
- En Asterisk hago una llamada a 888@openser.dominio.org.
- OpenSer encuentra un alias de 888 a 500 y reescribe el URI.
- Entonces de nuevo OpenSer reescribe el URI y encamina al Asterisk.
- Pero ahora Asterisk se vuelve loco del todo, avisando decenas de
veces de "LoopBack".
Buenas, primeramente pido disculpas porque al final he mandado un correo sobre este tema también a la lista de Asterisk (y hacer cross-posting es malo malo).
Bueno, finalmente he entendido que Asterisk **no** soporta LoopBack. La única ÑAPA que soporta es que Asterisk haga una llamada (p.ej. a sip:500@dominio.org), que esta llamada llegue a un proxy SIP el cual **sin modificar la extensión y dominio** la mande de vuelta a Asterisk de nuevo. En ese caso Asterisk avisa de "Loop back detected" pero hace la chapuza de "unir" los dos canales (el saliente y el entrante), pero ojo, no es un bridge ya que se carga los "Record-Route" que hayan podido incluir el proxy SIP y demás.
Lo de arriba no es más que una ñapa barata y se demuestra que no sirve de nada ya que en el caso de que un proxy SIP que recibe una llamada de Asterisk modifique el username/extensión y lo envíe de vuelta a Asterisk entonces éste último "falla", detecta el "Loop back", avisa de ello y trata de juntar los dos canales, pero **ojo**, sólo tiene en cuenta la URI ORIGINAL que él generó y no la modificada por el proxy SIP.
Desde siempre asterisk sólo ha podido hacer matching de transacciones, no de diálogos/branches.
Ahora mi pregunta sería:
Yo pretendía tener un Asterisk para llamadas entrantes vía PSTN y salientes vía PSTN/Voip/GSM... También quería mi sistema de forwarding que ya tengo implementado en OpenSer, es decir, que si Asterisk llama a sip:200@openser.domain.org y OpenSer tiene un forwarding a un número de móvil y hace un "append_branch ()" (modificando el URI) que entonces esa llamada fuese de vuelta a Asterisk el cuál la sacase al exterior. Ahora veo que no puedo hacer eso debido a la limitación que explico arriba de Asterisk.
¿Alguna sugerencia sobre cómo abordar esta fatalidad que me ha tocado? Las opciones que veo son:
- Usar 2 Asterisk, uno para entrantes y otro para salientes y
comunicarlos por IAX o SIP (bendita chapuza).
mmmm... quizás esta es una opción... no es nada bonita pero funcionaría.
- Olvidarme de mi bonito forwarding e implementar un ReDirect en
OpenSer que Asterisk sí soporta (no no y no, no me gusta).
Me quedo con la primera.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
Desde siempre asterisk sólo ha podido hacer matching de transacciones, no de diálogos/branches.
Entiendo, dolorosamente, a lo que te refieres.
Sólo un concepto: ¿por qué haces distinción entre transacción y branch? ¿acaso no es lo mismo? Es más, es algo que se supone yo tenía claro, ahora me has puesto en duda, pero lo he comprobado y efectivamente durante un diálogo cada transacción tiene un parámetro branch diferente en su VIA.
- Usar 2 Asterisk, uno para entrantes y otro para salientes y
comunicarlos por IAX o SIP (bendita chapuza).
mmmm... quizás esta es una opción... no es nada bonita pero funcionaría.
- Olvidarme de mi bonito forwarding e implementar un ReDirect en
OpenSer que Asterisk sí soporta (no no y no, no me gusta).
Me quedo con la primera.
Lo que pasa es que es una ñapa interesante, ya me estoy imaginando el caso de tener tarjetería BRI o la que fuere: tendré que ponerla en uno de los Asterisk (Asterisk-in por ejemplo) y unir Asterisk-in con Asterisk-out mediante IAX para que las salientes a PSTN las envíe Asterisk-out a Asterisk-in. En fin... qué guarrada :(
Muchas gracias por todo.
Hola,
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
Desde siempre asterisk sólo ha podido hacer matching de transacciones, no de diálogos/branches.
Entiendo, dolorosamente, a lo que te refieres.
Sólo un concepto: ¿por qué haces distinción entre transacción y branch? ¿acaso no es lo mismo? Es más, es algo que se supone yo tenía claro, ahora me has puesto en duda, pero lo he comprobado y efectivamente durante un diálogo cada transacción tiene un parámetro branch diferente en su VIA.
:%s/branches/tags/g :-)
Branch identifica transacciones. Tags identifican diálogos.
Saludos JesusR.
- Usar 2 Asterisk, uno para entrantes y otro para salientes y
comunicarlos por IAX o SIP (bendita chapuza).
mmmm... quizás esta es una opción... no es nada bonita pero funcionaría.
- Olvidarme de mi bonito forwarding e implementar un ReDirect en
OpenSer que Asterisk sí soporta (no no y no, no me gusta).
Me quedo con la primera.
Lo que pasa es que es una ñapa interesante, ya me estoy imaginando el caso de tener tarjetería BRI o la que fuere: tendré que ponerla en uno de los Asterisk (Asterisk-in por ejemplo) y unir Asterisk-in con Asterisk-out mediante IAX para que las salientes a PSTN las envíe Asterisk-out a Asterisk-in. En fin... qué guarrada :(
Muchas gracias por todo.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
Hola,
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
Desde siempre asterisk sólo ha podido hacer matching de transacciones, no de diálogos/branches.
Entiendo, dolorosamente, a lo que te refieres.
Sólo un concepto: ¿por qué haces distinción entre transacción y branch? ¿acaso no es lo mismo? Es más, es algo que se supone yo tenía claro, ahora me has puesto en duda, pero lo he comprobado y efectivamente durante un diálogo cada transacción tiene un parámetro branch diferente en su VIA.
:%s/branches/tags/g :-)
Vale, buff, qué susto :)
Branch identifica transacciones. Tags identifican diálogos.
Aclarado ;)
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
- Usar 2 Asterisk, uno para entrantes y otro para salientes y
comunicarlos por IAX o SIP (bendita chapuza).
mmmm... quizás esta es una opción... no es nada bonita pero funcionaría.
Se me estaba ocurriendo ahora que usar dos Asterisk en la misma máquina, además de ser engorroso, es un poco despilfarro. Lo único que yo necesitaría es un B2BUA SIP, algo que reciba la llamada de OpenSer (que a su vez viene de Asterisk) y genere otra nueva como UAC a Asterisk (todo esto para que Asterisk no detecte que es el mismo INVITE que él mismo inició y no lo rechace como "Loop Back").
Entonces, ¿qué otros B2BUA SIP me podrían servir? sobre todo me preocupa el tema del RTP ya que entiendo que meter otro B2BUA implica también tragarse el flujo RTP.
¿O tal vez me podría servir otro OpenSer haciendo de UAC en la máquina de Asterisk? aunque tengo entendido que el UAC de OpenSer es bastante limitado.
En fin, la que me ha liado Asterisk y su puñetera implementación de SIP, cada vez que pruebo algo Asterisk me prepara una sorpresa de este tipo.
Saludos.
El Martes, 28 de Agosto de 2007, Iñaki Baz Castillo escribió:
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
- Usar 2 Asterisk, uno para entrantes y otro para salientes y
comunicarlos por IAX o SIP (bendita chapuza).
mmmm... quizás esta es una opción... no es nada bonita pero funcionaría.
Se me estaba ocurriendo ahora que usar dos Asterisk en la misma máquina, además de ser engorroso, es un poco despilfarro. Lo único que yo necesitaría es un B2BUA SIP, algo que reciba la llamada de OpenSer (que a su vez viene de Asterisk) y genere otra nueva como UAC a Asterisk (todo esto para que Asterisk no detecte que es el mismo INVITE que él mismo inició y no lo rechace como "Loop Back").
Vale, he encontrado 2 opciones: http://www.b2bua.org http://www.vovida.org/applications/downloads/b2bua/ (creo que algo desfasado)
Yo estuve enredando con el módulo UAC de OpenSER y no saqué nada en limpio... No autenticaba correctamente... Aunque creo que para la 1.3.0 han hecho cambios, yo probé con la trunk y nada...
PD: También puede que no hiciera las cosas bien, aunque por lo que he leido no va nada fino...
El 28/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Martes, 28 de Agosto de 2007, Jesus Rodriguez escribió:
- Usar 2 Asterisk, uno para entrantes y otro para salientes y
comunicarlos por IAX o SIP (bendita chapuza).
mmmm... quizás esta es una opción... no es nada bonita pero funcionaría.
Se me estaba ocurriendo ahora que usar dos Asterisk en la misma máquina, además de ser engorroso, es un poco despilfarro. Lo único que yo necesitaría es un B2BUA SIP, algo que reciba la llamada de OpenSer (que a su vez viene de Asterisk) y genere otra nueva como UAC a Asterisk (todo esto para que Asterisk no detecte que es el mismo INVITE que él mismo inició y no lo rechace como "Loop Back").
Entonces, ¿qué otros B2BUA SIP me podrían servir? sobre todo me preocupa el tema del RTP ya que entiendo que meter otro B2BUA implica también tragarse el flujo RTP.
¿O tal vez me podría servir otro OpenSer haciendo de UAC en la máquina de Asterisk? aunque tengo entendido que el UAC de OpenSer es bastante limitado.
En fin, la que me ha liado Asterisk y su puñetera implementación de SIP, cada vez que pruebo algo Asterisk me prepara una sorpresa de este tipo.
Saludos.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Lunes, 27 de Agosto de 2007, Iñaki Baz Castillo escribió:
Pero ahora me da por poner un simple alias: 888 -> 500.
- En Asterisk hago una llamada a 888@openser.dominio.org.
- OpenSer encuentra un alias de 888 a 500 y reescribe el URI.
- Entonces de nuevo OpenSer reescribe el URI y encamina al Asterisk.
- Pero ahora Asterisk se vuelve loco del todo, avisando decenas de
veces de "LoopBack".
Ahora en Asterisk leo:
-------------- -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-870f,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-870f,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-8f00,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-8f00,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-0823aed8) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-71d9,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-71d9,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50)
Buff, estoy que no me lo creo... XDDD
He provado el patch para el chan_sip que permite "spiral" en vez de rechazar por "LoopBack" y ¡¡¡funciona!!!
Simplemente he seguido este reporte en el que al final me he puesto un poco pesao pidiendo sopitas XD
http://bugs.digium.com/view.php?id=7403
Ahora lo que me falta saber es si ese parche está también disponible para la versión trunk, ya que el chan_sip de entonces con el de ahora no tiene nada que ver (aunque el de ahora tenga sus fallos y tal).
En fin, que si me puedo ahorrar el invento de tener que usar un B2BUA y tal sólo para paliar esta carencia de Asterisk bienvenido sea :)
Saludos.
Como diria Homer: yuhu!!
El 30/08/07, Iñaki Baz Castillo ibc@aliax.net escribió:
El Lunes, 27 de Agosto de 2007, Iñaki Baz Castillo escribió:
Pero ahora me da por poner un simple alias: 888 -> 500.
- En Asterisk hago una llamada a 888@openser.dominio.org.
- OpenSer encuentra un alias de 888 a 500 y reescribe el URI.
- Entonces de nuevo OpenSer reescribe el URI y encamina al Asterisk.
- Pero ahora Asterisk se vuelve loco del todo, avisando decenas de
veces de "LoopBack".
Ahora en Asterisk leo:
-------------- -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-870f,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-870f,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-8f00,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-8f00,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-0823aed8) -- Executing [888@entrantes-openser:1] Dial("Local/888@entrantes-openser-71d9,2", "SIP/openser/888||") in new stack -- Called openser/888 -- Got SIP response 482 "Loop Detected" back from 82.94.0.210 -- Now forwarding Local/888@entrantes-openser-71d9,2 to 'Local/888@entrantes-openser' (thanks to SIP/openser-081fdf50)
Buff, estoy que no me lo creo... XDDD
He provado el patch para el chan_sip que permite "spiral" en vez de rechazar por "LoopBack" y ¡¡¡funciona!!!
Simplemente he seguido este reporte en el que al final me he puesto un poco pesao pidiendo sopitas XD
http://bugs.digium.com/view.php?id=7403
Ahora lo que me falta saber es si ese parche está también disponible para la versión trunk, ya que el chan_sip de entonces con el de ahora no tiene nada que ver (aunque el de ahora tenga sus fallos y tal).
En fin, que si me puedo ahorrar el invento de tener que usar un B2BUA y tal sólo para paliar esta carencia de Asterisk bienvenido sea :)
Saludos.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
El Jueves, 30 de Agosto de 2007, Saúl Ibarra escribió:
Como diria Homer: yuhu!!
Bueno, espero no ser pesado (no puedo negar que tengo mucho interés en que este parche pase al trunk), pero en el tracker de Asterisk han sugerido que más gente lo testee y he escrito los pasos a seguir para testearlo por si alguien quiere hacerlo:
http://blog.aliax.net/2007/08/asterisk-parche-chansip-para-permitir.html
Sin más, que ya que os he dado tanto al chapa pues... un poco más XDDD
No, en serio, muchas gracias por toda vuestra ayuda. Saludos.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra