[Asterisk-ES] Transferencias SIP

[Gelo]

Hola a todos

Cuando se hace una transferencia SIP con Asterisk, al llegar el REFER
se puentean los canales internamente, de forma un poco oscura a mi
entender.
Sin embargo, si a Asterisk le llega un REFER transfiriendo hacia otro
usuario SIP del que no tiene canal activo, manda un 202OK y luego el
NOTIFY con un "481 Call leg/transaction does not exist", y no manda,
como se esperaría, el INVITE hacia el Refer-to. Así que la llamada se
queda como estaba (pillada en mi caso)

Dicho de otro modo, cuando tengo una llamada establecida desde una
extensión a través de un kamailio hacia el asterisk e intento
transferir la llamada hacia otra extensión, se va todo a la m******.

Conocéis alguna solución que haga que Asterisk se porte bien?

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)

~~~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com

[Iñaki Baz Castillo]

El día 28 de abril de 2010 17:51, Gelo <gel...@gmail.com> escribió:
> Hola a todos
>
> Cuando se hace una transferencia SIP con Asterisk, al llegar el REFER
> se puentean los canales internamente, de forma un poco oscura a mi
> entender.
> Sin embargo, si a Asterisk le llega un REFER transfiriendo hacia otro
> usuario SIP del que no tiene canal activo, manda un 202OK y luego el
> NOTIFY con un "481 Call leg/transaction does not exist", y no manda,
> como se esperaría, el INVITE hacia el Refer-to. Así que la llamada se
> queda como estaba (pillada en mi caso)
>
> Dicho de otro modo, cuando tengo una llamada establecida desde una
> extensión a través de un kamailio hacia el asterisk e intento
> transferir la llamada hacia otra extensión, se va todo a la m******.
>
> Conocéis alguna solución que haga que Asterisk se porte bien?

Estás haciendo algo mal. Que haya un kamailio delante o no no debe
influir, en absoluto, en el comportamiento de Asterisk en la recepción
de un REFER (in-dialog claro). Garantizado.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Gelo]

No te diría yo que la "race condition" no la meta yo, pero en
cualquier caso asterisk está haciendo algo mal, porque los canales se
le quedan fritos. Están ahí haciendo un "core show channels", pero si
cuelgas la llamada devuelve un 481 al teléfono.

Y si la llamada la haces desde CLI, no permite hacer hangup, da el
famoso mensajito de No call to hang up. Para cepillarse los canales
hay que recurrir al soft hangup, que no parece de recibo en un sistema
estable, vaya.

Con qué versión de Asterisk te funciona a ti? Estoy haciendo pruebas
con la 1.4.30, tal vez hayan metido alguna gambada.

> ~~~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asteris...
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- Para anular la suscripción:asterisk-es...@googlegroups.com

[Iñaki Baz Castillo]

El día 29 de abril de 2010 10:57, Gelo <gel...@gmail.com> escribió:
> No te diría yo que la "race condition" no la meta yo, pero en
> cualquier caso asterisk está haciendo algo mal, porque los canales se
> le quedan fritos. Están ahí haciendo  un "core show channels", pero si
> cuelgas la llamada devuelve un 481 al teléfono.
>
> Y si la llamada la haces desde CLI, no permite hacer hangup, da el
> famoso mensajito de No call to hang up. Para cepillarse los canales
> hay que recurrir al soft hangup, que no parece de recibo en un sistema
> estable, vaya.
>
> Con qué versión de Asterisk te funciona a ti? Estoy haciendo pruebas
> con la 1.4.30, tal vez hayan metido alguna gambada.

A lo que me refiero es que, haya o no un proxy entre los teléfonos y
Asterisk, el mecanismo del REFER no varía en absoluto y en nada afecta
a Asterisk (si es que el proxy está bien configurado, claro).
No he probado la 1.4.30, pero vaya, que con cualquiera < 1.4.27 desde
luego funciona (que no funcionase implicaría que tampoco funcionaría
el REFER sin proxy en medio).

Saludos.

--
Iñaki Baz Castillo
<i...@aliax.net>

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)

[Gelo]

On 29 abr, 11:05, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 29 de abril de 2010 10:57, Gelo <gel...@gmail.com> escribió:
>
> > No te diría yo que la "race condition" no la meta yo, pero en
> > cualquier caso asterisk está haciendo algo mal, porque los canales se
> > le quedan fritos. Están ahí haciendo  un "core show channels", pero si
> > cuelgas la llamada devuelve un 481 al teléfono.
>
> > Y si la llamada la haces desde CLI, no permite hacer hangup, da el
> > famoso mensajito de No call to hang up. Para cepillarse los canales
> > hay que recurrir al soft hangup, que no parece de recibo en un sistema
> > estable, vaya.
>
> > Con qué versión de Asterisk te funciona a ti? Estoy haciendo pruebas
> > con la 1.4.30, tal vez hayan metido alguna gambada.
>
> A lo que me refiero es que, haya o no un proxy entre los teléfonos y
> Asterisk, el mecanismo del REFER no varía en absoluto y en nada afecta
> a Asterisk (si es que el proxy está bien configurado, claro).
> No he probado la 1.4.30, pero vaya, que con cualquiera < 1.4.27 desde

> luego funciona (que nofuncionase implicaría que tampoco funcionaría

> el REFER sin proxy en medio).
>
> Saludos.

En principio el kamailio está haciendo bien su parte, en lo que
respecta al call flow esperado. El asterisk es el que manda el 481, no
es que mande un 501 ni nada así, pero no es lo que debería enviar.

Sin proxy de por medio, si hago una transferencia SIP atendida
(llamada, cojo otra línea, transfiero) las dos llamadas pasan por
asterisk, así que es perfectamente natural que funcione sin problemas
cuando le llega el REFER. Pero en este caso, asterisk solo tiene un
canal y el refer le refiere a otro que no existe para él, y creo
(creía hasta ahora por lo menos) que ahí está el error. Ahora, si tú
me aseguras que sí funciona, tendré que explorar otras posibilidades.

Voy a probar con una 1.4.26, y a ver qué tal

Graciñas

[Iñaki Baz Castillo]

El día 29 de abril de 2010 12:17, Gelo <gel...@gmail.com> escribió:
> En principio el kamailio está haciendo bien su parte, en lo que
> respecta al call flow esperado. El asterisk es el que manda el 481, no
> es que mande un 501 ni nada así, pero no es lo que debería enviar.
>
> Sin proxy de por medio, si hago una transferencia SIP atendida
> (llamada, cojo otra línea, transfiero) las dos llamadas pasan por
> asterisk, así que es perfectamente natural que funcione sin problemas
> cuando le llega el REFER. Pero en este caso, asterisk solo tiene un
> canal y el refer le refiere a otro que no existe para él, y creo
> (creía hasta ahora por lo menos) que ahí está el error. Ahora, si tú
> me aseguras que sí funciona, tendré que explorar otras posibilidades.

Yo me refería al siguiente escenario:

- tfno1 llama al proxy.
- El proxy ruta a Asterisk.
- Asterisk ruta al proxy con RURI = tfno2.
- El proxy (también registrar entiendo) localiza a tfno-2 y le ruta la llamada.
- tfno-2 quiere transferir la llamada a tfno3 (también cliente del
proxy) por lo que envía un REFER a Asterisk (con quien está hablando
pues es un B2BUA) diciendo que transfiera la llamada a tfno-3.
- Asterisk llama al proxy con RURI = tfno3.
- El proxy localiza a tfno-3 y le ruta la llamada.

Ahora, si lo que tienes son llamadas directas entre tfnos sin pasar
por Asterisk (sólo por el proxy) el escenario no tiene nada que ver y
tendrás que mirar con cuidado qué es exactamente lo que pretendes. Si
haces un flow gráfico ne bonito de lo que intentas lograr y lo enseñas
aquí te podría dar mi opinión sobre su viabilidad.

Saludos.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Gelo]

> Ahora, si lo que tienes son llamadas directas entre tfnos sin pasar
> por Asterisk (sólo por el proxy) el escenario no tiene nada que ver y
> tendrás que mirar con cuidado qué es exactamente lo que pretendes. Si
> haces un flow gráfico ne bonito de lo que intentas lograr y lo enseñas
> aquí te podría dar mi opiniónsobre su viabilidad.

Nada más fácil, copio-pego del RFC 5589:

Transferor Transferee Transfer
(IPphone-Kamailio) (Asterisk) Target
| | (IPphone-Kamailio)
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2) F5
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (100 Trying)| |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog4 | INVITE (Replaces:dialog2)/200 OK/ACK F6
| |------------------->|
dialog2 | BYE/200 OK | |
|<----------------------------------------|
dialog3 | NOTIFY (200 OK) | |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |
dialog1 | BYE/200 OK | |
|------------------->| |
dialog4 | | BYE/200 OK |
| |<-------------------|

Lo anterior es lo esperado. Y esto es lo que pasa:

Transferor Transferee Transfer
(IPphone-Kamailio) (Asterisk) Target
| | (IPphone-Kamailio)
| | |
dialog1 | INVITE/200 OK/ACK F1 F2 |
|<-------------------| |
dialog1 | INVITE (hold)/200 OK/ACK |
|------------------->| |
dialog2 | INVITE/200 OK/ACK F3 F4 |
|---------------------------------------->|
dialog2 | INVITE (hold)/200 OK/ACK |
|---------------------------------------->|
dialog3 | REFER (Target-Dialog:1, |
| Refer-To:sips:TransferTarget?Replaces=2) F5
|------------------->| |
dialog3 | 202 Accepted | |
|<-------------------| |
dialog3 | NOTIFY (*481 Call leg does not exist*) |
|<-------------------| |
dialog3 | 200 OK | |
|------------------->| |

Cuando recibe el 202 Accepted, el teléfono libera la llamada, así que
Kamailio ya no le pasa el NOTIFY, sino que lo ack él mismo. Esto no sé
si debería ser así, la verdad, ¿igual el teléfono debería mantener los
diálogos hasta que le llegue el NOTIFY confirmando la transferencia?
En cualquier caso, Asterisk no estaría soportando el REFER
completamente, a mi entender.

Un saludo

[Iñaki Baz Castillo]

Hola, retomando este tema:

Creo que ahora lo entiendo, y en el fondo es normal: Asterisk sólo
soporta el REFER cuando se trata de diálogos en los que el propio
Asterisk estaba involucrado.

En tu caso, el tfno1 recibe una llamada de Asterisk, y luego inicia
una llamada directamente con tfno2 (una llamada que no pasa por
Asterisk).
Entonces tfno1 le manda un REFER a Asterisk en el contexto del primer
diálogo (llamada recibida) para que Asterisk haga la transferencia de
esa llamada entrante a tfno 2.

Bien, eso no va a funcionar, Asterisk sólo entiende las transferencias
si se refieren a diálogos existentes en el propio Asterisk, no sirve
si son diálogos externos a él (como en tu caso).

Asterisk está diseñado para ser el centro del universo, interopera
fatal con todo lo que no sea él mismo.

Por otra parte, a lo que yo me refería inicialmente era a que usando
un proxy delante de Asterisk, las transfernecias funcionan
perfectamente *siempre* que todas las llamadas pasen por Asterisk. Es
decir, en tu caso tfno1 recibe la llamada entrante de Asterisk (a
través del proxy), la contesta, y luego inicia una llamada con
Asterisk a la extensión de tfno2 (a través de Kamailio también). En
este caso el REFER funcionará pues menciona datos de un diálogo SIP
que existe en Asterisk.

Mi pésame ;)

--
Iñaki Baz Castillo
<i...@aliax.net>

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)

Entra ahora en el canal de irc de Asterisk-ES para charlar en directo sobre VoIP y
Asterisk: http://www.asterisk-es.org/

[Iñaki Baz Castillo]

El día 9 de mayo de 2010 02:18, Iñaki Baz Castillo <i...@aliax.net> escribió:
> Bien, eso no va a funcionar, Asterisk sólo entiende las transferencias
> si se refieren a diálogos existentes en el propio Asterisk, no sirve
> si son diálogos externos a él (como en tu caso).

Este hilo te resultará interesante:
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Load-Balancer-of-an-Asterisk-Cluster-REFER-Issue-td5008213.html

[Gelo]

Hola

Iba yo a contar el viernes mis avances; al final preferí esperar a
hacer algunos tests más, pero te respondo ya para no dejarte con la
palabra en la boca :)

