Agreed
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.good@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" <miconda@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-dev@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-dev@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:carsten@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/
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev