Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo al RFC de CPL (los ejemplos básicamente XD): http://www.faqs.org/rfcs/rfc3880.html
Tengo algunas cuestiones sobre ello:
1) ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la configuración de un tfno te diese la opción de subir las preferencias (desvío condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así en el caso de éste teléfono (esta branch).
2) ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a alguna especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e implemente redirecciones, desvíos, bloqueos...
Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER (como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda así en la tabla, lo que luego es más eficiente en su lectura. En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla no se pasa a binario.
Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué hay de los flags, los branch_route y todo eso? por ejemplo: Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale la llamada por el branch_route? ¿o una vez que entra en el CPL queda al margen de script? también he oído sobre problemas para tratar el NAT y así.
En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias.
PD: ¿Se usa el CPL en la vida real?
Hola,
Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo al RFC de CPL (los ejemplos básicamente XD): http://www.faqs.org/rfcs/rfc3880.html
Tengo algunas cuestiones sobre ello:
- ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la
configuración de un tfno te diese la opción de subir las preferencias (desvío condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así en el caso de éste teléfono (esta branch).
Que yo sepa no. Sólo se puede subir directamente al servidor.
- ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a
alguna especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e implemente redirecciones, desvíos, bloqueos...
Eso si que funciona en Openser. Puedes hacer unas cuantas cosas.
Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER (como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda así en la tabla, lo que luego es más eficiente en su lectura. En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla no se pasa a binario.
Sí que lo mete en binario si usas el comando:
openserctl fifo LOAD_CPL
Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué hay de los flags, los branch_route y todo eso? por ejemplo: Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale la llamada por el branch_route? ¿o una vez que entra en el CPL queda al margen de script? también he oído sobre problemas para tratar el NAT y así.
Sí. Cuando una llamada entra en el CPL queda al margen del script y pierdes el control. Lo que puedes hacer es una espiral de forma que el CPL envia la llamada de nuevo al proxy y usas algún parámetro para marcar que esa llamada no tiene que ejecutar el CPL.
En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias.
PD: ¿Se usa el CPL en la vida real?
Yo se al menos de un caso dónde sí se usa ;-)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Lunes, 12 de Noviembre de 2007, Jesus Rodriguez escribió:
Hola,
Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo al RFC de CPL (los ejemplos básicamente XD): http://www.faqs.org/rfcs/rfc3880.html
Tengo algunas cuestiones sobre ello:
- ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la
configuración de un tfno te diese la opción de subir las preferencias (desvío condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así en el caso de éste teléfono (esta branch).
Que yo sepa no. Sólo se puede subir directamente al servidor.
O sea, que no hay ningún cliente SIP que envíe un XML-CPL en el REGISTER. :(
- ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a
alguna especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e implemente redirecciones, desvíos, bloqueos...
Eso si que funciona en Openser. Puedes hacer unas cuantas cosas.
Pero ¿entonces no pierde algo de gracia? o sea, se supone que el proxy recibe el CPL en un REGISTER y lo examina (pudiéndolo rechazar si es incorrecto o mal formado). En cambio si lo subes directamente a BD a las bravas ese test previo se pierde e incluso podría fallar OpenSer al interpretar el CML, ¿no?
Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER (como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda así en la tabla, lo que luego es más eficiente en su lectura. En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla no se pasa a binario.
Sí que lo mete en binario si usas el comando:
openserctl fifo LOAD_CPL
Esa es buena ;)
Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué hay de los flags, los branch_route y todo eso? por ejemplo: Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale la llamada por el branch_route? ¿o una vez que entra en el CPL queda al margen de script? también he oído sobre problemas para tratar el NAT y así.
Sí. Cuando una llamada entra en el CPL queda al margen del script y pierdes el control. Lo que puedes hacer es una espiral de forma que el CPL envia la llamada de nuevo al proxy y usas algún parámetro para marcar que esa llamada no tiene que ejecutar el CPL.
Hasta donde yo sé, la única forma de pasar un parámetro en una espiral es a través de una cabecera o tag.
Pero lo que no entiendo es cómo forzar una espiral. O sea, ¿cómo puedo controlar a dónde se envía el mensaje SIP? ¿cómo puedo controlar el "location" que pone un usuario en su CPL?
¿O acaso estamos hablando de dar inteligencia de control en la aplicación que genera el CPL-XML y restringir con ella las posibilidades? Por ejemplo, se me ocurre que un usuario sólo puede redirigirse a otros usuarios de su propio dominio (controlamos esto en la aplicación web que genera el CPL) de tal forma que necesariamente se producirá una espiral y el mensaje llegará de nuevo al proxy, pero antes de haber leído el CPL se introdujo una cabecera "X-CPL-processed" y ahora no se procesa.
Pero tampoco me sirve, porque:
- User_A@domain.org redirige sus incomings a User_B@domain.org (regla de mismo dominio respetada). - User_B@domain.org no permite entrantes a usuarios del dominio "extern.com". - other@extern.com llama a User_A@domain.org, se procesa el CPL de User_A y la llamada hace una espiral con URI = User_B@domain.org (y se añade una cabecera "X-CPL-Processed"). - Ahora no se interpreta el CPL de User_B pues lleva cabecera. - La llamada llega a User_B que se quejará y con razón ("esto no funciona, oiga").
Es decir, no imagino forma de hacer que el mensaje se procese finalmente **sólo** por OpenSer (script) sin vulnerar y sacrificar posibles reglas.
¿Alguna pista más? :)
En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias.
PD: ¿Se usa el CPL en la vida real?
Yo se al menos de un caso dónde sí se usa ;-)
Vaya, y yo que después de leerme justo ahora el RFC 3880 estaba a punto de descartar el CPL dada su complejidad (¡¡¡pero alguien ha mirado el tema de las fechas y horarios!!!)... y resulta que sí se usa... no sé si alegrarme XDDD
Y claro, ahora toca currarse la aplicación que interprete un CPL-XML y todo... buffff... qué de cosas.
Mil gracias por todo. ;)
El Tuesday 13 November 2007 00:05:37 Iñaki Baz Castillo escribió:
Pero tampoco me sirve, porque:
- User_A@domain.org redirige sus incomings a User_B@domain.org (regla de
mismo dominio respetada).
- User_B@domain.org no permite entrantes a usuarios del dominio
"extern.com". - other@extern.com llama a User_A@domain.org, se procesa el CPL de User_A y la llamada hace una espiral con URI = User_B@domain.org (y se añade una cabecera "X-CPL-Processed").
- Ahora no se interpreta el CPL de User_B pues lleva cabecera.
- La llamada llega a User_B que se quejará y con razón ("esto no funciona,
oiga").
Es decir, no imagino forma de hacer que el mensaje se procese finalmente **sólo** por OpenSer (script) sin vulnerar y sacrificar posibles reglas.
Ops, tal vez si en la cabecera pongo el usuario para el que ya se ha procesado su CPL y así sólo interpreto el CPL de un usuario para el que no se haya procesado ya.
Pero...
- User_A desvía siempre a User_B. - User_B desvía siempre a User_A. - La llamada llega entonces a User_A pues en su segunda llegada no se interpreta su CPL.
Bueno, que lo tengo que pensar más antes de preguntar tanto ;)
Saludos.
Hola Iñaki,
El Lunes, 12 de Noviembre de 2007, Jesus Rodriguez escribió:
Hola,
Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo al RFC de CPL (los ejemplos básicamente XD): http://www.faqs.org/rfcs/rfc3880.html
Tengo algunas cuestiones sobre ello:
- ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la
configuración de un tfno te diese la opción de subir las preferencias (desvío condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así en el caso de éste teléfono (esta branch).
Que yo sepa no. Sólo se puede subir directamente al servidor.
O sea, que no hay ningún cliente SIP que envíe un XML-CPL en el REGISTER. :(
Yo no conozco ninguno.
- ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a
alguna especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e implemente redirecciones, desvíos, bloqueos...
Eso si que funciona en Openser. Puedes hacer unas cuantas cosas.
Pero ¿entonces no pierde algo de gracia? o sea, se supone que el proxy recibe el CPL en un REGISTER y lo examina (pudiéndolo rechazar si es incorrecto o mal formado). En cambio si lo subes directamente a BD a las bravas ese test previo se pierde e incluso podría fallar OpenSer al interpretar el CML, ¿no?
Sí, podria ser. La idea es tener una plantilla que sabes que funciona en la que ofreces las funcionalidades que quieras. Después, mediante una aplicación web o cualquier otro sistema sustituyes los valores de la plantilla por las preferencias del usuario.
Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER (como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda así en la tabla, lo que luego es más eficiente en su lectura. En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla no se pasa a binario.
Sí que lo mete en binario si usas el comando:
openserctl fifo LOAD_CPL
Esa es buena ;)
Ahh... openserctl tiene varias sorpresas escondidas ;)
Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué hay de los flags, los branch_route y todo eso? por ejemplo: Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale la llamada por el branch_route? ¿o una vez que entra en el CPL queda al margen de script? también he oído sobre problemas para tratar el NAT y así.
Sí. Cuando una llamada entra en el CPL queda al margen del script y pierdes el control. Lo que puedes hacer es una espiral de forma que el CPL envia la llamada de nuevo al proxy y usas algún parámetro para marcar que esa llamada no tiene que ejecutar el CPL.
Hasta donde yo sé, la única forma de pasar un parámetro en una espiral es a través de una cabecera o tag.
Pero lo que no entiendo es cómo forzar una espiral. O sea, ¿cómo puedo controlar a dónde se envía el mensaje SIP? ¿cómo puedo controlar el "location" que pone un usuario en su CPL?
Puedes hacer algo como:
<location url="sip:usuario@tudominio.com;cpl=no">
Y después, en el script de configuración:
if uri_param("cpl","no") { ....
Así sabes en la espiral que no tienes que volver a ejecutar el cpl... o montas un bucle de cuidado! :)
¿O acaso estamos hablando de dar inteligencia de control en la aplicación que genera el CPL-XML y restringir con ella las posibilidades? Por ejemplo, se me ocurre que un usuario sólo puede redirigirse a otros usuarios de su propio dominio (controlamos esto en la aplicación web que genera el CPL) de tal forma que necesariamente se producirá una espiral y el mensaje llegará de nuevo al proxy, pero antes de haber leído el CPL se introdujo una cabecera "X-CPL-processed" y ahora no se procesa.
Sí, es lo que te comentaba antes de usar una plantilla para generar el CPL con una aplicación.
Pero tampoco me sirve, porque:
- User_A@domain.org redirige sus incomings a User_B@domain.org
(regla de mismo dominio respetada).
- User_B@domain.org no permite entrantes a usuarios del dominio
"extern.com".
- other@extern.com llama a User_A@domain.org, se procesa el CPL de
User_A y la llamada hace una espiral con URI = User_B@domain.org (y se añade una cabecera "X-CPL-Processed").
- Ahora no se interpreta el CPL de User_B pues lleva cabecera.
- La llamada llega a User_B que se quejará y con razón ("esto no
funciona, oiga").
Es decir, no imagino forma de hacer que el mensaje se procese finalmente **sólo** por OpenSer (script) sin vulnerar y sacrificar posibles reglas.
¿Alguna pista más? :)
Puedes usar los parámetros "incoming" y "outgoing" en la función cpl_run_script.
En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias.
PD: ¿Se usa el CPL en la vida real?
Yo se al menos de un caso dónde sí se usa ;-)
Vaya, y yo que después de leerme justo ahora el RFC 3880 estaba a punto de descartar el CPL dada su complejidad (¡¡¡pero alguien ha mirado el tema de las fechas y horarios!!!)... y resulta que sí se usa... no sé si alegrarme XDDD
Y claro, ahora toca currarse la aplicación que interprete un CPL-XML y todo... buffff... qué de cosas.
Je, je... la vida del SIP es dura!! :)
P.D. Depende de las ganas que tengas de programar, WeSIP (o cualquier otro servidor de apliaciones SIP) es una buena alternativa a CPL.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Thursday 15 November 2007 14:27:09 Jesus Rodriguez escribió:
Pero ¿entonces no pierde algo de gracia? o sea, se supone que el proxy recibe el CPL en un REGISTER y lo examina (pudiéndolo rechazar si es incorrecto o mal formado). En cambio si lo subes directamente a BD a las bravas ese test previo se pierde e incluso podría fallar OpenSer al interpretar el CML, ¿no?
Sí, podria ser. La idea es tener una plantilla que sabes que funciona en la que ofreces las funcionalidades que quieras. Después, mediante una aplicación web o cualquier otro sistema sustituyes los valores de la plantilla por las preferencias del usuario.
Entendido.
Pero lo que no entiendo es cómo forzar una espiral. O sea, ¿cómo puedo controlar a dónde se envía el mensaje SIP? ¿cómo puedo controlar el "location" que pone un usuario en su CPL?
Puedes hacer algo como:
<location url="sip:usuario@tudominio.com;cpl=no">
Y después, en el script de configuración:
if uri_param("cpl","no") { ....
Esa es muy buena, pero... ¿y el spoofing? O sea, ¿y si un listillo mete ese parámetro "cpl=no"? es que ya me veo comprobando cabeceras y parámetros en el URI para evitar "ataques". Pero vamos, que supongo que eso es lo que hay.
P.D. Depende de las ganas que tengas de programar, WeSIP (o cualquier otro servidor de apliaciones SIP) es una buena alternativa a CPL.
Con la salvedad de que no existe ningún otro servidor de aplicaciones SIP viable, ¿no? XD
Gracias.
Hola Iñaki,
El Thursday 15 November 2007 14:27:09 Jesus Rodriguez escribió:
Pero ¿entonces no pierde algo de gracia? o sea, se supone que el proxy recibe el CPL en un REGISTER y lo examina (pudiéndolo rechazar si es incorrecto o mal formado). En cambio si lo subes directamente a BD a las bravas ese test previo se pierde e incluso podría fallar OpenSer al interpretar el CML, ¿no?
Sí, podria ser. La idea es tener una plantilla que sabes que funciona en la que ofreces las funcionalidades que quieras. Después, mediante una aplicación web o cualquier otro sistema sustituyes los valores de la plantilla por las preferencias del usuario.
Entendido.
Pero lo que no entiendo es cómo forzar una espiral. O sea, ¿cómo puedo controlar a dónde se envía el mensaje SIP? ¿cómo puedo controlar el "location" que pone un usuario en su CPL?
Puedes hacer algo como:
<location url="sip:usuario@tudominio.com;cpl=no">
Y después, en el script de configuración:
if uri_param("cpl","no") { ....
Esa es muy buena, pero... ¿y el spoofing? O sea, ¿y si un listillo mete ese parámetro "cpl=no"? es que ya me veo comprobando cabeceras y parámetros en el URI para evitar "ataques". Pero vamos, que supongo que eso es lo que hay.
Puedes hacer algo muy sencillo como:
if (src_ip==myself && src_port==5060) { ...
para comprobar que esta request viene de la espiral.
P.D. Depende de las ganas que tengas de programar, WeSIP (o cualquier otro servidor de apliaciones SIP) es una buena alternativa a CPL.
Con la salvedad de que no existe ningún otro servidor de aplicaciones SIP viable, ¿no? XD
:-)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Thursday 15 November 2007 18:12:18 Jesus Rodriguez escribió:
if uri_param("cpl","no") { ....
Esa es muy buena, pero... ¿y el spoofing? O sea, ¿y si un listillo mete ese parámetro "cpl=no"? es que ya me veo comprobando cabeceras y parámetros en el URI para evitar "ataques". Pero vamos, que supongo que eso es lo que hay.
Puedes hacer algo muy sencillo como:
if (src_ip==myself && src_port==5060) { ...
para comprobar que esta request viene de la espiral.
Sí, eso mismo hago ya para dar veracidad a cabeceras añadidas en mi OpenSer antes de la espiral. Si sólo es un servidor pues bueno, más o menos es mantenible. Pero si nos ponemos en un escenario "made in país de la piruleta IEFT" con múltiples servidores cada uno con su IP y blablabla... bufff... por suerte esas cosas no existen XD
El Jueves, 15 de Noviembre de 2007, Jesus Rodriguez escribió:
Puedes hacer algo como:
<location url="sip:usuario@tudominio.com;cpl=no">
Y después, en el script de configuración:
if uri_param("cpl","no") { ....
Estoy ahora probando los CPL y mola bastante.
Además creo que ya le he pillado el truco en cuanto a que no hay que hacer: <lookup source="registration"> sino: <location url="sip:mismo_usuario_llamado@dominio;cpl=no"> es decir, forzar el loop para poder rutarlo con los branch routes y todo lo que queramos.
El <lookup source="registration"> te hace el lookup dentro del CPL y no te deja jugar con los branchs y tal. Bueno, en realidad sí te deja si pones el parámetro: modparam("cpl-c","proxy_route",1) Entonces antes de rutar el paquete pasa por "route[1]" en el cual puedes llamar a on_brach_route y todo eso para temas de RtpProxy y demás. Lo malo es que dento de ese route[1] no puedes hacer un t_relay (necesario en el failure_route si usas LCR - next_contacts() para serial forwarding segun "q"), así que te limita un poco.
Por eso creo que mejor forzar el loop y mirar ;cpl=no para no aplicar dos veces el mismo CPL.
Buff, qué chapa he soltado... en realidad son como mis notas, para que no se me olvide ;)
Saludos.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez