Thank you, Daniel!

I was just confused because I do use set_rtpengine_set() with 
rtpengine_manage() quite a lot, for some years now, and it works fine...

-- Alex

> On 9 Nov 2023, at 03:24, Daniel-Constantin Mierla via sr-users 
> <sr-users@lists.kamailio.org> wrote:
> 
> 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 
>> > 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-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:

-- 
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:

Reply via email to