1 Apr
2009
1 Apr
'09
5:16 p.m.
Hi,
>>>> Frank Durda IV
<frank.durda(a)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.
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com