Hi Maxim,
Thank you for the valuable input - it is true what you are saying IF the
media relay has the ability to publish (or report) its internal load.
What you are describing here is what we did in terms of SIP call
balancing, with FreeSWITCH - local call counting versus pulling call
counters from FS.
In regards to the second topic, that is true also, let me give it some
thoughts. The only issue I see here is with "let each vendor to
implement proper hooks" :). But as concept it is something definitely
interesting.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11/11/2017 07:01 AM, Maxim Sobolev wrote:
Bogdan, with regards to the media relays clustering what's the
advantage of sharing that load info between each signalling node
versus having each node tracking this independently? In my view the
latter could be more reliable and much less complicated construct. The
only disadvantage is that you'd get more command load on relays,
however at least with the RTPproxy pulling load stats is very
lightweight operation so even with tens of signalling nodes pulling
single media relay every 1-10 seconds it won't cause any noticeable
performance degradation on the relay. On the flip side, each
signalling node would get accurate view from its vantage PoV, so in
the case of geographically distributed system when signalling node can
only see subset of all media nodes it would still be able to make
proper decisions. This is the approach we use in the rtp_cluster and
it works pretty well with cluster size of up to 5 signalling and 10
RTP handling nodes, 40-50K media sessions in total. It can also give
you accurate RTT information, so your signalling node can not only
factor in the load but also proximity or each and every media relay.
As far as the load tracking is concerned, I think the approach to
implement "b2b-driven routing" using API that is specific to each
particular b2b is somewhat wasteful and is not very future-proof. What
we would like to see instead, is for opensips to publish some kind of
API (preferably SIP-based, using OPTIONS or SUBSCRIBE/NOTIFY
mechanism) to pull this information out and let each b2b vendor to
implement proper hooks. Then it can go as far as making this info some
king of RFC.
Anyhow, just my $0.02c. Not volunteering to do opensips side
(ENOTIME), but if opensips project comes up with the reasonable
b2bua-agnostic load query API to use we might look at implementing it
in the sippy [py/go]-B2BUAs.
-Max
On Wed, Nov 8, 2017 at 9:31 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Nuno,
On the Asterisk part, the plan is to do exactly what we already
have for FreeSWITCH (see
https://blog.opensips.org/2017/03/01/freeswitch-driven-routing-in-opensips-2-3/
<https://blog.opensips.org/2017/03/01/freeswitch-driven-routing-in-opensips-2-3/>)
In terms of clustering media relays, is about the ability to share
the state (enabled/disabled) between all the cluster nodes using
the media relays. Optionally, we are looking in adding the ability
to balance the traffic between the relays, in a cluster-level
aware (all the nodes in the cluster will share the information on
the load of the media relays )
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
