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(a)gmail.com <mailto: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).
The dialog2 module implements the new dialog design according to:
http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-….
This allows for forked calls, concurrently confirmed calls and
proxy initiated dialog termination for early and confirmed dialogs.
* 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.
Regards
Richard.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla --http://www.asipto.com
Kamailio Advanced Training, Dec 5-8,
Berlin:http://asipto.com/u/kat
http://linkedin.com/in/miconda --
http://twitter.com/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla --
http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin:
http://asipto.com/u/kat
http://linkedin.com/in/miconda --
http://twitter.com/miconda