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(a)gmail.com>
Sent: Monday, October 5, 2020 5:47 PM
To: Daniel-Constantin Mierla <miconda(a)gmail.com>om>; Kamailio (SER) - Development
Mailing List <sr-dev(a)lists.kamailio.org>
Cc: Henning Westerholt <hw(a)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@gmail.com<mailto:miconda@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@lists.kamailio.org<mailto:sr-dev@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@lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev