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

[Daniel-Constantin Mierla]

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/ <https://skalatan.de/blog/>
>
> Kamailio services – https://gilawa.com <https://gilawa.com/>
>
>  
>
>
> _______________________________________________
> Kamailio (SER) - Development Mailing List
> sr-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20201005/9baeda1a/attachment-0001.htm>