[reSIProcate] Multi-Profile/Identities Design Discussion

[Scott Godin <slgodin@xxxxxxxxxxxx>]

Hi Team,

 

I've been talking quickly to Derek about some idea's that I would like to implement support for.  The main idea is to support multiple set's of Auth Credentials/OutboundProxy/Profile settings and give the application the ability to determine which set of options get used on a per dialogset basis.  These settings could be called an Indentity.  An example of existing Profile settings that would belong to an identity are:

1. Digest Credentials
2. Default From
3. Override Host and Port - or ability to specify preferred transport (needs work in stack)
4. GRUU
5. rport enabled

 

Most other profile settings probably make sense to remain system wide settings (ie. Non-Identity). Ie. Validate, supported and loose to tag matching settings are all used before a Dialogset is determined.

 

The way I see it - the Profile object would manage a list of identities:

Profile->addIdentity() - returns an Identity Handle

Profile->removeIdentity() - must be careful if in use in existing dialogsets

Profile->getIdentity() - used to modify settings

Each Identity would manage the settings mentioned above.

 

Each makeXXXXX method on the DialogUsageManager would be modified to allow specification of the Identity Handle for the resulting DialogSet.

 

Inbound requests creating DialogSets will require setting of the Identity - likely via a new AppDialogSet method:  setIdentity() that could be called sometime after createAppDialogSet is called.

 

We can make the above two settings of the Identity optional - ie. If not specified then settings from the first identity are used.  Or we can have an explicit default Identity specified.

 

All applicable current profile setting lookups will be changed to lookup settings via the Identity Handle stored in the DialogSet.

 

Let me know if you have any comments/suggestions/improvements.

 

Thanks,

 

Scott