DUM Configuration and Profiles

From reSIProcate
Revision as of 16:59, 15 June 2005 by Vinit (talk | contribs)
Jump to navigation Jump to search
  • Profiles
 Profile is a base class for User Profiles from which Master Profile is then derived.
  • User Profiles
 User Profile answers the questions: what’s the AOR, what are the credentials, what is the outbound proxy etc.  
  • Master Profile
 Master Profile hence aggregates all profiles loosely speaking.
 Master Profile answers the questions: What method types, methods, options, mime types, languages, content validation, accept header validation & event types do I support?
  • Dealing with Multiple User Profiles
 The Dialog Usage Manager support two basic models for profile settings. 
    • Single Profile Model
  This is typically used by UA's that only need to support one set of settings, such as simple softphones. Using this model all sessions/dialogs share the same configuration, From user and Digest Authentication settings. The BasicCall sample program uses this model. In this model the application is only required to: 
 1.  Create a MasterProfile.
 2.  Set All UA defaults on this instance. 
 3.  Set this MasterProfile on DUM using DialogUsageManager::setMasterProfile.

When calling the makeXXX methods after this the UserProfile need not be specified, since the MasterProfile will be used.

    • Multi Profile Model
  This is typically used by UA's that need to support many users and settings. For example: an IP PBX with different line groups that can have varying settings for Outbound Proxy, Digest Authentication settings and other profile settings. DUM profiles are setup to allow fallthrough settings. Profiles/UserProfiles can be chained together by passing a fall through profile into the Profile/UserProfile constructor. A typical application use may be: 
 1.  Application creates a MasterProfile.
 2.  Set All UA defaults on this instance. 
 3.  Set this MasterProfile on DUM using DialogUsageManager::setMasterProfile.
 4.  Application creates a profile for Proxy1 and sets settings appropriately 
     - the MasterProfile is specified in the consructor for fall through settings.
 5.  Application creates a profile for Proxy2 and sets settings appropriately 
     - the MasterProfile is specified in the consructor for fall through settings.
 6.  Application creates a UserProfile for User1 and specifies Proxy1 in the 
     constructor for fall through settings.  Digest credentials and other settings are set.
 7.  Application creates a UserProfile for User2 and specifies Proxy1 in the constructor for 
     fall through settings.  Digest credentials and other settings are set.
 8.  Application creates a UserProfile for User3 and specifies Proxy2 in the constructor for 
     fall through settings.  Digest credentials and other settings are set.
 9.  Sample UAC operation.  Application calls 
     makeInviteSession(target, User1, initialOffer, appDs) to create a call using settings 
     from User1's UserProfile->Proxy1->MasterProfile.  Note:  If 0 is provided as the 
     UserProfile to use then the MasterProfile is assigned as the UserProfile for this 
     DialogSet.
 10. Sample UAS operation.  DUM calls overloaded selectUASUserProfile method (implemented 
     by the application) - and application sets User3 so that settings for this DialogSet 
     are from User3's UserProfile->Proxy2->MasterProfile.  Note:  If the Application does 
     not overload the selectUASUserProfile method, then the MasterProfile is assigned as the 
     UserProfile for this DialogSet by default.

WARNING: When pointers to UserProfiles are passed to the makeXXX methods or via the selectUASUserProfile method. They are stored in the DialogSet class and used as required. The application developer must ensure that the pointer remains valid for the entire duration of the DialogSet's existance. Note: The SVN head has been updated to use reference counting smart pointers for Profiles - so this is a non issue for newer releases of resiprocate.