Hello,
several days ago I committed support for accessing components of xml documents using pseudo-variables based on XPath syntax. The new $xml(...) PV is implemented in the presence_xml module as it works with xml docs and links libxml2.
Short description in the cookbook: https://sip-router.org/wiki/cookbooks/pseudo-variables/devel#presence_xml_ps...
As an example: - publish has the body:
<?xml version='1.0' encoding='UTF-8'?> <presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' entity='sip:daniel@asipto.com'> <tuple id='t8b484917'> <status><basic>open</basic></status> </tuple> <dm:person id='p7562ef60'>rpid:activitiesrpid:unknown/</rpid:activities></dm:person> </presence>
Getting the presence status:
# this is needed because libxml2 cannot work with default no-prefix ns, so we alias the "p" prefix. modparam("presence_xml", "xml_ns", "p=urn:ietf:params:xml:ns:pidf")
$xml(a=>doc) = $rb; $xml(a=>xpath:/p:presence/p:tuple/p:status/p:basic)
Next is to update the presence modules to be able to work with the documents that have been updated in the config.
Comments, opinions and improvements are welcome!
Cheers, Daniel
El Jueves, 25 de Junio de 2009, Daniel-Constantin Mierla escribió:
Hello,
several days ago I committed support for accessing components of xml documents using pseudo-variables based on XPath syntax. The new $xml(...) PV is implemented in the presence_xml module as it works with xml docs and links libxml2.
Short description in the cookbook: https://sip-router.org/wiki/cookbooks/pseudo-variables/devel#presence_xml_p seudo-variables
As an example:
- publish has the body:
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' entity='sip:daniel@asipto.com'>
<tuple id='t8b484917'> <status><basic>open</basic></status> </tuple> <dm:person id='p7562ef60'><rpid:activities><rpid:unknown/></rpid:activities></dm:perso n> </presence>
Getting the presence status:
# this is needed because libxml2 cannot work with default no-prefix ns, so we alias the "p" prefix. modparam("presence_xml", "xml_ns", "p=urn:ietf:params:xml:ns:pidf")
$xml(a=>doc) = $rb; $xml(a=>xpath:/p:presence/p:tuple/p:status/p:basic)
Next is to update the presence modules to be able to work with the documents that have been updated in the config.
Comments, opinions and improvements are welcome!
This is more than great!
It would make possible exotic routing decissions based on presence status... or perhaps not yet? I understand that this makes possible to extract XML nodes when processing a request, but would it be possible to extract them from the "presentity" table?
A simpler approach for what I mean would be having a mini API to get presence basic status (some module that connects to DB with "presentity" table):
if ( is_presence_basic_status_open($ru) ) { ...route the MESSAGE... }
XD
On 06/25/2009 11:31 AM, Iñaki Baz Castillo wrote:
El Jueves, 25 de Junio de 2009, Daniel-Constantin Mierla escribió:
Hello,
several days ago I committed support for accessing components of xml documents using pseudo-variables based on XPath syntax. The new $xml(...) PV is implemented in the presence_xml module as it works with xml docs and links libxml2.
Short description in the cookbook: https://sip-router.org/wiki/cookbooks/pseudo-variables/devel#presence_xml_p seudo-variables
As an example:
- publish has the body:
<?xml version='1.0' encoding='UTF-8'?>
<presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' entity='sip:daniel@asipto.com'>
<tuple id='t8b484917'> <status><basic>open</basic></status> </tuple> <dm:person id='p7562ef60'><rpid:activities><rpid:unknown/></rpid:activities></dm:perso n> </presence>
Getting the presence status:
# this is needed because libxml2 cannot work with default no-prefix ns, so we alias the "p" prefix. modparam("presence_xml", "xml_ns", "p=urn:ietf:params:xml:ns:pidf")
$xml(a=>doc) = $rb; $xml(a=>xpath:/p:presence/p:tuple/p:status/p:basic)
Next is to update the presence modules to be able to work with the documents that have been updated in the config.
Comments, opinions and improvements are welcome!
This is more than great!
It would make possible exotic routing decissions based on presence status...
... or based on other content of the xml doc -- you may have there geo positions and send it to the appropriate server.
or perhaps not yet? I understand that this makes possible to extract XML nodes when processing a request, but would it be possible to extract them from the "presentity" table?
Yes, if you load it you can do it. For example, next piece of config is valid as well:
$xml(a=>doc) = '<?xml version="1.0" encoding="UTF-8"?><presence entity="abc"><mynode>abc</mynode></presence>';
xlog("$xml(a=>xpath:/presence/mynode)\n");
Probably not very clear in my first email, but you can change the xml content:
$xml(a=>xpath:/presence/mynode) = "123";
Note that if you assigned the sip message body to $xml(name=>doc), body does not get changed, the operations are done on a replica.
Cheers, Daniel
A simpler approach for what I mean would be having a mini API to get presence basic status (some module that connects to DB with "presentity" table):
if ( is_presence_basic_status_open($ru) ) { ...route the MESSAGE... }
XD
El Jueves, 25 de Junio de 2009, Daniel-Constantin Mierla escribió:
Probably not very clear in my first email, but you can change the xml content:
$xml(a=>xpath:/presence/mynode) = "123";
When reading, which is the result if the node doesn't exist? empty string? If a=>xpath:/presence/mynode gets 123 (an integer) can it be used in math operation as integer? or is it a string?
Note that if you assigned the sip message body to $xml(name=>doc), body does not get changed, the operations are done on a replica.
So modifications in the body must be done in the proxy before forwarding the request to the presence server, or doing a spiral if the presence server is integrated in the proxy, right?
Thanks.
Iñaki Baz Castillo schrieb:
El Jueves, 25 de Junio de 2009, Daniel-Constantin Mierla escribió:
Probably not very clear in my first email, but you can change the xml content:
$xml(a=>xpath:/presence/mynode) = "123";
When reading, which is the result if the node doesn't exist? empty string? If a=>xpath:/presence/mynode gets 123 (an integer) can it be used in math operation as integer? or is it a string?
Note that if you assigned the sip message body to $xml(name=>doc), body does not get changed, the operations are done on a replica.
So modifications in the body must be done in the proxy before forwarding the request to the presence server, or doing a spiral if the presence server is integrated in the proxy, right?
Hi Daniel!
In sip-router there is functionality to apply lumps before sending (it is used for SIP-Identity). Maybe this could be exported to script and can be executed manually to triggering reconstruction of the message, e.g. for processing the modified message in the presence module.
regards klaus
On 06/25/2009 04:13 PM, Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
El Jueves, 25 de Junio de 2009, Daniel-Constantin Mierla escribió:
Probably not very clear in my first email, but you can change the xml content:
$xml(a=>xpath:/presence/mynode) = "123";
When reading, which is the result if the node doesn't exist? empty string? If a=>xpath:/presence/mynode gets 123 (an integer) can it be used in math operation as integer? or is it a string?
Note that if you assigned the sip message body to $xml(name=>doc), body does not get changed, the operations are done on a replica.
So modifications in the body must be done in the proxy before forwarding the request to the presence server, or doing a spiral if the presence server is integrated in the proxy, right?
Hi Daniel!
In sip-router there is functionality to apply lumps before sending (it is used for SIP-Identity). Maybe this could be exported to script and can be executed manually to triggering reconstruction of the message, e.g. for processing the modified message in the presence module.
it does not work now directly on msg body, but your approach can get life using set_body() from textops.
Applying lumps would be good to add as experimental function in config, to see how much it affects the rest.
Cheers, Daniel