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:
> 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 <abalas...@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.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
>     <dcunning...@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
>     <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@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-le...@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-le...@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-le...@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
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Reply via email to