Resources.PuaExtensions History

Hide minor edits - Show changes to markup

April 26, 2013, at 11:41 AM by 109.99.235.212 -
Changed lines 1-159 from:

Resources -> Documentation -> Presence -> Presence User Agent Extensions

written by Anca Vamanu

OpenSIPS has some presence extensions that offer some very interesting features:

  • Get presence status from Register
  • Gateway to xmpp presence
  • Sending Publish and Subscribe messages using the MI interface
  • Bridge Line Appearance (BLA, event: dialog;sla)
  • Busy Lamp Field (BLF, event:dialog)

They are implemented as presence user agent in modules named pua_<extension>:

  1. pua_usrloc
  2. pua_mi
  3. pua_xmpp
  4. pua_bla
  5. pua_dialoginfo

pua_usrloc

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 basic presence information to the Presence Server about any phone. The modules parameters that can be configured are the following:

  • default_domain : (compulsory) the default domain to use when constructing the presentity uri if it is missing from

recorded aor

  • entity_prefix : the prefix when constructing entity attribute to be added to presence node in xml pidf. (ex:

'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_mi

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:

  • mi_fifo: local commands through fifo
  • mi_xmlrpc: local and remote commands
  • mi_datagram: UNIX/UDP SOCKET transport

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_xmpp

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:

  • server_address - the IP address of the machine where the OpenSIPS XMPP gateway is running

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:

  • pua_xmpp_notify()
  • pua_xmpp_req_winfo(char* request_uri, char* expires)

See a configuration example here.

You can read the module readme here.


pua_bla

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 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:

  • default_domain(str) - (compulsory) the default domain
  • header_name(str) - (compulsory) the header name to be used for comprising information about the sender of the Notify in the generated Publish message; in the configuration file of the presence server the content of this header has to be given as a parameter for the handle_publish function
  • outbound_proxy(str) - the address of the outbound proxy if one is used
  • server_address(str) - (compulsory) the IP address of the bla server

To achieved the functionalities described above, the following functions exported by the pua_bla module have to be used in the script:

  • bla_set_flag: should be called upon receiving a Register message for those registrations that are addressed to a BLA
  • bla_handle_notify: Should be called when receiving a Notify with a BLA information ( event: dialog;sla).

See here a configuration file example.

You can read the .

pua_dialoginfo

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.

See here a configuration file example.

(:commentboxchrono:)

to:

(:redirect Documentation/Tutorials-PUAExtensions quiet=1:)

October 25, 2012, at 10:05 AM by bogdan -
Deleted lines 157-162:

(:nl:)>>messagehead<<

Foge?24 October 2012, 12:05

It's great to read something that's both enjyoalbe and provides pragmatisdc solutions.

October 24, 2012, at 12:05 PM by Foge - Comment added
Added lines 158-163:

(:nl:)>>messagehead<<

Foge?24 October 2012, 12:05

It's great to read something that's both enjyoalbe and provides pragmatisdc solutions.

October 23, 2012, at 03:12 PM by bogdan -
Deleted lines 157-162:

(:nl:)>>messagehead<<

Julie?22 October 2012, 17:40

آقا ببخشید اگه اعصابتونو خورد میکنم، ولی من از روش آلتر استفاده می کنم وقتی روی aIW2 می زنم ارور می ده. شاید مشکل از همین جاست؟؟ آخه من هم با آلتر و هم با آلتر رولوشن انجام دادم، توی هر دو تا روی connecting to IWNet sveerr گیر می کنه.لطفا کمک!

October 22, 2012, at 05:40 PM by Julie - Comment added
Added lines 158-163:

(:nl:)>>messagehead<<

Julie?22 October 2012, 17:40

آقا ببخشید اگه اعصابتونو خورد میکنم، ولی من از روش آلتر استفاده می کنم وقتی روی aIW2 می زنم ارور می ده. شاید مشکل از همین جاست؟؟ آخه من هم با آلتر و هم با آلتر رولوشن انجام دادم، توی هر دو تا روی connecting to IWNet sveerr گیر می کنه.لطفا کمک!

October 22, 2012, at 01:17 PM by bogdan -
Deleted lines 157-162:

(:nl:)>>messagehead<<

Marcelo?22 October 2012, 08:11

Warning: fopen(wp-config.php) [function.fopen]: failed to open staerm: Permission denied in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 462Warning: fwrite(): supplied argument is not a valid staerm resource in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 502Warning: fwrite(): supplied argument is not a valid staerm resource in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 502Warning: fclose(): supplied argument is not a valid staerm resource in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 506Warning: chmod() [function.chmod]: No such file or directory in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 507Warning: include_once(./wp-config.php) [function.include-once]: failed to open staerm: No such file or directory in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 663Warning: include_once() [function.include]: Failed opening ./wp-config.php' for inclusion (include_path='.;./includes;./pear') in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 663Warning: require_once(ABSPATHwp-admin/includes/admin.php) [function.require-once]: failed to open staerm: No such file or directory in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocswp-adminincludesupgrade.php on line 16Fatal error: require_once() [function.require]: Failed opening required ABSPATHwp-admin/includes/admin.php' (include_path='.;./includes;./pear') in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocswp-adminincludesupgrade.php on line 16

October 22, 2012, at 08:11 AM by Marcelo - Comment added
Added lines 158-163:

(:nl:)>>messagehead<<

Marcelo?22 October 2012, 08:11

Warning: fopen(wp-config.php) [function.fopen]: failed to open staerm: Permission denied in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 462Warning: fwrite(): supplied argument is not a valid staerm resource in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 502Warning: fwrite(): supplied argument is not a valid staerm resource in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 502Warning: fclose(): supplied argument is not a valid staerm resource in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 506Warning: chmod() [function.chmod]: No such file or directory in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 507Warning: include_once(./wp-config.php) [function.include-once]: failed to open staerm: No such file or directory in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 663Warning: include_once() [function.include]: Failed opening ./wp-config.php' for inclusion (include_path='.;./includes;./pear') in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocsindex-install.php on line 663Warning: require_once(ABSPATHwp-admin/includes/admin.php) [function.require-once]: failed to open staerm: No such file or directory in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocswp-adminincludesupgrade.php on line 16Fatal error: require_once() [function.require]: Failed opening required ABSPATHwp-admin/includes/admin.php' (include_path='.;./includes;./pear') in D:inetpubvhostskhondoi.comsubdomainspa-ohhttpdocswp-adminincludesupgrade.php on line 16

May 11, 2011, at 09:19 AM by bogdan - Comments Cleanup
Deleted lines 157-169:

(:nl:)>>messagehead<<

Kiana?10 May 2011, 07:09

AFAICT you've coveerd all the bases with this answer!

(:nl:)>>messagehead<<

Louisa?10 May 2011, 07:09

THX that's a great anwser!

May 10, 2011, at 07:09 AM by Louisa - Comment added
Added lines 164-169:

(:nl:)>>messagehead<<

Louisa?10 May 2011, 07:09

THX that's a great anwser!

May 10, 2011, at 07:09 AM by Kiana - Comment added
Added lines 159-164:

(:nl:)>>messagehead<<

Kiana?10 May 2011, 07:09

AFAICT you've coveerd all the bases with this answer!

February 11, 2011, at 02:48 PM by anca_vamanu -
Added line 2:

written by Anca Vamanu

April 27, 2009, at 04:49 PM by anca_vamanu -
Changed line 88 from:

You can read the modules readme here.

to:

You can read the modules readme here.

April 27, 2009, at 04:48 PM by anca_vamanu -
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 12:18 PM by anca_vamanu -
Added lines 156-159:

(:commentboxchrono:)

January 23, 2009, at 08:10 PM by 81.180.102.217 -
Changed lines 8-9 from:
  • Busy Lamp Field (BLF, event:dialoginfo)
to:
  • Busy Lamp Field (BLF, event:dialog)
January 23, 2009, at 08:06 PM by 81.180.102.217 -
Added lines 153-155:
January 23, 2009, at 08:00 PM by 81.180.102.217 -
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 07:48 PM by 81.180.102.217 -
Changed lines 15-16 from:
to:
January 23, 2009, at 07:48 PM by 81.180.102.217 -
Added lines 146-148:

pua_dialoginfo

January 23, 2009, at 07:47 PM by 81.180.102.217 -
Changed lines 6-8 from:
  • Publish info from non SIP devices
  • Bridge Line Appearance (BLA)
to:
  • Sending Publish and Subscribe messages using the MI interface
  • Bridge Line Appearance (BLA, event: dialog;sla)
  • Busy Lamp Field (BLF, event:dialoginfo)
Changed lines 11-16 from:
to:
August 22, 2008, at 05:05 PM by 81.180.102.217 -
Added line 69:

.

July 31, 2008, at 05:21 PM by 81.180.102.217 -
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:
  • entity_prefix : the prefix when construstructing entity attribute to be added to presence node in xml pidf. (ex:
to:
  • entity_prefix : the prefix when constructing entity attribute to be added to presence node in xml pidf. (ex:
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 04:29 PM by 81.180.102.217 -
Changed lines 141-142 from:
 You can read the module readme here.
to:

You can read the module readme here.

July 29, 2008, at 04:29 PM by 81.180.102.217 -
Changed line 141 from:

You can read the module readme here.

to:
 You can read the module readme here.
July 29, 2008, at 01:40 PM by 81.180.102.217 -
Changed lines 140-141 from:

You can see here a configuration file example.

to:
July 29, 2008, at 01:40 PM by 81.180.102.217 -
Added line 141:
July 29, 2008, at 01:39 PM by 81.180.102.217 -
Changed line 26 from:
 recorded aor
to:

recorded aor

July 29, 2008, at 01:39 PM by 81.180.102.217 -
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 01:38 PM by 81.180.102.217 -
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 01:38 PM by 81.180.102.217 -
Changed line 2 from:

[[<<

to:
Changed lines 18-20 from:

pua_usrloc

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.

to:

pua_usrloc

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 25-28 from:
  • default_domain : (compulsory) the default domain to use when constructing the presentity uri if it is missing from recorded aor
  • entity_prefix : the prefix when construstructing entity attribute to be added to presence node in xml pidf. (ex: '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.

to:
  • default_domain : (compulsory) the default domain to use when constructing the presentity uri if it is missing from
 recorded aor
  • entity_prefix : the prefix when construstructing entity attribute to be added to presence node in xml pidf. (ex:

'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 01:36 PM by 81.180.102.217 -
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 01:30 PM by 81.180.102.217 -
Added lines 15-16:

Added lines 31-32:

Changed lines 74-75 from:
to:

Added lines 97-98:

July 29, 2008, at 01:29 PM by 81.180.102.217 -
Changed lines 16-17 from:

pua_usrloc

to:

pua_usrloc

Changed lines 30-31 from:

pua_mi

to:

pua_mi

Changed lines 72-73 from:

pua_xmpp

to:

pua_xmpp

Changed lines 93-94 from:

pua_bla

to:

pua_bla

July 29, 2008, at 01:28 PM by 81.180.102.217 -
Added line 114:

You can read the module readme here.

July 29, 2008, at 01:11 PM by 81.180.102.217 -
Changed line 112 from:
  • 'bla_handle_notify: Should be called when receiving a Notify with a BLA information ( event: dialog;sla).
to:
  • bla_handle_notify: Should be called when receiving a Notify with a BLA information ( event: dialog;sla).
July 29, 2008, at 01:11 PM by 81.180.102.217 -
Changed line 106 from:
  • header_name(str) - the header name to be used for comprising information about the sender of the Notify in the generated Publish message (default value:'Sender'); in the configuration file of the presence server the content of this header has to be given as a parameter for the handle_publish function
to:
  • header_name(str) - (compulsory) the header name to be used for comprising information about the sender of the Notify in the generated Publish message; in the configuration file of the presence server the content of this header has to be given as a parameter for the handle_publish function
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:

  • bla_set_flag: should be called upon receiving a Register message for those registrations that are addressed to a BLA
  • 'bla_handle_notify: Should be called when receiving a Notify with a BLA information ( event: dialog;sla).

You can see here a configuration file example.

July 29, 2008, at 01:06 PM by 81.180.102.217 -
Changed line 77 from:
  • server_address - the IP address of the machine where the OpenSIPS XMPP gateway is running
to:
  • server_address - the IP address of the machine where the OpenSIPS XMPP gateway is running
Changed lines 85-87 from:
  • pua_xmpp_notify()
  • pua_xmpp_req_winfo(char* request_uri, char* expires)
to:
  • pua_xmpp_notify()
  • pua_xmpp_req_winfo(char* request_uri, char* expires)
Changed lines 103-108 from:

To configure the

to:

To configure the pua_bla module you can set these parameters:

  • default_domain(str) - (compulsory) the default domain
  • header_name(str) - the header name to be used for comprising information about the sender of the Notify in the generated Publish message (default value:'Sender'); in the configuration file of the presence server the content of this header has to be given as a parameter for the handle_publish function
  • outbound_proxy(str) - the address of the outbound proxy if one is used
  • server_address(str) - (compulsory) the IP address of the bla server
July 29, 2008, at 12:54 PM by 81.180.102.217 -
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 12:38 PM by 81.180.102.217 -
Changed lines 90-95 from:

You can read the module readme here.

to:

You can read the module readme here.

pua_bla

This module implements BLA( Bridge Line Appearance ) according to draft draft-anil-sipping-bla-03.txt.

July 29, 2008, at 12:27 PM by 81.180.102.217 -
Changed line 39 from:
  1. pua_publish
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.

  1. pua_subscribe
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 12:27 PM by 81.180.102.217 -
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 12:26 PM by 81.180.102.217 -
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 12:24 PM by 81.180.102.217 -
Added line 50:

[@

Changed line 58 from:
to:

@]

July 29, 2008, at 11:47 AM by 81.180.102.217 -
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:

  • server_address - the IP address of the machine where the OpenSIPS XMPP gateway is running

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:

  • pua_xmpp_notify()
  • pua_xmpp_req_winfo(char* request_uri, char* expires)

See a configuration example here.

July 25, 2008, at 03:38 PM by 81.180.102.217 -
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 03:37 PM by 81.180.102.217 -
Changed lines 66-74 from:

You can read the modules readme here?.

to:

You can read the modules readme here?.

pua_xmpp

This 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 01:07 PM by 81.180.102.217 -
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_mi

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:

  • mi_fifo: local commands through fifo
  • mi_xmlrpc: local and remote commands
  • mi_datagram: UNIX/UDP SOCKET transport

The commands and their parameters:

  1. pua_publish
 <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:

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.

  1. pua_subscribe

<presentity_uri> <watcher_uri> <event_package> <expires>

You can read the modules readme here?.

July 24, 2008, at 12:18 PM by 81.180.102.217 -
Added line 25:
July 24, 2008, at 12:17 PM by 81.180.102.217 -
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:

  • default_domain : (compulsory) the default domain to use when constructing the presentity uri if it is missing from recorded aor
  • entity_prefix : the prefix when construstructing entity attribute to be added to presence node in xml pidf. (ex: '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.

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 11:33 AM by 81.180.102.217 -
Added lines 1-9:

Resources -> Documentation -> Presence -> Presence User Agent Extensions

OpenSIPS has some presence extensions that offer some very interesting features:

  • Get presence status from Register
  • Gateway to xmpp presence
  • Publish info from non SIP devices
  • Bridge Line Appearance (BLA)

They are implemented as presence user agent in modules named pua_<extension>:

Changed lines 13-18 from:
to:
  1. pua_bla

pua_usrloc

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

July 24, 2008, at 11:07 AM by 81.180.102.217 -
Added lines 1-4:

Page last modified on April 26, 2013, at 11:41 AM