Hello,
not sure why that remark is there, because contradicts with the first
paragraph that has:
"Sets the ID of the RTP proxy set to be used for the next
rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or
rtpengine_manage() command."
-
I don't think that the last statement is good, maybe it propagated
without notice from a very old version. From code point of view, there
is no reason for set_rtpengine_set() not to work for rtpengine_manage(),
this function is a pretty simple wrapper for
rtpengine_offer()/_answer()/_delete().
I am going to remove that last statement from docs.
Cheers,
Daniel
On 09.11.23 01:06, David Cunningham via sr-users wrote:
Hi Alex,
It's on the page that you linked to: "This is supported by all
rtpengine commands except rtpengine_manage()."
Thanks.
On Thu, 9 Nov 2023 at 12:55, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Hi David,
Whence the impression that sets aren't compatible with
rtpengine_manage()?
https://kamailio.org/docs/modules/5.7.x/modules/rtpengine.html#rtpengine.f.…
"Sets the ID of the RTP proxy set to be used for the next
rtpengine_delete(),
rtpengine_offer(), rtpengine_answer() or rtpengine_manage()
command. The parameter
can be an integer or a config variable holding an integer."
Or are you using an earlier version of Kamailio in which this may
not have been true?
-- Alex
On 8 Nov 2023, at 18:52, David Cunningham
<dcunningham(a)voisonics.com> wrote:
Hi Alex,
Thank you for the reply. We use a large weight of 99999999 to
send almost all calls to the 22.x and 33.x servers without using
sets. We avoided sets because our Kamailio configuration uses
rtpengine_manage(), which according to the documentation is not
compatible with set_rtpengine_set(). I'll try it without the 11.x
server and the large weights, and see if the calls are evenly
distributed between the 22.x and 33.x servers then.
Thanks again.
On Thu, 9 Nov 2023 at 10:25, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hi,
From the docs:
"The balancing inside a set is done automatically by the module
based on the weight of each RTPEngine from the set. The default
weight is 1, if another RTPEngine should be used twice as often as
the first one, one would specify the weight 2 for this server, for
example."
I am unsure as to what effect such large values as 99999999
might have on this arithmetic.
It seems to me that if what you really want to accomplish is to
evenly distribute calls between 22.22.22.22 and 33.33.33.33, with
11.11.11.11 only as a last-resort backup, then you should put the
first two into one naive set without any weights, e.g.
modparam("rtpengine_sock", "1 == udp:22.22.22.22:7724
<http://22.22.22.22:7724> udp:33.33.33.33:7724
<http://33.33.33.33:7724>")
Then put 11.11.11.11 into a set of its own:
modparam("rtpengine_sock", "2 == udp:11.11.11.11:22724
<http://11.11.11.11:22724>")
By default, set 1 should be invoked:
set_rtpengine_set("1");
rtpengine_{offer,manage}("...");
According to the docs, rtpengine_offer() will return a negative
value if there is a failure of both:
"The function will return true on success and false (-1) on
various failures, like
using rtp_engine_offer() on a SIP MESSAGE
request or
communication with rtpengine fails."
Presumably, rtpengine_manage() does the same. Accordingly, you
can do something like:
set_rtpengine_set("1");
if(!rtpengine_offer("...")) {
if($rc == -1) {
set_rtpengine_set("2");
rtpengine_offer("...");
}
}
Exact details and your mileage may vary.
-- Alex
> On 8 Nov 2023, at 15:33, David Cunningham via sr-users
<sr-users(a)lists.kamailio.org> wrote:
>
> Hello,
>
> We have a Kamailio configuration with the following, however
all the load is going to the server at 22.22.22.22 (hiding the
real IP obviously) instead of being shared evenly between
22.22.22.22 and 33.33.33.33. Can anyone please tell me why? The
rtpengine server at 11.11.11.11 is intended to only receive calls
if the other two are offline. Thank you very much.
>
> #!define RTPENGINE_ADDR "udp:11.11.11.11:7724=1
udp:22.22.22.22:7724=99999999 udp:33.33.33.33:7724=99999999"
>
> modparam( "rtpengine", "rtpengine_sock", RTPENGINE_ADDR )
>
> --
> David Cunningham, Voisonics Limited
>
http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not
reply only to the sender!
Edit
mailing list options or unsubscribe:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://evaristesys.com
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!
Edit mailing list options or unsubscribe:
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://evaristesys.com
Tel: +1-706-510-6800
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
Kamailio Consultancy and Development Services
Kamailio Advanced Training - Online - Nov 14-16, 2023 --