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

Re: [reSIProcate] merging teltel-branch to main (IMPORTANT)


The merge occurred today. I am deleting the branch. You MUST change
your views to begin using the main trunk now or it will not work.

I used this command to do the merge: 
svn merge -r 3484:HEAD
https://scm.sipfoundry.org/rep/resiprocate/branches/b-teltel-20041118-invitesession


These files were changed significantly from the main trunk:
BaseSubscription.cxx
ClientAuthManager.cxx
ClientInviteSession.cxx, ClientInviteSession.hxx
ClientSubscription.cxx
Dialog.cxx, Dialog.hxx
DialogSet.cxx, DialogSet.hxx
DialogUsageManager.cxx, DialogUsageManager.hxx
DumTimeout.hxx
InviteSession.cxx, InviteSession.hxx
InviteSessionCreator.cxx
Profile.cxx
ServerSubscription.cxx
SubscriptionHandler.cxx
test/certServer.cxx

Not in branch (new in trunk):
InMemoryRegistrationDatabase.cxx, InMemoryRegistrationDatabase.hxx

Summary of mods during merge:
------------------------------------------------

- Many files had license added 

AppDialog.cxx, AppDialog.hxx
- added getContact() and dump method

AppDialogSet.cxx, AppDialogSet.hxx
- added getDialogSetId(), dump() method
- Profile related changes
- store DialogSet* instead of DialogSetId in mDialogSet

BaseCreator.cxx, BaseCreator.hxx
- Profile related changes
- add an instanceId to contact
- mod to how embedded params are merged

BaseSubscription.cxx
- various changes (see diffs)

BaseUsage.cxx, BaseUsage.hxx
- added dump

ClientAuthManager.cxx, ClientAuthManager.hxx
- Profile related changes

ClientInviteSession.cxx, ClientInviteSession.hxx
- removed forked(), cancel() replaced with onForkAccepted()
- massive changes to impl (see other notes)

ClientPagerMessage.cxx, ClientPagerMessage.hxx
- changed behavior when a client tries to send a MESSAGE before
response is received from previous message
- added msgQueued() method

ClientPublication.cxx, ClientPublication.hxx
- added dump
- added state to take care of case where publish occurs while another
pending publish is outstanding

ClientRegistration.cxx, ClientRegistration.hxx
- added dump
- added state to deal with case where update occurs while pending
register request

ClientSubscription.cxx, ClientSubscription.hxx
- added dump
- acceptUpdate takes a reason phrase
- handle case where 481 is received (reSUB)
- handle case where events occur after subscription is ended

Dialog.cxx, Dialog.hxx
- forked() renamed to onForkAccepted()
- store map of all requests to handle 407/401 
- substantial changes in impl (see diffs)

DialogSet.cxx, DialogSet.hxx
- Profile related changes
- handle forking correctly
- change how destroying occurs (with events now)
- added a state machine
- significant changes in impl (see diffs)

DialogUsageManager.cxx, DialogUsageManager.hxx
- Profile related changes
- changes to how destroying objects (DialogSet, Dialog, Usages)
- significant changes in impl (see diffs)

DumTimeout.hxx
- added RegistrationRetry
- rename Forked to WaitingForForked2xx

Handled.cxx, Handled.hxx
- added dump

InviteSession.cxx, InviteSession.hxx
- significant changes in impl (see diffs and other notes)

InviteSessionCreator.cxx,InviteSessionCreator.hxx
- Profile related changes

InviteSessionHandler.cxx
- added onSessionExpired

Makefile
- removed DestroyUsage.cxx
- added MasterProfile, UserProfile

MergedRequestKey.cxx, MergedRequestKey.hxx
- added accessor for cseq

Profile.cxx, Profile.hxx
- major changes

PublicationCreator.cxx, PublicationCreator.hxx
- Profile related changes

RedirectHandler.cxx
- change in impl (see diffs)

RefCountedDestroyer
- no longer used

