Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#937 closed enhancement (fixed)

Revamping of presence management to make it more efficient

Reported by: bennylp Owned by: bennylp
Priority: normal Milestone: release-1.5
Component: pjsua-lib Version: trunk
Keywords: Cc: johan, emil
Backport to 1.x milestone: Backported:

Description (last modified by bennylp)

Some issues to be fixed in the presence management in PJSUA-LIB:

  • pjsua_pres_refresh() will be called every time there is an operation to a buddy, which is not very efficient since this function scans the buddy list for modifications.
  • the use of LOCK_BUDDIES/LOCK_BUDDIES (introduced by #351) has been identified to have caused slow performance, especially on mobile devices, since it prevents other thread from working with different buddy object every time the main thread does something with a buddy.
  • buddy may need individual timer, so that refreshes do not happen all at once.
  • add the last subscription status code (not just reason string) in the buddy info, so that application may handle some other failures with the buddy subscription
  • sending of PUBLISH in relation to REGISTER
  • handle several cases where PJSUA-LIB should re-subscribe to buddy's presence immediately, rather than relying on the timer:
    • 481 response to SUBSCRIBE
    • subscription is terminated with "deactivated", "timeout", "probation", and "giveup" reason
    • note that for other cases, there is already PJSUA_PRES_TIMER timer to refresh subscriptions periodically

Change History (11)

comment:1 Changed 15 years ago by bennylp

  • Description modified (diff)

comment:2 Changed 15 years ago by bennylp

  • Description modified (diff)

comment:3 Changed 15 years ago by bennylp

  • Description modified (diff)

comment:4 Changed 15 years ago by bennylp

  • Description modified (diff)

Added to resubscribe immediately if subscription is terminated with "deactivated" reason. From the RFC:

   deactivated: The subscription has been terminated, but the subscriber
      SHOULD retry immediately with a new subscription.  One primary use
      of such a status code is to allow migration of subscriptions
      between nodes.  The "retry-after" parameter has no semantics for
      "deactivated".

Thanks Saúl Ibarra for the suggestion

comment:5 Changed 15 years ago by bennylp

  • Description modified (diff)

Also resubscribe immediately or after retry-after parameter for "timeout", "probation", and "giveup" reasons. Thanks Iñaki Baz Castillo for the suggestion.

comment:6 Changed 15 years ago by bennylp

  • Description modified (diff)

Added note about PJSUA_PRES_TIMER

comment:7 Changed 15 years ago by bennylp

Initial commit in r2956:

Presence enhancements:

  • finer grained buddy lock object, instead of using global PJSUA-LIB's mutex
  • individual resubscription timer for buddies and also add random delay interval so that resubscriptions don't happen simultaneously (may hog processing and bandwidth).
  • in general reduced the use of global PJSUA-LIB's mutex for more efficiency
  • added last termination code in buddy info
  • use the RPID note's text for buddy's offline status rather than the default "offline" status, if available
  • resubscribe automatically on several termination causes as explained in the ticket (still untested)

General enhancements:

  • added pjsua_schedule_timer() and pjsua_cancel_timer() APIs

comment:8 Changed 15 years ago by bennylp

Note that PUBLISH issues were fixed in #411 and #364

comment:9 Changed 15 years ago by bennylp

  • Resolution set to fixed
  • Status changed from new to closed

In r2959:

  • Added couple of SIPp scenario files to test various retry scenarios:
    • uas-subscribe-refresh-481.xml: client should resubscribe immediately on receiving 481 on resubscription
    • uas-subscribe-terminated-retry.xml: client should resubscribe upon receiving NOTIFY with some specific termination reasons
  • Added log message when PJSUA-LIB is resubscribing automatically due to above

comment:10 Changed 15 years ago by bennylp

In r2960:

  • added protection to not resubscribe immediately if initial SUBSCRIBE is responded with 481 for some reason

comment:11 Changed 14 years ago by bennylp

In r3009:

  • handle case where event argument is NULL. Could happen with various timeout events
Note: See TracTickets for help on using tickets.