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 List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev