Re: [reSIProcate] merging teltel-branch to main (IMPORTANT)
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
>
>