Great, thanks Daniel - I will move stuff into the tmp
branch as well
Only if needed, as I said.
'tmp/' path is the one that can be used for any kind of branch out
of master where many people want to commit, until gets merged to
master.
Cheers,
Daniel
Cheers
Jason
On Wed, Nov 2, 2011 at 5:22 PM,
Daniel-Constantin Mierla <miconda@gmail.com>
wrote:
Hello,
I kind of forgotten to reply to this one, just refreshed
due to seeing the last commits on Jason's IMS branch...
What I wanted to say is that if you plan to share the
development effort among several people, which are going
to commit, then you can store the IMS branch under 'tmp/'
path, like 'tmp/IMS'. All branches under 'tmp/' can be
accessed in read/write mode by all developers, unlike
those under developer id path, which are accessible for
write only to that specific developer. Of course, you can
move back and forth, merge, etc. from tmp/ branch to
developer specific branch.
Cheers,
Daniel
On 10/21/11 4:38 PM, Richard Good wrote:
Hi
We are in the process of developing a branch for
Kamailio IMS extensions held at jason.penton/kamailio_ims_extensions
branch in the GIT repository. This branch
largely originates from the Open IMS Core project
and Carsten Block's Kamailio IMS branch with the
intention of using core, tried and tested Kamailio
modules (dialog, registrar, tm, usrloc, etc.) in
place of the custom defined functionality in the
Open IMS Core project.
In the coming weeks we will push modules and cfg
files to this branch to implement basic xCSCF
functionality, so watch this space.
Right now the branch includes stock standard
Kamailio 3.3.x with an overhauled dialog2 module
which is central to the functionality of the xCSCFs;
and a slightly modified rr module (one additional
method exposed to add mo/mt to the record-route).
For each dialog there is now a dlg_cell
structure with one or more dlg_out cell
structures.
Forked calls have multiple dlg_out structures;
once a call is confirmed all other dlg_out
structures are removed except for the confirmed
one.
Concurrent calls are allowed where multiple
dialogs are confirmed at the same time - in this
case a dlg_cell structure is created for each
confirmed dialog.
Dialog's can be terminated as in the previous
dialog module from mi, api and cfg; but this now
also caters for terminating early state /
unconfirmed dialogs.
Still TO DO: Integrate old dialog functionality for
dialog transfer, dialog database management,
statistics and RPC functions and general bug fixes
as they come up.
API changes: Two new exposed methods get_current_dialog
and terminate_dlg_with_id
We want to get as many eyes on the code as possible
to get it integrated into the master branch ASAP.