[Kamailio-Users] NAThelper and multipart SDP

[Iñaki Baz Castillo]

El Miércoles, 24 de Junio de 2009, Daniel-Constantin Mierla escribió:
> > - rtpproxy seems to not take advantage of SMP
>
> it is well known, but you can run one or two instances per core and load
> balance from the nathelper module. I usually start 2 per cpu core.

I've asked some times some doubts about this supposed "load balance" system 
(which I can't trust at 100%). 

Which the current RtpProxy documentation there is no info enough to ensure 
that load balancing should work correctly.
I sent the following mail to rtpproxy-dev maillist but unfortunatelly got no 
reply. Perhaps I could receive now some comments on it? I'd really appreciate 
them.

My mail ot rtpproxy-dev ML:

----------------------------
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 at aliax.net>