RegistrationCreator.cxx, RegistrationCreator.hxx
- Profile related changes

ServerInviteSession.cxx, ServerInviteSession.hxx
- significant impl and interface changes

ServerOutOfDialogReq
- Profile related changes

ServerSubscription.cxx
- minor impl changes (see diffs)

SubscriptionCreator.cxx, SubscriptionCreator.hxx
- Profile related changes


On Fri, 18 Mar 2005 16:12:29 -0800, Fischl jason <jason.fischl@xxxxxxxxx> wrote:
> Hi all,
> 
> There is a plan for a stable release. A stable release of resiprocate
> and dum  should come out  within a month or so of the sipit event (so
> end of April).
> 
> Anybody considering using resiprocate should really only consider
> using the main trunk. The teltel branch is explained in the email that
> started this thread (see below).
> 
> Jason
> 
> 
> On Fri, 18 Mar 2005 11:51:13 -0800, Jason Reich <jreich@xxxxxxxxxxxx> wrote:
> >
> > Hi all, I'm relatively new to resiprocate and the mailing list, and I've
> > been curious about the branches and development plan.  However, I haven't
> > been able to find much information on the website or in recent mailing list
> > discussions.
> >
> > Is there a plan for new stable releases of resiprocate?  0.4 is pretty
> > stale compared to what is in svn.  Is this merge part of a plan to get to a
> > new release?  What is(was) the teltel branch, and what are the other
> > branches of significance?  Is there a roadmap of branches and releases?
> >
> > Thanks for any light anyone can shed on this matter.  We've been using
> > Vocal for a while now and resiprocate has some pretty attractive new
> > features, but I'm curious about the future plan for resiprocate.
> >
> > thanks
> > Jason.
> >
> > At 04:07 PM 3/17/2005, Fischl jason wrote:
> > >In the next couple of days a branch in progress since November 2004 is
> > >going to be merged back to main. This has some interface changes. The
> > >result will be that the following branch will be merged back to main
> > >and development on this branch will be discontinued. I'm sure I've
> > >missed some stuff here - please let me know if you notice anything.
> > >
> > >https://scm.sipfoundry.org/rep/resiprocate/branches/b-teltel-20041118-invitesession
> > >
> > >
> > >Highlights of changes:
> > >---------------------------------
> > >
> > >- complete rewrite of the InviteSession incorporating state machines
> > >to handle PRACK and UPDATE.
> > >- interface changes in InviteSession
> > >- minor changes in InviteSessionHandler interface (see below for details)
> > >- switched to a more generic method of managing User Profiles
> > >- removed the DestroyerGuard from Dialog, DialogSet and derived
> > >BaseUsages - replaced with posting a Destroy Event.
> > >- significant changes to implementation of DialogSet
> > >- added a CancelMap to DUM to properly handle cancelled INVITEs as UAS
> > >- complete
> > >
> > >Summary of interface changes:
> > >----------------------------------------------
> > >
> > >InviteSession
> > >- provideOffer(const SdpContents&) and provideAnswer(const
> > >SdpContents&) instead of setOffer and setAnswer
> > >- the following methods (some renamed) do not return the SipMessage -
> > >they actually synchronously send
> > >   - reject(int code, WarningCategory*) instead of
> > >rejectDialogModification(int code)
> > >   - refer instead of makeRefer
> > >   - info  instead of makeInfo
> > >- removed acceptDialogModification(int) - use
> > >ServerInviteSession::accept instead
> > >- added some convenience accessors to an InviteSession
> > >   - const NameAddr& myAddr()  const
> > >   - const NameAddr& peerAddr()  const
> > >   - const SdpContents& getLocalSdp() const;
> > >   - const SdpContents& getRemoteSdp() const;
> > >   - bool isConnected() const;
> > >   - bool isTerminated() const;
> > >   - bool isEarly() const;
> > >
> > >ServerInviteSession
> > >- added redirect method to send 3xx response
> > >- end, provisional, reject, accept and redirect now synchronously send
> > >the message
> > >
> > >InviteSessionHandler
> > >- onTerminated now passes a TerminatedReason and a pointer to the
> > >related message (which can be 0)
> > >- onOffer/onAnswer take const SdpContents* instead of const SdpContents&
> > >- added onReferAccepted
> > >- onAckNotReceived doesn't have a const SipMessage& argument
> > >- added onSessionExpired
> > >
> > >Profile changes:
> > >- dum->setProfile is now dum->setMasterProfile
> > >- dum->getProfile is now dum->getMasterProfile
> > >- 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.
> > >- AppDialogSet now has a selectUASIdentity callback for the app to set
> > >the Identity for UAS DialogSets.
> > >
> > >DialogUsageManager changes:
> > >- cancel renamed to end
> > >
> > >
> > >Implementation/Merge Notes:
> > >-------------------------------------------
> > >
> > >InviteSessionHandler.hxx
> > >- added onForkDestroyed
> > >
> > >DumTimeout.hxx, DumTimeout.cxx
> > >-  added WaitingForForked2xx to fire after a 2xx is received to an
> > >INVITE as UAC. When timer fires, terminate all other forks that didn't
> > >receive a 2xx.
> > >
> > >DialogUsageManager.hxx
> > >- added CancelMap to keep track of all DialogSets for any UAS Invite
> > >transaction. Can use this to match the incoming CANCEL to the
> > >appropriate DialogSet
> > >
> > >DialogUsageManager.cxx
> > >- use Uri::removeEmbedded
> > >- don't copy from header when making a session from a REFER
> > >- reorg logic for incoming request (as UAS) to look first for to tag,
> > >then checking to see if the dialog already exists (requried for 2543
> > >UAC)
> > >- disallow out of dialog INFO
> > >- add in CANCEL processing on UAS based on CancelMap
> > >
> > >DialogSet.hxx
> > >- merged internal State for DialogSet from main branch
> > >- split handledByAuthOrRedirect out from ::dispatch (part of the merge
> > >from main branch)
> > >- added onForkAccepted to be called when 2XX is received as UAS
> > >- maintains the CancelMap in mDum (when DialogSet created or destroyed)
> > >
> > >DialogSet.cxx
> > >- use mState instead of mEnded, mReceivedProvisional, mReceivedFinal
> > >- eliminated mDestroying (may still be needed but suspect not)
> > >- maintain the mCancelMap in mDum
> > >- DialogSet::possiblyDie looks at mState
> > >- DialogSet::findDialog was greatly simplified - more complex stuff
> > >was commented out after discussion with dcm
> > >- much code is simplified due to new method of destroying DialogSet by
> > >posting an event - gets rid of destroy guards and wierd timing issues
> > >- split handledByAuthOrRedirect out of dispatch
> > >- reorg/refactored DialogSet::dispatch (mainly merged from main
> > >branch) but take into account new method of destroying the DialogSet
> > >- added code to call onForkAccepted
> > >- DialogSet::dispatch is the likeliest place for integration/merge problems
> > >- DialogSet::end refactored to use new mState
> > >- added DialogSet::dispatchToAllDialogs (from merge)
> > >
> > >Dialog.hxx
> > >- added onForkAccepted and cancel methods
> > >- added matches and handleTargetRefresh methods
> > >
> > >Dialog.cxx
> > >- merged in code for Dialog::handleTargetRefresh
> > >- reorg code related to making ServerSubscription due to a refer
> > >(doesn't do much validation of this)
> > >- added onForkAccepted to pass on to the ClientInviteSession usages
> > >
> > >ClientInviteSession.hxx
> > >- added onForkAccepted
> > >
> > >ClientInviteSession.cxx
> > >- when onForkAccepted is called in an early state, add a
> > >WaitingForForked2xx timer.
> > >- when timer fires, destroy the usage
> > >_______________________________________________
> > >resiprocate-devel mailing list
> > >resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > >https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
> >
>