[OpenSER-Users-ES] ¿ CPL ?
Jesus Rodriguez
jesusr at voztele.com
Thu Nov 15 14:27:09 CET 2007
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:
>>>
>>>
>>> 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).
>>
>> 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.
>>> 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...
>>
>> 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 at 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 at domain.org redirige sus incomings a User_B at domain.org
> (regla de mismo
> dominio respetada).
> - User_B at domain.org no permite entrantes a usuarios del dominio
> "extern.com".
> - other at extern.com llama a User_A at domain.org, se procesa el CPL de
> User_A y la
> llamada hace una espiral con URI = User_B at 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 at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
More information about the Users-es
mailing list