Hola, se me plantea una duda:
Ahora mismo cuando se llama a un usuario se mira si tiene CPL y si no lo tiene se prosigue con un "lookup(location)" y tal. Lo malo de esto es que me obliga a replicar código para ambos casos:
Por ejemplo, en el CPL uso "proxy_recurse" por lo que si durante el CPL recibo un 302 automáticamente genero un branch al Contact en vez de reenviar el 302 al llamante.
Pero si no hay CPl entonces tengo que andar trasteando con el onreply_route y la función "get_contacts" para emular ese mismo comportamiento en caso de recibir un 302.
Entonces se me estaba ocurriendo que en el INVITE hacer un: does_uri_exist() y en ese caso buscar CPL del usuario llamado, y si no existe CPL responder con 404 (y no hacer un lookup).
Así simplifico código y lógica, pero lo malo es que tal vez ejecutar un CPL siempre cuando resulta que puede que sólo tenga un triste:
<cpl> <incoming> <lookup source="registration"> <success> <proxy /> </success> </lookup> </incoming> </cpl>
Pues igual resulta que es un poco derroche de procesador, ¿no?
Bueno, en cualquier caso creo que lo haré, salvo que alguien me comente que es una locura usar CPL para cada llamada a un usuario. ;)
Saludos y gracias.
Hola Iñaki,
Hola, se me plantea una duda:
Ahora mismo cuando se llama a un usuario se mira si tiene CPL y si no lo tiene se prosigue con un "lookup(location)" y tal. Lo malo de esto es que me obliga a replicar código para ambos casos:
Por ejemplo, en el CPL uso "proxy_recurse" por lo que si durante el CPL recibo un 302 automáticamente genero un branch al Contact en vez de reenviar el 302 al llamante.
Pero si no hay CPl entonces tengo que andar trasteando con el onreply_route y la función "get_contacts" para emular ese mismo comportamiento en caso de recibir un 302.
Entonces se me estaba ocurriendo que en el INVITE hacer un: does_uri_exist() y en ese caso buscar CPL del usuario llamado, y si no existe CPL responder con 404 (y no hacer un lookup).
Así simplifico código y lógica, pero lo malo es que tal vez ejecutar un CPL siempre cuando resulta que puede que sólo tenga un triste:
<cpl> <incoming> <lookup source="registration"> <success> <proxy /> </success> </lookup> </incoming> </cpl>
Pues igual resulta que es un poco derroche de procesador, ¿no?
Bueno, en cualquier caso creo que lo haré, salvo que alguien me comente que es una locura usar CPL para cada llamada a un usuario. ;)
Si lo he entendido bien, ¿por qué no añades a los usuarios con CPL a un grupo "cpl" y antes de ejecutarlo miras si un usuario está en el grupo o no?.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
On Thursday 03 January 2008 17:43:43 Jesus Rodriguez wrote:
Entonces se me estaba ocurriendo que en el INVITE hacer un: does_uri_exist() y en ese caso buscar CPL del usuario llamado, y si no existe CPL responder con 404 (y no hacer un lookup).
Si lo he entendido bien, ¿por qué no añades a los usuarios con CPL a un grupo "cpl" y antes de ejecutarlo miras si un usuario está en el grupo o no?.
Es que en realidad quiero básicamente lo mismo para todos los usuarios. Vuelvo al ejemplo del 302:
Me interesa que si un usuario devuelve un 302 desde su teléfono entonces OpenSer se lo coma y genere un branch al "Contact" en vez de reenviar el 302 al llamante.
Eso lo puedo hacer con CPL sin más que poner "proxy_recurse", así que si un usuario tiene CPL no necesito hacer nada más (siempre que busque el registro del usuario dentro del propio CPL).
Pero si permito usuarios sin CPL entonces el tema de recoger el 302 y generar un branch lo tengo que hacer en un "onreply_route" y sería más lioso.
Por eso digo de forzar a que todos los usuarios tengan CPL, es más, el lookup(location) sólo se haría dento del CPL (bueno, claro, para enviar un OPTIONS y tal vez un MESSAGE no usaré CPL y sí lookup(location)...).
No sé si me he explicado mejor ahora ;)
Saludos.
Hola Iñaki,
On Thursday 03 January 2008 17:43:43 Jesus Rodriguez wrote:
Entonces se me estaba ocurriendo que en el INVITE hacer un: does_uri_exist() y en ese caso buscar CPL del usuario llamado, y si no existe CPL responder con 404 (y no hacer un lookup).
Si lo he entendido bien, ¿por qué no añades a los usuarios con CPL a un grupo "cpl" y antes de ejecutarlo miras si un usuario está en el grupo o no?.
Es que en realidad quiero básicamente lo mismo para todos los usuarios. Vuelvo al ejemplo del 302:
Me interesa que si un usuario devuelve un 302 desde su teléfono entonces OpenSer se lo coma y genere un branch al "Contact" en vez de reenviar el 302 al llamante.
Eso lo puedo hacer con CPL sin más que poner "proxy_recurse", así que si un usuario tiene CPL no necesito hacer nada más (siempre que busque el registro del usuario dentro del propio CPL).
Pero si permito usuarios sin CPL entonces el tema de recoger el 302 y generar un branch lo tengo que hacer en un "onreply_route" y sería más lioso.
Por eso digo de forzar a que todos los usuarios tengan CPL, es más, el lookup(location) sólo se haría dento del CPL (bueno, claro, para enviar un OPTIONS y tal vez un MESSAGE no usaré CPL y sí lookup(location)...).
No sé si me he explicado mejor ahora ;)
O quizás es que yo lo he entendido mejor :) ... yo creo que poner el CPL para todos los usuarios no es problema y te ahorras código. El único problema sería que limitas el control que tienes sobre la llamada porque una vez se la entregas al CPL él se lo guisa y se lo come.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Viernes, 4 de Enero de 2008, Jesus Rodriguez escribió:
O quizás es que yo lo he entendido mejor :) ... yo creo que poner el CPL para todos los usuarios no es problema y te ahorras código.
Aclarado, pues así será ;)
El único problema sería que limitas el control que tienes sobre la llamada porque una vez se la entregas al CPL él se lo guisa y se lo come.
Pues en realidad no me parece que haya mucha limitación ya que gracias al parámetro:
# route de salida desde el CPL (pasa cada posible branch por separado). modparam("cpl-c","proxy_route", 10)
Entonces al salir del CPL se pasa el control al route[10] (cada branch por separado, aunque hay un bug [1] al respecto y se hace necesario usar a su vez un "t_on_branch"), de tal forma que puedo mirar los bflags, aplicar RtpProxy, rutar al servidor de voicemail si el nuevo RURI username es "voicemail" (como fruto de un forwarding o incluso un 302 del UAC...).
Es decir, yo no veo mucha limitación, salvo ésta [2] (que según Bogdan será mejorada.
[1] https://sourceforge.net/tracker/?func=detail&aid=1857603&group_id=13... [2] https://sourceforge.net/tracker/?func=detail&aid=1862712&group_id=13...
Saludos.
El Viernes, 4 de Enero de 2008, Iñaki Baz Castillo escribió:
# route de salida desde el CPL (pasa cada posible branch por separado). modparam("cpl-c","proxy_route", 10)
Entonces al salir del CPL se pasa el control al route[10] (cada branch por separado
Es más, yo tengo puesto:
modparam("cpl-c","proxy_route", 10)
...
# ----------------------------------------------------------------- # CPL out: # ----------------------------------------------------------------- # Al ejecutarse el CPL se sale por este route. route[10] {
t_on_branch("10"); t_on_reply("1"); t_on_failure("1");
}
Y con eso más o menos puedo controlarlo todo XD
Hola Iñaki,
El Viernes, 4 de Enero de 2008, Jesus Rodriguez escribió:
El único problema sería que limitas el control que tienes sobre la llamada porque una vez se la entregas al CPL él se lo guisa y se lo come.
Pues en realidad no me parece que haya mucha limitación ya que gracias al parámetro:
# route de salida desde el CPL (pasa cada posible branch por separado). modparam("cpl-c","proxy_route", 10)
Entonces al salir del CPL se pasa el control al route[10] (cada branch por separado, aunque hay un bug [1] al respecto y se hace necesario usar a su vez un "t_on_branch"), de tal forma que puedo mirar los bflags, aplicar RtpProxy, rutar al servidor de voicemail si el nuevo RURI username es "voicemail" (como fruto de un forwarding o incluso un 302 del UAC...).
Es decir, yo no veo mucha limitación, salvo ésta [2] (que según Bogdan será mejorada.
Mmmmm... aún así se que hay cosas que no se pueden hacer, pero no recuerdo cuales :) ... lo miraré y si lo encuentro lo pongo por aquí.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
On Monday 07 January 2008 11:34:13 Jesus Rodriguez wrote:
Hola Iñaki,
El Viernes, 4 de Enero de 2008, Jesus Rodriguez escribió:
El único problema sería que limitas el control que tienes sobre la llamada porque una vez se la entregas al CPL él se lo guisa y se lo come.
Pues en realidad no me parece que haya mucha limitación ya que gracias al parámetro:
# route de salida desde el CPL (pasa cada posible branch por separado). modparam("cpl-c","proxy_route", 10)
Entonces al salir del CPL se pasa el control al route[10] (cada branch por separado, aunque hay un bug [1] al respecto y se hace necesario usar a su vez un "t_on_branch"), de tal forma que puedo mirar los bflags, aplicar RtpProxy, rutar al servidor de voicemail si el nuevo RURI username es "voicemail" (como fruto de un forwarding o incluso un 302 del UAC...).
Es decir, yo no veo mucha limitación, salvo ésta [2] (que según Bogdan será mejorada.
Mmmmm... aún así se que hay cosas que no se pueden hacer, pero no recuerdo cuales :) ... lo miraré y si lo encuentro lo pongo por aquí.
Pues te lo agradeeré mucho ;)
El Lunes, 7 de Enero de 2008, Iñaki Baz Castillo escribió:
Mmmmm... aún así se que hay cosas que no se pueden hacer, pero no recuerdo cuales :) ... lo miraré y si lo encuentro lo pongo por aquí.
Pues te lo agradeeré mucho ;)
Una pega que le veo es que, tras el CPL, no hay forma de saber si se ha producido con éxito el <lookup source="registration">, bueno, la única forma es hacer: is_uri_host_local() lo cuál conlleva una consula SQL (o a memoria). Es decir, si se ha buscado la localización del AoR entonces esa función "is_uri_host_local()" devolverá "FALSE" ya que el nuevo dominio será la IP donde está registrado el usuario llamado.
Pero bueno, no es muy grave. :)
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez