Hi,
Frank Durda IV frank.durda@hypercube-llc.com wrote:
So, this means that each time force or unforce rtpproxy calls, this same hash gets performed on the same Call-ID for a given call, and except for rare cases where a proxy has failed, you will end up sending the force/unforce for a given Call-ID to the same rtpproxy instance every time. At least, this is how I read the source code.
Yes, that's how it works and that was the task when we were writing this code. In absense of dialog state in SER (the most primitive one was invented a few months later) and need to keep a characteristics which is stable during the stable work, the only solution was a kind of hashing by dialog ID among alive proxies. If alive proxy set is changed, this does it best - keeps the calls which doesn't need re-INVITE and allows them to work in most cases after re-INVITE if used in simple scenario.
I'll point out that if the initial selection of rtpproxy from the first force_rtp_proxy() of a given call session had simply been recorded as an integer somewhere with the other trivia that is maintained for the duration of a given call session, nathelper wouldn't have to burn cycles and time recomputing the hash as many as additional three times for the typical call (two more force_rtp_proxy() calls for 183 and 200 responses, then an unforce_rtp_proxy() to tear things down), but that's the limited behavior that exists in there today.
This requires to maintain dialog state. In PortaSIP, we later moved this to B2BUA because it already maintains dialog state and we didn't need to extend SER which programming is extremely hard. This was approx. version 0.9.3. If current implementation allows custom per-transaction and per-dialog variables kept through lifetime of according object, this would be rewritten with new mechanisms.