XCAP. Ejemplos y utilidad
Francisco José Méndez Cirera
XCAP, al menos en relación con SIP, se utiliza como un servicio adicional que trabaja conjuntamente con el proxy SIP, para manejar la lista de subscripciones, como la política de estas (hasta donde yo conozco). Si no recuerdo mal uno de los ejemplos útiles que leí, es que mediante un server XCAP y el proxy SIP era posible notificar los cambios de un dispositivo, sólo a aquellos que han sido especificados en el servicio XCAP por el dispositivo. Por ejemplo, puede que en un determinado momento quieres que un compañero pueda saber si estas libre o estás ocupado, mientras que para otra persona siempre muestras que tu estado es ocupado. La verdad es que me parece muy muy interesante :)
Ahora, la pregunta que me surge es... ¿Podeis darme más ejemplos de uso como el que acabo de citar? Ejemplos cotidiandos donde realmente se vea la utilidad del "XCAP server". Ejemplo tanto a nivel de política como de manejo de "buddy lists". Entiendo que las posibilidades están ligadas a la aplicación en sí, pero bueno, me gustaría conocer más ejemplos de uso.
Muchisimas gracias.
--
Francisco José Méndez Cirera
Mende...@gmail.com "sin la C ni ná"
Iñaki Baz Castillo
XCAP es simplemente un protocolo para que un cliente maneje documentos
(normalmente ficheros XML) que guarda en un servidor (servidor XCAP).
XCAP hace uso de HTTP para subir, bajar y borrar documentos (PUT, GET y
DELETE) y XPATH [*] para obtener, subir o borrar elementos dentro del propio
documento XML (ejemplo: añadir un contacto más sin tener que subir todo el
documento entero de nuevo).
Las aplicaciones típicas son:
- XML Formats for Representing Resource Lists (RFC 4826):
Un formato XMl para guardar contactos SIP, nada más. Se guardan categorizados
en "listas" dentro del propio documento.
- Presence Authorization Rules (RFC 5025):
Un formato XML para expresar reglas sobre quién puede ver nuestro estado de
presencia (igualito que en el Messenger o en XMPP cuando "bloqueas" a un
usuario para que no sepa que estás online).
- XCAP Usage for Manipulating Presence Document Contents (RFC 4827):
Consiste simplemente en que el cliente XCAP sube un documento XMl de
presencia, *igualito* (o similar) que el que puede enviar mediante un PUBLISH.
La diferencia es que el documento guardado en el servidor XCAP no expira y es
estático. Util si te vas de vacaciones y quieres que los que se subscriben a
tu presencia vean que estás "offline" con un mensaje "Estoy de vacas!!!" y con
una foto en plan playero.
Una explicación que a mí me parece interesante es la de cómo añadir a un
contacto y permitirle ver nuestro estado cuando se subscribe a nuestra
presencia:
- Bob arranca su teléfono y envía un SUBSCRIBE "Event: presence.winfo" [*]
para recibir notificaciones sobre quié se subscribe a su estado de presencia.
- Alice añade a Bob en sus contactos y su tfno SIP envía un SUBSCRIBE para ver
la presencia de Bob.
- El servidor de presencia hace una consulta XCAP al servidor XCAP para ver
las reglas que ha subido Bob, y ve que no está permitido, así que le devuelve
a Alice un NOTIFY con "Subscription-status: pending".
- Además, el servidor de presencia notifica (NOTIFY) a Bob que Alice se ha
subscrito a su presencia.
- El tfno de Bob muestra en pantalla al usuario "Alice le ha añadido a su
agenda de contactos, ¿quire que Alice pueda ver su estado de presencia?".
- El usuario responde que sí. El teléfono inmediatamente usa XCAP para añadir
ese contacto en la lista de pres-rules, y lo sube al servidor XCAP (o lo sube
entero todo el documento o hace un "update" de la parte específica).
- El servidor XCAP lo recibe y notifica al servidor de presencia (mediante un
protocolo propietario o mediante un PUBLISH SIP con evento "xcapdiff") que ha
habido un cambio en las reglas de pres-rules de Bob. Por lo que el servidor de
presencia las examina de nuevo y al ver que "Alice" estaba "pending" y que
ahora en el documento está "allowed" entonces permite la subscripción y envía
un NOTIFY "Subscription-Status: active" a Alice conteniendo la presencia de
Bob ("online", "en casa de copas...").
- Además, seguramente al permitir Bob a Alice, el propio tfno de Bob habrá
añadido a Alice a su agenda de contactos/buddiesy también habrá enviaod un
SUBSCRIBE para ver la presencia de Alice por lo que todo el proceso se repite
a la inversa.
:)
Y ya puesto un poco de auto-bombo:
Recientemente he publicado una librería XCAP cliente en Ruby que funciona
estupendamente :)
http://dev.sipdoc.net/projects/ruby-xcapclient/wiki
http://xcapclient.rubyforge.org/
Saludos.
[*] XPATH: http://www.sidar.org/recur/desdi/traduc/es/xml/xpath.html
[*] RFC 3857 (A Watcher Information Event Template-Package for SIP):
http://tools.ietf.org/html/rfc3857
--
Iñaki Baz Castillo <i...@aliax.net>
Francisco José Méndez Cirera
Por lo que puedo deducir, respecto a las "Presence Authorization Rules" es siempre la típica de permitir o no permitir que un determinado usuario conozca tu estado. Estoy dandole vueltas al tema (demasiadas diria yo), pero la verdad, que no se me ocurre otro tipo de "rule".
Muchas gracias.
Iñaki Baz Castillo
> Iñaki :) , eres un crack. Muchas gracias, nunca falta tu ejemplo que lo
> explica todo perfecto :)
>
> Por lo que puedo deducir, respecto a las "Presence Authorization Rules" es
> siempre la típica de permitir o no permitir que un determinado usuario
> conozca tu estado. Estoy dandole vueltas al tema (demasiadas diria yo),
> pero la verdad, que no se me ocurre otro tipo de "rule".
Sí, es básicamente eso, lo que pasa es que se puede complicar un poco más ya
que el RFC 5025 (pres-rules) permite restringir sólo cierta información a
según qué usuario y demás florituras (ejemplo: que Alice vea mi estado
"online" o "offline" pero que no vea mi comentario personal "estoy de
parranda!").
La mala noticia es que, de por sí sólos, todos los RFC's que te indicaba antes
(y sobre todo el de pres-rules) son increible y exageradamente flexibles, pero
para mal. O sea, realmente no definen un documento estricto que cualquier
cliente podría interpretar *para interoperar* sino que el XML schemma del
pres-rules es muy muy permisivo.
Esto significa que, sólo con dichas especificaciones, es imposible esperar que
Counterpath dé soporte XCAP a sus softphones y que los documentos que dichos
softphones manejan (y esperan recibir) sean válidos para softphones de otro
fabricante. IMPOSIBLE. Y de hecho no encontrarás hoy en día dos softphones
cuya implementación XCAP interopere. Lo juro.
Por esa razón, en el mundo IMS (SIP para los móviles, más o menos) están OMA
(OpenMobilleAlliance) y RCS (Realtimenosequé...) sacando especificaciones más
concretas de los RFC's de arriba, es decir, un formato de XML más específico
con unas reglas y secciones claras, una especie de subconjunto del XML schemma
definido en el RFC 5025. De esta forma todos los móviles IMS sabrán
interpretar dichos documentos estandarizados por el OMA y/o RCS o las siglas
que sean (que estoy super rallado con tantas siglas).
Al final esto significa que el IETF ha hecho un trabajo a medias, lo que me
parece fatal, ya que sus especificaciones sólo tendrán validez cuando una
asociación de fabricantes (y aquí nos salimos del mundo Internet) añadan una
capa de especificaciones por encima para tener algo funcional en su
chiringuito/business (IMS) en el que *sólo* ellos tienen cabida.
Realmente me parece lamentable la actitud del IETF en este asunto, sacando
especificaciones que, de por sí solas, no valen para nada.
Francisco José Méndez Cirera
Iñaki Baz Castillo
> Por lo que veo van entonces un poco "por la idea feliz" de como esperan que
> se hagan las cosas...
Yo me lo imagino como si el IETF hubiese sido "subcontratado" por los
fabricantes para especificar el protocolo subyacente, pero en plan "vosotros
diseñad el protocolo que nosotros le daremos especificaciones concretas y
estrictas para que sea usable".