Opened 12 years ago

Last modified 11 years ago

#937 closed enhancement

Revamping of presence management to make it more efficient — at Version 4

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
    • subscription is terminated with "deactivated" reason

Change History (4)

comment:1 Changed 12 years ago by bennylp

  • Description modified (diff)

comment:2 Changed 12 years ago by bennylp

  • Description modified (diff)

comment:3 Changed 12 years ago by bennylp

  • Description modified (diff)

comment:4 Changed 12 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

Thanks Saúl Ibarra for the suggestion

Note: See TracTickets for help on using tickets.