Documentation

Documentation.Tutorials-Presence-PresenceModule History

Show minor edits - Show changes to markup

June 17, 2014, at 08:57 PM by 89.120.101.121 -
Changed lines 66-67 from:

Exported Paramters

to:

Exported Parameters

Added lines 69-70:

June 17, 2014, at 08:57 PM by 89.120.101.121 -
Changed lines 67-87 from:
  • db_url : database url
  • presentity_table: the name of the database table used for storing published info
  • active_watchers_table: the name of the database table used for storing Subscribe dialog info
  • watchers_table: the name of the database table used for storing subscription status for watchers
  • clean_period : time period for cleaning expired PUBLISH or SUBSCRIBE messages from database
  • to_tag_pref : prefix used when generating to_tag when sending replies for SUBSCRIBE requests
  • expires_offset' : the value that should be substracted from the expires value when sending a 200OK for a publish or subscribe to force the client cu send an update before the old request expires
  • max_expires : reduce validity of PUBLISH/SUBSCRIBE to this value if the Expires in request is greater.
  • server_address': presence server address to be included in Contact header field for Subscribe and Publish replies and in Notify messages.
  • fallback2db: parameter which enables a fallback to db mode of operation. In this mode, in case a searched record is not found in cache, the search is continued in database. Useful for an architecture in which processing and memory load might be divided on more machines using the same database.
  • subs_htable_size: the size of the hash table storing subscription dialogs(used as the power of 2 when computing table size)
  • pres_htable_size: the size of the hash table storing published info (used as the power of 2 when computing table size)
  • enable_sphere_check: a flag that should be set if privacy rules include sphere checking. The sphere information is expected to be present in the RPID body published by the presentity. The flag is introduced as this check requires extra processing that should be avoided if this feature is not supported by the clients.

Developer's Guide

Module Readme

Please refer to the module's documentation.

to:

Please refer to the module's documentation for the full list of parameters and a comprehensive description.

June 17, 2014, at 08:54 PM by 89.120.101.121 -
Changed line 87 from:

You can read the module's documentation here .

to:

Please refer to the module's documentation.

May 07, 2014, at 12:29 PM by 89.120.101.121 -
Changed lines 1-8 from:
to:
Documentation -> Tutorials -> Presence -> Presence Server -> Presence Module - Parameters and Functions

(:toc-float Table of Content:)

Changed lines 11-12 from:

handle_publish()

to:

handle_publish()

Changed lines 37-38 from:

handle_subscribe()

to:

handle_subscribe()

Changed lines 63-64 from:

to:

Changed lines 80-81 from:

to:

Changed lines 85-86 from:

Module Readme

to:

Module Readme

May 09, 2013, at 12:37 PM by 109.99.235.212 -
Changed line 1 from:

Resources -> Documentation -> Presence -> Presence Server -> Presence Module - Parameters and Functions

to:

Documentation? -> Presence Tutorial -> Presence Server -> Presence Module - Parameters and Functions

April 24, 2013, at 08:12 PM by 109.99.235.212 -
Added lines 1-88:

Resources -> Documentation -> Presence -> Presence Server -> Presence Module - Parameters and Functions

  1. Exported Functions
  2. Exported Parameters
  3. Developer's Guide
  4. Module Readme

Exported Functions

  • handle_publish()
  • handle_subscribe()

handle_publish()

  • function which handles PUBLISH requests. It stores and updates presence information in database and calls functions to send NOTIFY messages when changes in presence information occur;
  • it takes one optional parameter - the URI of the sender, used by the BLA feature( event dialog;sla ).

Actions:

  • verifies if the PUBLISH message is correct:
    • check its structure - calls an event specific function defined in a presence_ev module (presence_xml or presence_mwi);
    • if it has a SIP-if-Match header, checks is there is a previous record for the same presentity;
    • if not present checks if a body is present
  • if the conditions are not complied with it sends an adequate error message
  • if a correct message:
    • sends a 200Ok message with 2 extra header fields : Expires and SIP-if-Match
  • if a new PUBLISH without a Sip-if-Match header field
    • it generates one
    • inserts a new row in database
    • calls a function which sends Notify with presence to all the watchers which have subscribed to the presentity
  • if the PUBLISH message is a sequential one
    • updates the expires value
    • generates a new E-Tag and sends it in the Sip-Etag header of the 200OK reply
  • if body present
    • updates body (replace with the new one)
    • calls a function which sends Notify with presence to all watchers

handle_subscribe()

  • function which handles SUBSCRIBE requests. It stores or updates dialog information in and calls functions to send Notify messages to teh watcher and to the presentity (if a subscription for event presence.winfo exists for the presentity and the event)
  • it does not take any parameter.

Actions

  • checks if the SUBSCRIBE message is correct:
    • check its structure;
    • if inside a dialog tries to match the dialogs with the records stored
  • if the conditions are not complied with it sends an adequate error message
  • if a correct message sends 2XX reply
    • the reply contains an Expires header
    • for SUBSCRIBE messages for event "presence.winfo" the status of the reply is 202OK and for all the other 200OK
  • if a new SUBSCRIBE, saves the dialog information in cache
  • if a Subscribe inside a dialog
    • if the Expires header field value is 0
      • deletes the registration from cache and database
      • if event is a PUBLISH event - sends a Notify for winfo to the presentity with full state
    • if update
      • updates the expires value
      • sends Notifies
  • if a SUBSCRIBE for a PUBLISH event( 'presence', 'dialog.sla', 'message-summary'):
    • sends Notify with presence.winfo to the presentity(if a winfo subscription from the presentity exists) with a partial state informing only about the subscription status of the new watcher
    • sends Notify with the presence information
  • if a SUBSCRIBE for a winfo(watcher info) event
    • sends Notify with presence.winfo to the subscriber with full state informing about all the watchers

Exported Paramters

  • db_url : database url
  • presentity_table: the name of the database table used for storing published info
  • active_watchers_table: the name of the database table used for storing Subscribe dialog info
  • watchers_table: the name of the database table used for storing subscription status for watchers
  • clean_period : time period for cleaning expired PUBLISH or SUBSCRIBE messages from database
  • to_tag_pref : prefix used when generating to_tag when sending replies for SUBSCRIBE requests
  • expires_offset' : the value that should be substracted from the expires value when sending a 200OK for a publish or subscribe to force the client cu send an update before the old request expires
  • max_expires : reduce validity of PUBLISH/SUBSCRIBE to this value if the Expires in request is greater.
  • server_address': presence server address to be included in Contact header field for Subscribe and Publish replies and in Notify messages.
  • fallback2db: parameter which enables a fallback to db mode of operation. In this mode, in case a searched record is not found in cache, the search is continued in database. Useful for an architecture in which processing and memory load might be divided on more machines using the same database.
  • subs_htable_size: the size of the hash table storing subscription dialogs(used as the power of 2 when computing table size)
  • pres_htable_size: the size of the hash table storing published info (used as the power of 2 when computing table size)
  • enable_sphere_check: a flag that should be set if privacy rules include sphere checking. The sphere information is expected to be present in the RPID body published by the presentity. The flag is introduced as this check requires extra processing that should be avoided if this feature is not supported by the clients.

Developer's Guide

Module Readme

You can read the module's documentation here .


Page last modified on June 17, 2014, at 08:57 PM