< Previous by Date Date Index Next by Date >
  Thread Index  

[reSIProcate] Profile/Identity Work


There doesn't really seem to be any opposition on this concept from previous postings - but I just wanted to repost some of these ideas in greater detail.  I'll be starting work on this shortly.

 

Header files outlining the reorganization of the current Profile.hxx are attached.  Check them out first.

 

Sample usage of Profiles/Identities:

1.  MasterProfile is created

2.  All UA defaults are set on this class.

3.  MasterProfile is set on the DialogUsageManager::setMasterProfile - (note:  old setProfile method is depricated).

4.  Some applications will stop here and all settings will just be used from the MasterProfile.

5.  Application creates a profile for Proxy1 and sets settings appropriately - the MasterProfile is specified in the consructor for fall through settings.

6.  Application creates a profile for Proxy2 and sets settings appropriately - the MasterProfile is specified in the consructor for fall through settings.

7.  Application creates an Identity for User1 and specifies Proxy1 in the constructor for fall through settings.  Digest credentials and other settings are set.

8.  Application creates an Identity for User2 and specifies Proxy1 in the constructor for fall through settings.  Digest credentials and other settings are set.

9.  Application creates an Identity for User3 and specifies Proxy2 in the constructor for fall through settings.  Digest credentials and other settings are set.

 

UAC

Application calls makeInviteSession(target, User1, initialOffer, appDs) to create a call using settings from User1's Indentity->Proxy1->MasterProfile.

If 0 is provided as the Identity to use then the MasterProfile is assigned as the Identity for this DialogSet.

 

UAS

DUM calls overloaded AppDialogSet constructor - and application sets User3 so that settings for this DialogSet are from User3's Indentity->Proxy2->MasterProfile.

If Application does not overload constructor or does not set Identity, then the MasterProfile is assigned as the Identity for this DialogSet by default.

 

For thought Reference:  Currently the profile is used in the following classes - they will need to be modifed to fetch the set Identity from the DialogSet:

1.  BaseCreator::makeInitialRequest - this one will actually be changed to have the Identity passed in

2.  ClientInviteSession::dispatch

3.  ClientRegistration::addBinding

4.  Dialog::makeRequest

5.  DialogSet::findDialog - looseToTagMatching is used here

6.  DialogUsageManager::makeXXXX - Identity to be passed in here

7.  InviteSession::makeFinalResponse

8.  InviteSession::handleSessionTimerxxx

9.  InviteSession::dispatch

10.  InviteSessionCreator

11.  ServerOutOfDialogReq - this actually only needs the MasterProfile

12.  DialogUsageManager::send, ::process, ::validatexxx, ::mergeRequest, ...

13.  ClientAuthManager::handleAuthHeader - called from Dialog::dispatch and DialogSet::dispatch

 

Let me know if you have any concerns.

 

Thanks,

 

 

 

Scott Godin

Research and Development

Computer Talk Technology

slgodin@xxxxxxxxxxxx

905-882-5000 and 'Say my name' or x127

 

Attachment: MasterProfile.hxx
Description: Binary data

Attachment: Identity.hxx
Description: Binary data

Attachment: Profile.hxx
Description: Binary data