[sr-dev] [rtpproxy module] set_rtp_proxy_set() to allow pv as parameter

Hi, using multiple RtpProxy instancies would be more flexible if set_rtp_proxy_set() allows a pseudo-variable instead of just a fixed integer. Without this feature, it's impossible to implement real RtpProxy loadbalancing since: how to use the same RtpProxy for an in-dialog request? Let me show an example: - Let's suppose we have these rtpproxies: modparam("nathelper", "rtpproxy_sock", "1 == udp:1.1.1.1:12221") modparam("nathelper", "rtpproxy_sock", "2 == udp:2.2.2.2:12221") (note that I don't use various rtpproxies in the same set since with the, real loadbalancing it's not possible). - An INVITE arrives and we want to use a ramdom rtpproxy (set 1 or 2). Since set_rtp_proxy_set() doesn't allow pv, the only way is something as computing the from_tag or call-id and get values 0 or 1 (or 1 or 2). In the first case we invoke set_rtp_proxy_set("1") and in the second set_rtp_proxy_set("2"). - When processing the 183/200 response we should do the same (get 1 or 2 from the from_tag or call-id), or perhaps add a parameter in RR (rtpproxy_set=1) and invoke the corresponding set_rtp_proxy_set() function. - The same for every in-dialog request (re-INVITE, BYE...). I understand that this mechanims is not really scalable since adding a new rtpproxy requires modifications in the kamailio script (the ramdom function which now should return 1, 2 or 3 depending on the call-id/from_tag hash or something similar) and also adding a new "else if (XXXXX) { set_rtp_proxy_set("3") ... }" So, extending set_rtp_proxy_set() to allow pv would mitigate this issue: - When the INVITE arrives a ramdom function returns 1,2,3..., we store that value in a pv and use it into set_rtp_proxy_set(). - We also store that value in a RR param to retrieve it in replies and in- dialog requests in order to invoke the samertpproxy set. About various rtpproxy instances per set: I consider there is no solution for it. If we have: # multiple rtproxies for LB modparam("nathelper", "rtpproxy_sock", "udp:localhost:12221 udp:localhost:12222") We invoke "rtpproxy_offer" and some rtpproxy has been transparently selected, but we CANNOT know which one, so, how to reuse it in the reply and in-dialog requests?? I remember a thread about it in which the code was inspected and some "hash algorithm" resulted to take place to select the rtpproxy instance. However I remember that this algorithm is not so robust as required for a real loadbalancing system. So, in conclusion, is there any aim in improving RtpProxy module to allow real and robust load-balancing? What about multiple rtpproxy instances in the same set? is it really usable? Thanks a lot for any comment on it. -- Iñaki Baz Castillo <ibc(a)aliax.net>