Repro Presence Server Announcement page

From reSIProcate
Jump to navigation Jump to search

Hello Fellow reSIPers,

I am happy to announce that repro now supports the ability to be a presence server. This will officially appear in the 1.10 release when it is made available. The code is currently checked into git master for anyone that want's to kick the tires early. The Presence Server capability in repro can be enabled or disabled depending on your needs. When enabled any PUBLISH or SUBSCRIBE requests sent to one of repro's domains will be handled by the new Presence Server handling logic.

Key Features

  • Generic presence document merging - will merge documents using any presence extension (including Rich Presence, Data-model, contact-info, etc.)
  • Presence document replication/synchronization with a redundant repro node (similar to existing registration replication mechanism)
  • Ability to handle presence subscriptions for endpoints that don't publish any presence, using their registration state for simple "open" and "closed" presence.
  • Extensible (via code) for custom merge rules and behaviour

The following RFC's were used for this implementation:

  • RFC3265 - SIP Specific Event Notification (SUBSCRIBE/NOTIFY)
  • RFC3903 - SIP Extension for Event State Publication (PUBLISH)
  • RFC3856 - A Presence Event Package for SIP
  • RFC3859 - Common Profile for Presence
  • RFC3863 - Presence Information Data Format (PIDF)
  • RFC4479 - Data-model PIDF Extension
  • RFC4482 - Contact Info PIDF Extension
  • RFC4480 - Rich Presence PIDF Extension

The typical flow is as follows:

  1. UserA is registering with the repro proxy and also wants to publish it's presence state so it sends a PUBLISH message to repro with an application/pidf+xml body.
  2. repro receives the presence document and stores it in memory.
  3. If publication replication is enabled then the document is also sent over to another repro node for redundancy purposes.
  4. If a second or third document arrives for the same AOR (ie: an AOR that is registered from multiple devices), then all are stored.
  5. Registered UserB is interested in seeing UserA's presence information, so he sends a SUBSCRIBE to repro to receive presence updates.
  6. UserB receives an initial copy of a single presence document consisting of a merge of all published documents for UserA's AOR, via a NOTIFY message.
  7. UserB receives updated merged presence documents whenever one of the published documents is updated by UserA's endpoints.

New repro configuration settings are:

# Enable Presence server
EnablePresenceServer = true

# Will report "open" basic presence for aor's that are registered, but don't publish presence.
# Always report "closed" basic presence for unregistered AORs
PresenceUsesRegistrationState = false

# If enabled presence server will fabricate a simple presence closed state for users
# that haven't published any presence.  If disabled then a 480 response is returned.
# Note:  This setting has no effect when PresenceUsesRegistrationState is set to true.
PresenceNotifyClosedStateForNonPublishedUsers = true

# Enable Publication Syncronization - Currently only applies to Presence Publications
# Requires RegSyncPort to be specified
EnablePublicationRepication = true

Best Regards,
Scott Godin
SIP Spectrum, Inc.