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

Re: [reSIProcate] RE: Profile/Identity Idea


Hi Scott,

I'm sorry to have to do this but I have to revert your change. I'm going to roll the repository back to 3607. We are under a crunch right now and we can't carry on if the stuff doesn't build.

Can I suggest that you get this stuff working in a branch rather than on the head of the repository.

Once again, sorry to have to do this.

Thanks,
Jason


david Butcher wrote:
Hi Scott,

Any chance that you neglected to check in the new files Identity.?xx and
MasterProfile.?xx  ?

david

Quoting Scott Godin <slgodin@xxxxxxxxxxxx>:


I just commited the first pass of this.  A few notes on interface changes:

1.  dum->setProfile is now dum->setMasterProfile

2.  makeXXXX methods now take an identity, instead of a from - or you can
omit the identity and the from will be used from the defaultFrom setting in
the master profile.

3.  AppDialogSet now has a selectUASIdentity callback for the app to set the
Identity for UAS DialogSets.



I fixed BasicCall and BasicRegister test programs to compile and work.



I still need to work on memory management of profiles/identities.



Let me know if there are any issues.



Scott



_____
....



Sample usage:

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 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







_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel