Difference between revisions of "DUM Configuration and Profiles"

From reSIProcate
Jump to navigation Jump to search
m (Changed block text to formatted text,. No content changes.)
Line 1: Line 1:
* Profiles
+
= Profiles =
  Profile is a base class for User Profiles from which Master Profile is then derived.
 
  This contains several setXXXX methods which will set this setting internally in this object. 
 
  If you do not call a particular setXXX method on this object then a corresponding getXXXX call will attempt
 
  to retrieve that value from the BaseProfile (provided in the constructor). 
 
  This allows you to setup a hierarchy of profiles and settings.
 
  The unsetXXX methods are used to re-enable fallthrough after calling a setXXXX method. 
 
  If you call an unsetXXXX method on an object with a NULL BaseProfile it will have no effect.
 
  The various XXXX 'settable' pieces available are (all Default) RegistrationTime, MaxRegistrationTime,
 
  RegistrationRetryTime, SubscriptionTime, PublicationTime, StaleCallTime, SessionTime, SessionTimerMode,
 
  1xxRetransmissionTime & overrideHostAndPort, outBoundProxy, advertisedCapabilities, userAgentStatus,
 
  keepAliveTime, fixedTransportPort
 
* User Profiles
 
  User Profile answers the questions: what’s the AOR, what are the credentials, etc.
 
  GRUU stuff is also handled here. 
 
* Master Profile
 
  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
+
Profile is a base class for User Profiles from which Master Profile is then derived. This contains several setXXXX methods that will set this setting internally in this object. If you do not call a particular setXXX method on this object, then a corresponding getXXXX call will attempt to retrieve that value from the BaseProfile (provided in the constructor).  This allows you to set up a hierarchy of profiles and settings.
  The Dialog Usage Manager support two basic models for profile settings.  
 
  
** Single Profile Model
+
The unsetXXX methods are used to re-enable fallthrough after calling a setXXXX method. If you call an unsetXXXX method on an object with a NULL BaseProfile, it will have no effect.
  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
+
The various XXXX 'settable' pieces available are (all Default): RegistrationTime, MaxRegistrationTime, RegistrationRetryTime, SubscriptionTime, PublicationTime, StaleCallTime, SessionTime, SessionTimerMode, 1xxRetransmissionTime & overrideHostAndPort, outBoundProxy, advertisedCapabilities, userAgentStatus, keepAliveTime, fixedTransportPort
  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.  
+
= User Profiles =
  Profiles/UserProfiles can be chained together by passing a fall through profile into the Profile/UserProfile constructor.  
+
 
  A typical application use may be:  
+
User Profile answers the questions: what’s the AOR, what are the credentials, etc.
  1.  Application creates a MasterProfile.
+
 
  2.  Set All UA defaults on this instance.  
+
GRUU stuff is also handled here. 
  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.
+
= Master Profile =
  5.  Application creates a profile for Proxy2 and sets settings appropriately  
+
 
      - the MasterProfile is specified in the consructor for fall through settings.
+
Master Profile answers the questions: What method types, methods, options, mime types, languages, content validation, Accept header field validation & event types do I support?
  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  
+
= Dealing with Multiple User Profiles =
      fall through settings.  Digest credentials and other settings are set.
+
 
  8.  Application creates a UserProfile for User3 and specifies Proxy2 in the constructor for  
+
The Dialog Usage Manager supports two basic models for profile settings: single profile and multi profile.
      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  
+
== Single Profile Model ==
      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  
+
This is typically used by UAs that only need to support one set of settings, such as simple softphones. With 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 do the following:
      DialogSet.
+
 
  10.  Sample UAS operation. DUM calls overloaded selectUASUserProfile method (implemented  
+
<ol>
      by the application) - and application sets User3 so that settings for this DialogSet  
+
<li>Create a MasterProfile.
      are from User3's UserProfile->Proxy2->MasterProfile. Note: If the Application does  
+
<li>Set All UA defaults on this instance.
      not overload the selectUASUserProfile method, then the MasterProfile is assigned as the  
+
<li>Set this MasterProfile on DUM using DialogUsageManager::setMasterProfile.
      UserProfile for this DialogSet by default.
