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(a)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
_______________________________________________
Kamailio (SER) - Development Mailing
Listsr-dev@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla --
www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding:
https://www.paypal.me/dcmierla
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev