[sr-dev] extension of DMQ module to support several notifcation servers

[Henning Westerholt]

Hello,

thank you both for the reply. So, it seems that option 2) seems to be the preferred way.

We will investigate this then and if necessary, update this discussion.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>

From: Julien Chavanton <jchavanton at gmail.com>
Sent: Monday, October 5, 2020 5:47 PM
To: Daniel-Constantin Mierla <miconda at gmail.com>; Kamailio (SER) - Development Mailing List <sr-dev at lists.kamailio.org>
Cc: Henning Westerholt <hw at skalatan.de>
Subject: Re: [sr-dev] extension of DMQ module to support several notifcation servers

I would have selected #2 even if it is not clear just by reading config file if they will cumulate or override.

Now you will be asked to support both :)

On Mon, Oct 5, 2020 at 8:38 AM Daniel-Constantin Mierla <miconda at gmail.com<mailto:miconda at gmail.com>> wrote:

Hello,

the problem I see with 1) is in case one wants to set there SIP URI for other transports than UDP, the ; is used to separate URI parameters as well. I think now it supports only UDP anyhow, but to have it open for future, this should be kept in mind

From my point of view, for the modules I work with and develop, the style of separating with ; within same modparam value suits for sip-params-like-values, respectively name1=value1;name2=value2; ... because parase param function can be used. In this case, a value can contain ; but the entire value has to be enclosed in quotes.

So far 1) maybe another delimiter between URIs should be used, like comma.

Personally I would like more for 2), it is more compact in case one uses many addresses, not to have a single very long value, but I don't really mind 1) with a different separator (at the end both variants can be supported :-) , but more coding is needed, without much benefits ...)

Cheers,
Daniel
On 05.10.20 17:25, Henning Westerholt wrote:
Hello,

one question about a planned extension in the DMQ module. Right now the module supports only one server in the notification_address parameter. It is possible to set multi_notify to 1, and then the module will resolve the one sip URI over DNS to multiple servers, thought.

There is interest in extending the module to support multiple notification_address servers natively without using DNS. I see two options right now:

1.       Separate the multiple servers, with “;”, e.g. modparam(“dmq”, “notification_address”, “sip:server1;sip:server2”). If only one server in the param, use the existing logic.
2.       Use multiple notification_servers parameter calls, e.g. modparam(“dmq”, “notification_address”) - modparam(“dmq”, “notification_address”, “sip:server2”). If only one param statement, use the existing logic.

As the module already has support to use a notification server list internally, the change should be small in both cases.

I think option 1) is the better way, as its already done in other modules like this to support multiple server scenarios.

Any comments or objections about this extension?

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>



_______________________________________________

Kamailio (SER) - Development Mailing List

sr-dev at lists.kamailio.org<mailto:sr-dev at lists.kamailio.org>

https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

--

Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>

www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>

Funding: https://www.paypal.me/dcmierla
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev at lists.kamailio.org<mailto:sr-dev at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20201006/fb1076de/attachment-0001.htm>