Resources.PuaExtensions HistoryShow minor edits - Show changes to markup April 26, 2013, at 12:41 PM
by
- Changed lines 1-159 from:
Resources -> Documentation -> Presence -> Presence User Agent Extensionswritten by Anca Vamanu OpenSIPS has some presence extensions that offer some very interesting features:
They are implemented as presence user agent in modules named pua_<extension>: pua_usrlocThere are still many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to send basic presence information to the Presence Server about any phone. The modules parameters that can be configured are the following:
recorded aor
'pres'). You can filter for which users or phones to have this feature enabled. In the configuration file you must call the function pua_set_publish exported by the module when a Register for one ot the users is being processed. See here a configuration file example. It is not compulsory for the presence server to run on the same machine as the pua_usrloc extension, as the communication is through PUBLISH SIP messages. You can read the modules readme here. pua_miOpenSIPS offers the possibility to publish any kind of information to the Presence Server or subscribe to the presence state of a resource through the MI interface. This module requires the pua core and an mi module:
The commands and their parameters: 1. pua_publish <presentity_uri> <expires> <event package> <content_type> - body type if body of a type different from default event content-type or . <ETag> - ETag that publish should match or . if no ETag <extra_headers> - extra headers to be added to the request or . <publish_body> - may not be present in case of update for expire Example: :pua_publish:fifo_reply sip:system@192.168.2.132 3600 presence application/pidf+xml . . <?xml version='1.0'?><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='system@domain'><tuple id='0x81475a0'><status><basic>open</basic></status></tuple><dm:person id='pdd748945'><rpid:activities><rpid:away/>away</rpid:activities><dm:note>CPU:16 MEM:476</dm:note></dm:person></presence> This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account. 2. pua_subscribe <presentity_uri> <watcher_uri> <event_package> <expires> You can read the modules readme here. pua_xmppThis module implements a presence gateway between XMPP and SIP. It requires pua and xmpp modules. You have to respect the uri format rules described in [link| xmpp-sip tutorial]. The module has one compulsory module parameter:
Ex: modparam( "pua_xmpp", "server_address", "sip:xmppgw@10.10.10.10") The operations performed by pua_xmpp module consist in translating the presence information format from xmpp to sip and back and also dealing with logic incompatibilities( SIP is time based while XMPP is not). In the SIP part, the module sends Subscribe messages on behalf of the xmpp users and catches Notifies in the script. Also it detects Subscribes to users in XMPP domains and sends Subscribes with event presence.winfo to on behalf of those users to be notified when others Subscribe to its presence. This is achieved by calling the following functions in the script:
See a configuration example here. You can read the module readme here. pua_blaThis module implements BLA( Bridge Line Appearance ) according to draft draft-anil-sipping-bla-03.txt. The implementation is compatible with Polycom phones SoundPoint IP430 SIP. The module requires central pua module and a presence server( either collocated with the BLA server or remote). It also requires to monitor Register messages which means that as pua_usrloc, it has to be collocated with the registrar or Register messages has to be forwarded to the server. The BLA server works as a central entity that gathers bridge line information from the phones and then distributes it to all the phones registered to the line. The gathering part is done by the pua_bla module, with functionalities provided by the pua module. It is achieved by sending Subscribe messages to the phones when registering and then catching the Notifies from the phones. The Notify is then transformed in a Publish message and sent to the presence server. The presence server is the one that will deal with the distributing part. It will receive the subscribe messages from the phones and using the published information sent by the pua_bla module, it will send Notifies with the state of the line. To configure the pua_bla module you can set these parameters:
To achieved the functionalities described above, the following functions exported by the pua_bla module have to be used in the script:
See here a configuration file example. You can read the . pua_dialoginfoThis module enables BLF feature in the server by monitoring and publishing dialog information to the presence server. Basically this module uses the 'dialog' module, which is a tracker for dialogs and registers callback that are called whenever a call dialog SIP message is received. These callbacks code the new state of the dialog into an application/dialog-info+xml data format text and send these to the presence server as a body for a Publish message. Then, the rest of the job is done by the presence server. To enable handling for this event in the presence server you need to load the 'presence_dialoginfo' module that will register the 'dialog-info' event to the presence server. The presence server will receive Subscribe messages from the UA's and generate Notifies with the information received in Publish messages sent by the pua_dialoginfo module. See here a configuration file example. (:commentboxchrono:) to:
(:redirect Documentation/Tutorials-PUAExtensions quiet=1:) October 25, 2012, at 11:05 AM
by
- Deleted lines 157-162:
October 24, 2012, at 01:05 PM
by
- Comment addedAdded lines 158-163:
October 23, 2012, at 04:12 PM
by
- Deleted lines 157-162:
October 22, 2012, at 06:40 PM
by
- Comment addedAdded lines 158-163:
October 22, 2012, at 02:17 PM
by
- Deleted lines 157-162:
October 22, 2012, at 09:11 AM
by
- Comment addedAdded lines 158-163:
May 11, 2011, at 10:19 AM
by
- Comments CleanupDeleted lines 157-169:
May 10, 2011, at 08:09 AM
by
- Comment addedAdded lines 164-169:
May 10, 2011, at 08:09 AM
by
- Comment addedAdded lines 159-164:
February 11, 2011, at 03:48 PM
by
- Added line 2:
written by Anca Vamanu April 27, 2009, at 05:49 PM
by
- Changed line 88 from:
You can read the modules readme here. to:
You can read the modules readme here. April 27, 2009, at 05:48 PM
by
- Changed lines 38-39 from:
You can read the modules readme here. to:
You can read the modules readme here. Changed lines 113-114 from:
You can read the module readme here. to:
You can read the module readme here. Changed line 145 from:
You can read the module readme here. to:
You can read the . March 03, 2009, at 01:18 PM
by
- Added lines 156-159:
(:commentboxchrono:) January 23, 2009, at 09:10 PM
by
- Changed lines 8-9 from:
to:
January 23, 2009, at 09:00 PM
by
- Added lines 149-152:
This module enables BLF feature in the server by monitoring and publishing dialog information to the presence server. Basically this module uses the 'dialog' module, which is a tracker for dialogs and registers callback that are called whenever a call dialog SIP message is received. These callbacks code the new state of the dialog into an application/dialog-info+xml data format text and send these to the presence server as a body for a Publish message. Then, the rest of the job is done by the presence server. To enable handling for this event in the presence server you need to load the 'presence_dialoginfo' module that will register the 'dialog-info' event to the presence server. The presence server will receive Subscribe messages from the UA's and generate Notifies with the information received in Publish messages sent by the pua_dialoginfo module. January 23, 2009, at 08:48 PM
by
- Added lines 146-148:
pua_dialoginfoJanuary 23, 2009, at 08:47 PM
by
- Changed lines 6-8 from:
to:
Changed lines 11-16 from:
to:
January 23, 2009, at 08:43 PM
by
- Changed lines 10-14 from:
to:
August 22, 2008, at 06:05 PM
by
- Added line 69:
. July 31, 2008, at 06:21 PM
by
- Changed line 22 from:
not. This information is used by this module to send basical presence information to the Presence Server about any to:
not. This information is used by this module to send basic presence information to the Presence Server about any Changed line 27 from:
to:
Changed lines 30-31 from:
function pua_set_publish exported by the module when a Register for one ot the users is beeing processed. to:
function pua_set_publish exported by the module when a Register for one ot the users is being processed. Changed line 56 from:
<content_type> - body type if body of a type different from defaultevent content-type or . to:
<content_type> - body type if body of a type different from default event content-type or . Changed line 98 from:
The operations perfromed by pua_xmpp module consist in translating the presence information format from xmpp to:
The operations performed by pua_xmpp module consist in translating the presence information format from xmpp Changed line 104 from:
This is achived by calling th efollowing functions in the script: to:
This is achieved by calling the following functions in the script: Changed line 125 from:
The gathering part is done by the pua_bla module, with functionalities provided by the pua module. It is achived by to:
The gathering part is done by the pua_bla module, with functionalities provided by the pua module. It is achieved by Changed line 137 from:
To achived the functionalities described above, the following functions exported by the pua_bla module have to be used in the script: to:
To achieved the functionalities described above, the following functions exported by the pua_bla module have to be used in the script: July 29, 2008, at 05:29 PM
by
- Changed lines 141-142 from:
You can read the module readme here. to:
You can read the module readme here. July 29, 2008, at 05:29 PM
by
- Changed line 141 from:
You can read the module readme here. to:
You can read the module readme here. July 29, 2008, at 02:40 PM
by
- Changed lines 140-141 from:
You can see here a configuration file example. to:
See here a configuration file example. July 29, 2008, at 02:40 PM
by
- Added line 141:
July 29, 2008, at 02:39 PM
by
- Changed line 26 from:
recorded aor to:
recorded aor July 29, 2008, at 02:39 PM
by
- Changed lines 102-103 from:
those users to be notified when others Subscribe to its presence. to:
those users to be notified when others Subscribe to its presence. July 29, 2008, at 02:38 PM
by
- Changed line 124 from:
to all the phones registered to the line. to:
to all the phones registered to the line. Changed line 127 from:
is then transformed in a Publish message and sent to the presence server. to:
is then transformed in a Publish message and sent to the presence server. Deleted line 141:
]] July 29, 2008, at 02:38 PM
by
- Changed line 2 from:
[[<< to:
Changed lines 18-20 from:
pua_usrlocThere are still many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to send basical presence information to the Presence Server about any phone. to:
pua_usrlocThere are still many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to send basical presence information to the Presence Server about any phone. Changed lines 25-28 from:
You can filter for which users or phones to have this feature enabled. In the configuration file you must call the function pua_set_publish exported by the module when a Register for one ot the users is beeing processed. to:
recorded aor
'pres'). You can filter for which users or phones to have this feature enabled. In the configuration file you must call the function pua_set_publish exported by the module when a Register for one ot the users is beeing processed. Changed lines 34-35 from:
It is not compulsory for the presence server to run on the same machine as the pua_usrloc extension, as the communication is through PUBLISH SIP messages. to:
It is not compulsory for the presence server to run on the same machine as the pua_usrloc extension, as the communication is through PUBLISH SIP messages. Changed lines 43-44 from:
OpenSIPS offers the possibility to publish any kind of information to the Presence Server or subscribe to the presence state of a resource through the MI interface. This module requires the pua core and an mi module: to:
OpenSIPS offers the possibility to publish any kind of information to the Presence Server or subscribe to the presence state of a resource through the MI interface. This module requires the pua core and an mi module: Changed lines 69-73 from:
<?xml version='1.0'?><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='system@domain'><tuple id='0x81475a0'><status><basic>open</basic></status></tuple><dm:person id='pdd748945'><rpid:activities><rpid:away/>away</rpid:activities><dm:note>CPU:16 MEM:476</dm:note></dm:person></presence> to:
<?xml version='1.0'?><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='system@domain'><tuple id='0x81475a0'><status><basic>open</basic></status></tuple><dm:person id='pdd748945'><rpid:activities><rpid:away/>away</rpid:activities><dm:note>CPU:16 MEM:476</dm:note></dm:person></presence> Changed lines 75-76 from:
This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account. to:
This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account. Changed lines 98-99 from:
The operations perfromed by pua_xmpp module consist in translating the presence information format from xmpp to sip and back and also dealing with logic incompatibilities( SIP is time based while XMPP is not). to:
The operations perfromed by pua_xmpp module consist in translating the presence information format from xmpp to sip and back and also dealing with logic incompatibilities( SIP is time based while XMPP is not). Changed lines 101-102 from:
Also it detects Subscribes to users in XMPP domains and sends Subscribes with event presence.winfo to on behalf of those users to be notified when others Subscribe to its presence. to:
Also it detects Subscribes to users in XMPP domains and sends Subscribes with event presence.winfo to on behalf of those users to be notified when others Subscribe to its presence. Changed lines 120-121 from:
The module requires central pua module and a presence server( either collocated with the BLA server or remote). It also requires to monitor Register messages which means that as pua_usrloc, it has to be collocated with the registrar or Register messages has to be forwarded to the server. to:
The module requires central pua module and a presence server( either collocated with the BLA server or remote). It also requires to monitor Register messages which means that as pua_usrloc, it has to be collocated with the registrar or Register messages has to be forwarded to the server. Changed lines 123-125 from:
The BLA server works as a central entity that gathers bridge line information from the phones and then distributes it to all the phones registered to the line. The gathering part is done by the pua_bla module, with functionalities provided by the pua module. It is achived by sending Subscribe messages to the phones when registering and then catching the Notifies from the phones. The Notify is then transformed in a Publish message and sent to the presence server. The presence server is the one that will deal with the distributing part. It will receive the subscribe messages from the phones and using the published information sent by the pua_bla module, it will send Notifies with the state of the line. to:
The BLA server works as a central entity that gathers bridge line information from the phones and then distributes it to all the phones registered to the line. The gathering part is done by the pua_bla module, with functionalities provided by the pua module. It is achived by sending Subscribe messages to the phones when registering and then catching the Notifies from the phones. The Notify is then transformed in a Publish message and sent to the presence server. The presence server is the one that will deal with the distributing part. It will receive the subscribe messages from the phones and using the published information sent by the pua_bla module, it will send Notifies with the state of the line. July 29, 2008, at 02:36 PM
by
- Changed line 2 from:
to:
[[<< Changed lines 121-122 from:
You can read the module readme here. to:
You can read the module readme here. ]] July 29, 2008, at 02:30 PM
by
- Added lines 15-16:
Added lines 31-32:
Changed lines 74-75 from:
to:
Added lines 97-98:
July 29, 2008, at 02:29 PM
by
- Changed lines 16-17 from:
pua_usrlocto:
pua_usrlocChanged lines 30-31 from:
pua_mito:
pua_miChanged lines 72-73 from:
pua_xmppto:
pua_xmppChanged lines 93-94 from:
pua_blato:
pua_blaJuly 29, 2008, at 02:28 PM
by
- Added line 114:
You can read the module readme here. July 29, 2008, at 02:11 PM
by
- Changed line 112 from:
to:
July 29, 2008, at 02:11 PM
by
- Changed line 106 from:
to:
Added lines 109-113:
To achived the functionalities described above, the following functions exported by the pua_bla module have to be used in the script:
You can see here a configuration file example. July 29, 2008, at 02:06 PM
by
- Changed line 77 from:
to:
Changed lines 85-87 from:
to:
Changed lines 103-108 from:
To configure the to:
To configure the pua_bla module you can set these parameters:
July 29, 2008, at 01:54 PM
by
- Changed lines 95-103 from:
This module implements BLA( Bridge Line Appearance ) according to draft draft-anil-sipping-bla-03.txt. to:
This module implements BLA( Bridge Line Appearance ) according to draft draft-anil-sipping-bla-03.txt. The implementation is compatible with Polycom phones SoundPoint IP430 SIP. The module requires central pua module and a presence server( either collocated with the BLA server or remote). It also requires to monitor Register messages which means that as pua_usrloc, it has to be collocated with the registrar or Register messages has to be forwarded to the server. The BLA server works as a central entity that gathers bridge line information from the phones and then distributes it to all the phones registered to the line. The gathering part is done by the pua_bla module, with functionalities provided by the pua module. It is achived by sending Subscribe messages to the phones when registering and then catching the Notifies from the phones. The Notify is then transformed in a Publish message and sent to the presence server. The presence server is the one that will deal with the distributing part. It will receive the subscribe messages from the phones and using the published information sent by the pua_bla module, it will send Notifies with the state of the line. To configure the July 29, 2008, at 01:38 PM
by
- Changed lines 90-95 from:
You can read the module readme here. to:
You can read the module readme here.
pua_blaThis module implements BLA( Bridge Line Appearance ) according to draft draft-anil-sipping-bla-03.txt. July 29, 2008, at 01:27 PM
by
- Changed line 39 from:
to:
1. pua_publish Changed lines 58-60 from:
@]This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account.
to:
@] This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account. 2. pua_subscribe July 29, 2008, at 01:27 PM
by
- Changed lines 40-41 from:
[@ <presentity_uri> to:
[@ <presentity_uri> Changed lines 58-60 from:
@] This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account. to:
@]This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account. July 29, 2008, at 01:26 PM
by
- Changed line 40 from:
<presentity_uri> to:
[@ <presentity_uri> Changed lines 47-48 from:
to:
@] Deleted line 59:
Added line 61:
[@ Changed line 66 from:
to:
@] July 29, 2008, at 01:24 PM
by
- Added line 50:
[@ Changed line 58 from:
to:
@] July 29, 2008, at 12:47 PM
by
- Changed lines 73-74 from:
This module implements a presence gateway between XMPP and SIP. It requires pua and 'xmpp modules. to:
This module implements a presence gateway between XMPP and SIP. It requires pua and xmpp modules. You have to respect the uri format rules described in [link| xmpp-sip tutorial]. The module has one compulsory module parameter:
Ex: modparam( "pua_xmpp", "server_address", "sip:xmppgw@10.10.10.10") The operations perfromed by pua_xmpp module consist in translating the presence information format from xmpp to sip and back and also dealing with logic incompatibilities( SIP is time based while XMPP is not). In the SIP part, the module sends Subscribe messages on behalf of the xmpp users and catches Notifies in the script. Also it detects Subscribes to users in XMPP domains and sends Subscribes with event presence.winfo to on behalf of those users to be notified when others Subscribe to its presence. This is achived by calling th efollowing functions in the script:
See a configuration example here. July 25, 2008, at 04:38 PM
by
- Changed lines 27-28 from:
You can read the modules readme here?. to:
You can read the modules readme here. Changed lines 67-69 from:
You can read the modules readme here?. to:
You can read the modules readme here. Changed line 75 from:
You can read the module readme here. to:
You can read the module readme here. July 25, 2008, at 04:37 PM
by
- Changed lines 66-74 from:
You can read the modules readme here?. to:
You can read the modules readme here?.
pua_xmppThis module implements a presence gateway between XMPP and SIP. It requires pua and 'xmpp modules. You can read the module readme here. July 24, 2008, at 02:07 PM
by
- Changed line 18 from:
There are many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to send basical presence information to the Presence Server about any phone. to:
There are still many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to send basical presence information to the Presence Server about any phone. Changed lines 27-29 from:
to:
You can read the modules readme here?. pua_miOpenSIPS offers the possibility to publish any kind of information to the Presence Server or subscribe to the presence state of a resource through the MI interface. This module requires the pua core and an mi module:
The commands and their parameters:
<presentity_uri> <expires> <event package> <content_type> - body type if body of a type different from defaultevent content-type or . <ETag> - ETag that publish should match or . if no ETag <extra_headers> - extra headers to be added to the request or . <publish_body> - may not be present in case of update for expire Example:
sip:system@192.168.2.132 3600 presence application/pidf+xml . <?xml version='1.0'?><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='system@domain'><tuple id='0x81475a0'><status><basic>open</basic></status></tuple><dm:person id='pdd748945'><rpid:activities><rpid:away/>away</rpid:activities><dm:note>CPU:16 MEM:476</dm:note></dm:person></presence> This example publishes the state of a system( CPU/MEM). This feature can be used in many applications, one example is advertising and publishing news and offers through the presence status of a dummy SIP account.
<presentity_uri> <watcher_uri> <event_package> <expires> You can read the modules readme here?. July 24, 2008, at 01:18 PM
by
- Added line 25:
July 24, 2008, at 01:17 PM
by
- Changed lines 18-28 from:
There are many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to to:
There are many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to send basical presence information to the Presence Server about any phone. The modules parameters that can be configured are the following:
You can filter for which users or phones to have this feature enabled. In the configuration file you must call the function pua_set_publish exported by the module when a Register for one ot the users is beeing processed. See here a configuration file example. It is not compulsory for the presence server to run on the same machine as the pua_usrloc extension, as the communication is through PUBLISH SIP messages. July 24, 2008, at 12:33 PM
by
- Added lines 1-9:
Resources -> Documentation -> Presence -> Presence User Agent ExtensionsOpenSIPS has some presence extensions that offer some very interesting features:
They are implemented as presence user agent in modules named pua_<extension>: Changed lines 13-18 from:
to:
pua_usrlocThere are many SIP phones( especially hard phones) that do not implement presence, or not presence with a central server. Even so, the server is aware if the phone is online or not from whether the phone is registered or not. This information is used by this module to |