From a strictly linguistic point of view
the sentence, “This is supported by all rtpengine commands
except rtpengine_manage()” is at the end of the second
paragraph, which is in reference to the second argument. I
would take it to mean that the second argument is not
supported by rtpengine_manage() – not that the entire function
is not supported. Does that seem correct?
As reference the full section:
---
5.1. set_rtpengine_set(setid[, setid])
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.
A second set ID can be specified to
daisy-chain two RTP proxies. The two set IDs must be distinct
from each other and there must not be any overlap in the
proxies present in both sets. In this use case, the request
(offer, answer, etc) is first sent to an RTP proxy from the
first set, which rewrites the SDP body and sends it back to
the module. The rewritten SDP body is then used to make
another request to an RTP proxy from the second set, which
rewrites the SDP body another time and sends it back to the
module to be placed back into the SIP message. This is useful
if you have a set of RTP proxies that the caller must use, and
another distinct set of RTP proxies that the callee must use.
This is supported by all rtpengine commands except
rtpengine_manage().
---
|
CAUTION: This
email originated from outside the organization.
Do not click links or open attachments
unless you recognize the sender and know the
content is safe.
|
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."
-
https://www.kamailio.org/docs/modules/stable/modules/rtpengine.html#rtpengine.f.set_rtpengine_set
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:
It's on the page that you linked
to: "This is supported by all rtpengine commands
except rtpengine_manage()."
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.set_rtpengine_set
"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@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@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 udp: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")
>
> 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@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@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@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@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com