Por las pruebas que he realizado, Asterisk SÍ permite hacer
transferencias a dialogs que no atraviesen por él. El truco es el
parámetro "domain", que le dice a Asterisk cuáles son sus dominios
locales. Si el dominio de destino de la transferencia lo tiene
Asterisk como local (si no configuras ninguno siempre lo toma como
local), supondrá que él tiene que tener la llamada, y cuando no la
encuentra es cuando devuelve el 481.

Yo tengo Kamailio y Asterisk en la misma máquina, así que lo que hice
fue un bind de Kamailio a una IP virtual (que tengo para alta
disponibilidad) y el Asterisk a la IP física, Una vez hecho esto, hice
una prueba con una llamada a un Playback en el Asterisk, y al realizar
la transferencia me devolvió un 503, con un mensaje que dice "not
possible to transfer one-legged calls", o algo así. Me fui al código y
encontré el punto en el que se envía ese mensaje; justo antes, hay un
comentario que explica que habría que realizar una llamada y luego
puentear los canales (ver flujo de llamada más arriba), acabando con
la frase, y cito: "Put your code here :)"

Esto, claro, desmoraliza, ya me veía yo programando. Pero una llamada
solo atraviesa por ahí si no está bridgeada (one-legged call), lo que
hace que si el Asterisk se utiliza como gateway hacia otras
tecnologías no sea un problema en absoluto (por demostrar). En
principio en mi solución el caso que veo en que puede fallar es en
transferencias hacia salas de conferencias, pero solo en el caso de
que se transfiera una sala a un canal, que no es el escenario
habitual.

No he probado aún si fallan las llamadas a través de colas, que sería
el caso más preocupante, aunque intuyo que una vez esté la llamada
establecida con un agente no debería haber problemas. Me falta también
hacer pruebas con más tecnologías (por ahora he probado en entornos
todo SIP), ahora mismo le enchufo una tarjeta a la máquina y miro. IAX
que lo pruebe otro, que a mi me da pereza.

Sobre el link que indicaste, yo intenté una solución con los profiles
del módulo dialogs de manera que si había una llamada establecida con
Asterisk a/desde un teléfono, la siguiente pasase por el Asterisk.
Pero no me vale de mucho, porque si la primera llamada no atraviesa
por Asterisk y la segunda sí, se dan condiciones en que falla.
También, me parece que el escenario que están discutiendo ahí no es
exactamente el mismo que tengo yo, y hacen cosas que no me explico
para qué...

Antes de que me echéis la bronca si probáis esto y no funciona, repito
que aún no he hecho pruebas exhaustivas. Si alguien me dice una
condición de llamada puenteada en que falle, agradecido.

Saludos

[Iñaki Baz Castillo]

El día 10 de mayo de 2010 10:40, Gelo <gel...@gmail.com> escribió:
> Por las pruebas que he realizado, Asterisk SÍ permite hacer
> transferencias a dialogs que no atraviesen por él. El truco es el
> parámetro "domain", que le dice a Asterisk cuáles son sus dominios
> locales. Si el dominio de destino de la transferencia lo tiene
> Asterisk como local (si no configuras ninguno siempre lo toma como
> local), supondrá que él tiene que tener la llamada, y cuando no la
> encuentra es cuando devuelve el 481.

Ajá, interesante, aunque me parece demasiado "frágil" tener que
basarse en los dominios ya que yo podría querer usar un único dominio
incluso aunque la llamada llegue a Asterisk.

> Yo tengo Kamailio y Asterisk en la misma máquina, así que lo que hice
> fue un bind de Kamailio a una IP virtual (que tengo para alta
> disponibilidad) y el Asterisk a la IP física, Una vez hecho esto, hice
> una prueba con una llamada a un Playback en el Asterisk, y al realizar
> la transferencia me devolvió un 503, con un mensaje que dice "not
> possible to transfer one-legged calls", o algo así. Me fui al código y
> encontré el punto en el que se envía ese mensaje; justo antes, hay un
> comentario que explica que habría que realizar una llamada y luego
> puentear los canales (ver flujo de llamada más arriba), acabando con
> la frase, y cito: "Put your code here :)"

"Put your code here... and cross one's fingers" :)

--
Iñaki Baz Castillo
<i...@aliax.net>