Hi, I agree, if the dialog_ng module is only used with IMS deployments, it may be confusing that it's called dialog_ng (despite the original ideas/thoughts, Richard mentioned). I have no objections renaming it to ims_dialog; if we manage to merge it at some point with the existing dialog-module and make the functionality more generic, we can rename it back to dialog_ng or similar later.
Thanks, Carsten 2015-12-15 20:50 GMT+01:00 Richard Good <richard.g...@smilecoms.com>: > Hi Daniel > > As you mentioned the original reason for this module was not IMS but rather > to support some new features, in particular forking. It is not > particularly specific to IMS. > > Unfortunately we have not managed to merge with the normal dialog module as > we had originally intended. > > I do hope at some point we manage to merge the two modules so each can > benefit for the others fixes but think it will be quite an endeavour. > > Having said this I have no issue with renaming the module or explicitly > explaining in the documentation if it is causing any confusion. > > Let's see if the other IMS devs agree. > > Regards > Richard. > > On 15 Dec 2015 2:52 PM, "Daniel-Constantin Mierla" <mico...@gmail.com> > wrote: >> >> Hello, >> >> I am under the impression that the name dialog_ng creates confusion out >> there and some people are using it instead of the classic dialog module. >> >> Although it was started with goals of reworking dialog module with a >> different concept (which was discussed mainly by some guys that >> afterwards changed their job to non-voip area), dialog_ng ended up to be >> tailored for IMS needs. >> >> Probably we should do that refactoring of the dialog module, but >> meanwhile dialog_ng doesn't refect that and some people are confused by >> the current naming of the two modules. >> >> Practically is more about convenience at this moment and if IMS >> developers and users think it is not going to be a big overhead for >> their deployments to be upgraded, I can take care to rename it. So, >> while general opinion matters, I think we should see first what IMS devs >> prefer. >> >> I am personally not affected that much, so I am fine to keep it like it >> is now -- in that case, proper notes should be added to documentation, >> stating that dialog_ng must be used only for IMS (or when the config >> writer knows very well what she/he is doing). >> >> Cheers, >> Daniel >> >> -- >> Daniel-Constantin Mierla >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> Book: SIP Routing With Kamailio - http://www.asipto.com >> http://miconda.eu >> >> >> _______________________________________________ >> sr-dev mailing list >> sr-...@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > This email is subject to the disclaimer of Smile Communications at > http://www.smilecoms.com/home/email-disclaimer/ > > > _______________________________________________ > sr-dev mailing list > sr-...@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany http://www.ng-voice.com mailto:cars...@ng-voice.com Office +49 40 5247593-0 Fax +49 40 5247593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/ _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
