5 Oct
2020
5 Oct
'20
11:37 a.m.
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(a)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