Now that we have worked to integrate modules_s and modules_k I find it a tiny bit disturbing to have dialog and dialog2.
What's the major difference? Would it be impossible to integrate?
/O
Olle E. Johansson writes:
Now that we have worked to integrate modules_s and modules_k I find it a tiny bit disturbing to have dialog and dialog2.
if modules are integrated, why there is still modules and modules_k directories?
also, it would make sense to have core directory that holds core files.
-- juha
On 03.01.2013 16:32, Olle E. Johansson wrote:
Now that we have worked to integrate modules_s and modules_k I find it a tiny bit disturbing to have dialog and dialog2.
What's the major difference? Would it be impossible to integrate?
Wasn't dialog2 just a recent commit (together with the IMS commits) and is a completely new module, and has nothing to do with ser?
klaus
Hi All,
Dialog2 is a start at the following: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d...
We needed this functionality for the IMS modules. In IMS a proxy can take the same session in both terminating and originating modes (ie 2 dialogs for the same session). dialog 1 does not support this. Dialog2 has been tested to at least support the functionality we required and we will build on it as we move along.
Docs are coming but please be patient - we are really busy at the moment, not just with ser/kamailio.
Cheers Jason
On Thu, Jan 3, 2013 at 6:14 PM, Klaus Darilion <klaus.mailinglists@pernau.at
wrote:
On 03.01.2013 16:32, Olle E. Johansson wrote:
Now that we have worked to integrate modules_s and modules_k I find it a tiny bit disturbing to have dialog and dialog2.
What's the major difference? Would it be impossible to integrate?
Wasn't dialog2 just a recent commit (together with the IMS commits) and is a completely new module, and has nothing to do with ser?
klaus
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3 jan 2013 kl. 17:40 skrev Jason Penton jason.penton@gmail.com:
Hi All,
Dialog2 is a start at the following: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d...
We needed this functionality for the IMS modules. In IMS a proxy can take the same session in both terminating and originating modes (ie 2 dialogs for the same session). dialog 1 does not support this. Dialog2 has been tested to at least support the functionality we required and we will build on it as we move along.
Docs are coming but please be patient - we are really busy at the moment, not just with ser/kamailio.
The question is if Dialog2 - as a superset - can handle the same stuff that dialog1 does?
/O
Right now it would be impossible if we want to be backwards compatible. I suppose we could look at pre processor defines to decide which version to use, but this could be equally as messy
-- This email was sent using my phone and may be brief, to the point or contain typos -- On Jan 3, 2013 6:45 PM, "Olle E. Johansson" oej@edvina.net wrote:
3 jan 2013 kl. 17:40 skrev Jason Penton jason.penton@gmail.com:
Hi All,
Dialog2 is a start at the following: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d...
We needed this functionality for the IMS modules. In IMS a proxy can take the same session in both terminating and originating modes (ie 2 dialogs for the same session). dialog 1 does not support this. Dialog2 has been tested to at least support the functionality we required and we will build on it as we move along.
Docs are coming but please be patient - we are really busy at the moment, not just with ser/kamailio.
The question is if Dialog2 - as a superset - can handle the same stuff that dialog1 does?
/O
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3 jan 2013 kl. 17:49 skrev Jason Penton jason.penton@gmail.com:
Right now it would be impossible if we want to be backwards compatible. I suppose we could look at pre processor defines to decide which version to use, but this could be equally as messy
Defines doesn't make sense. Can we rename dialog2 to ims-dialog so people understand that it's special for IMS?
/O
If the intent is to replace the current dialog implementation with this one or if the dialog2 is not ims specific, then we should rename-it to dialog-ng.
-ovidiu
On Thu, Jan 3, 2013 at 3:35 PM, Olle E. Johansson oej@edvina.net wrote:
3 jan 2013 kl. 17:49 skrev Jason Penton jason.penton@gmail.com:
Right now it would be impossible if we want to be backwards compatible. I suppose we could look at pre processor defines to decide which version to use, but this could be equally as messy
Defines doesn't make sense. Can we rename dialog2 to ims-dialog so people understand that it's special for IMS?
/O
3 jan 2013 kl. 21:46 skrev Ovidiu Sas osas@voipembedded.com:
If the intent is to replace the current dialog implementation with this one or if the dialog2 is not ims specific, then we should rename-it to dialog-ng.
Agree. So we need to figure out where we are heading with this so we can communicate this properly to our users.
/O
-ovidiu
On Thu, Jan 3, 2013 at 3:35 PM, Olle E. Johansson oej@edvina.net wrote:
3 jan 2013 kl. 17:49 skrev Jason Penton jason.penton@gmail.com:
Right now it would be impossible if we want to be backwards compatible. I suppose we could look at pre processor defines to decide which version to use, but this could be equally as messy
Defines doesn't make sense. Can we rename dialog2 to ims-dialog so people understand that it's special for IMS?
/O
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
3 jan 2013 kl. 17:14 skrev Klaus Darilion klaus.mailinglists@pernau.at:
On 03.01.2013 16:32, Olle E. Johansson wrote:
Now that we have worked to integrate modules_s and modules_k I find it a tiny bit disturbing to have dialog and dialog2.
What's the major difference? Would it be impossible to integrate?
Wasn't dialog2 just a recent commit (together with the IMS commits) and is a completely new module, and has nothing to do with ser?
Right, which is a bit annoying unless it's really impossible to merge them... At least it would be good for my curiousity to get an explanation :-)
/O