+
</ol>
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.
+
 
 +
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 UAs 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 set up to allow fallthrough settings. Profiles/UserProfiles can be chained together by passing a fallthrough profile into the Profile/UserProfile constructor.  
 +
 
 +
A typical application use may be:  
 +
<ol>
 +
<li>Application creates a MasterProfile.
 +
<li>Set all UA defaults on this instance.  
 +
<li>Set this MasterProfile on DUM using DialogUsageManager::setMasterProfile.
 +
<li>Application creates a profile for Proxy1 and sets settings appropriately. The MasterProfile is specified in the constructor for fallthrough settings.
 +
<li>Application creates a profile for Proxy2 and sets settings appropriately. The MasterProfile is specified in the constructor for fallthrough settings.
 +
<li>Application creates a UserProfile for User1 and specifies Proxy1 in the constructor for fallthrough settings. Digest credentials and other settings are set.
 +
<li>Application creates a UserProfile for User2 and specifies Proxy1 in the constructor for fallthrough settings.  Digest credentials and other settings are set.
 +
<li>Application creates a UserProfile for User3 and specifies Proxy2 in the constructor for fallthrough settings.  Digest credentials and other settings are set.
 +
<li>'''Sample UAC operation:''' Application calls makeInviteSession(target, User1, initialOffer, appDs) to create a call using settings  
 +
from User1's UserProfile->Proxy1->MasterProfile.   
 +
<ul><li>Note:  If 0 is provided as the UserProfile to use, then the MasterProfile is assigned as the UserProfile for this DialogSet.</li></ul>
 +
<li>'''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.
 +
<ul><li>Note: If the Application does not overload the selectUASUserProfile method, then the MasterProfile is assigned as the UserProfile for this DialogSet by default.</li></ul>
 +
</ol>
 +
 
 +
 
 +
'''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. You must ensure that the pointer remains valid for the entire duration of the DialogSet's existence.  
 +
 
 +
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.

Revision as of 15:56, 17 November 2005

Profiles

Profile is a base class for User Profiles from which Master Profile is then derived. This contains several setXXXX methods that will set this setting internally in this object. If you do not call a particular setXXX method on this object, then a corresponding getXXXX call will attempt to retrieve that value from the BaseProfile (provided in the constructor). This allows you to set up a hierarchy of profiles and settings.

The unsetXXX methods are used to re-enable fallthrough after calling a setXXXX method. If you call an unsetXXXX method on an object with a NULL BaseProfile, it will have no effect.

The various XXXX 'settable' pieces available are (all Default): RegistrationTime, MaxRegistrationTime, RegistrationRetryTime, SubscriptionTime, PublicationTime, StaleCallTime, SessionTime, SessionTimerMode, 1xxRetransmissionTime & overrideHostAndPort, outBoundProxy, advertisedCapabilities, userAgentStatus, keepAliveTime, fixedTransportPort


User Profiles

User Profile answers the questions: what’s the AOR, what are the credentials, etc.

GRUU stuff is also handled here.


Master Profile

Master Profile answers the questions: What method types, methods, options, mime types, languages, content validation, Accept header field validation & event types do I support?


Dealing with Multiple User Profiles

The Dialog Usage Manager supports two basic models for profile settings: single profile and multi profile.


Single Profile Model

This is typically used by UAs that only need to support one set of settings, such as simple softphones. With 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 do the following:

  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 UAs 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 set up to allow fallthrough settings. Profiles/UserProfiles can be chained together by passing a fallthrough 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 constructor for fallthrough settings.
  5. Application creates a profile for Proxy2 and sets settings appropriately. The MasterProfile is specified in the constructor for fallthrough settings.
  6. Application creates a UserProfile for User1 and specifies Proxy1 in the constructor for fallthrough settings. Digest credentials and other settings are set.
  7. Application creates a UserProfile for User2 and specifies Proxy1 in the constructor for fallthrough settings. Digest credentials and other settings are set.
  8. Application creates a UserProfile for User3 and specifies Proxy2 in the constructor for fallthrough 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. You must ensure that the pointer remains valid for the entire duration of the DialogSet's existence.

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.