[Serusers] How rest of call is steered to same rtpproxy instance ( was Re: Running multiple instances of rtpproxy...)

Valentin Nechayev netch at portaone.com
Wed Apr 1 08:16:51 CEST 2009


Hi,

>>>>> Frank Durda IV <frank.durda at 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 at portaone.com



More information about the sr-users mailing list