You might be right. I haven't used second parameter for set_rtpengine_set(), I don't recall who implemented it, but maybe someone else can confirm if it is like that and eventually add a clearer sentence there.
Cheers, Daniel On 09.11.23 16:26, Ben Kaufman wrote: > > 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(). > > --- > > > > > > > > *From:* Daniel-Constantin Mierla via sr-users > <sr-users@lists.kamailio.org> > *Sent:* Thursday, November 9, 2023 2:25 AM > *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org> > *Cc:* Daniel-Constantin Mierla <mico...@gmail.com> > *Subject:* [SR-Users] Re: Sharing load between rtpengine servers > > > > > > > *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: > > 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" > > <udp:11.11.11.11:7724=1udp:22.22.22.22:7724=99999999udp: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 -- 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:
