[OpenSIPS-Users] OpenSIPs + RTP High Availability Plans

[Callum Guy]

Hi All,

Just wondering if this mail came through? Be very interested in hearing if
anyone has any ideas regarding a "multi-master" rtp proxy service.

To date the closest I have found is a Redis plugin for RTPEngine whih
provides some concept of shared state however I wonder if there is a
simpler approach out there (
https://github.com/ngvoice/rtpengine-redis-plugin)

Best Regards,

Callum

On Wed, Jun 27, 2018 at 11:45 AM Callum Guy <callum.guy at x-on.co.uk> wrote:

> Hi All,
>
> I am looking into updating my network to support live failover between two
> OpenSIPs instances acting as an HA pair. We use a VIP address and want to
> allow calls and audio streams to be maintained in the event of a single
> node failure. At present the system works and allows new calls to be
> processed when one node goes away however any active calls lose their media
> streams.
>
> I’ve started exploring my options and am open to the idea of moving to use
> RTPEngine or implementing some state storage in RTPProxy (if such a thing
> exists) but I wanted to reach out to the community to get an experienced
> opinion while I’m gathering ideas.
>
> I would very much appreciate any ideas/thoughts and have tried to explain
> the current deployment below, just let me know if you need more details.
>
> *Current Setup*
> Two identical CentOS 7.5 instances running OpenSIPs 2.3.3 and RTPProxy
> 2.0.0.
> The servers have individual IP addresses 172.18.0.111 and 172.18.0.112.
> External traffic hits a single static public IP (*8.8.8.8* for
> illustrative purposes) which forwards SIP+RTP traffic to a floating IP
> address *172.18.0.110* (keepalived) which is owned by the current master
> instance.
> All traffic is then forwarded on to an internal IVR platform (FreeSWITCH)
> so OpenSIPs is just acting as a pure B2BUA proxy which needs to work in
> both directions (i.e. some calls originate from the IVR as well as carrier
> network calls coming in).
>
> *OpenSIPs/RTPProxy Setup*
> RTPProxy is served on a local socket
> “unix:/var/run/rtpproxy/rtpproxy.sock”.
> When an INVITE is being processed we run "rtpproxy_offer(“rfo”, [*8.8.8.8*
>  or *172.18.0.110* ])" in accordance with the request direction.
> When any reply is received our onreply_route will invoke
> "rtpproxy_offer(“rfo”, [*8.8.8.8* or *172.18.0.110* ])" again in
> accordance with the request direction.
>
> Hopefully that is clear - the idea is to allow the remote systems to be
> completely agnostic to which proxy handled the traffic. I presume that the
> main issue is that the backup RTPProxy instance is unaware of the current
> state and is not listening on the necessary ports and that this is
> something which can be addressed?
>
> Finally if anyone has any other advice/articles regarding using OpenSIPs
> in this way (dialog failover, using 2.4 features etc) then this would be
> gratefully received!
>
> Many thanks,
>
> Callum
> --
> Callum Guy
> Head of Information Security
> X-on
>
-- 
Callum Guy
Head of Information Security
X-on

-- 





*0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   ** 
<https://www.linkedin.com/company/x-on>   <https://www.facebook.com/XonTel> 
  <https://twitter.com/xonuk> *


























X-on
is a trading 
name of Storacall Technology Ltd a limited company registered in
England 
and Wales.

Registered Office : Avaland House, 110 London Road, Apsley, 
Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.

The 
information in this e-mail is confidential and for use by the addressee(s)

only. If you are not the intended recipient, please notify X-on immediately 
on +44(0)333 332 0000 and delete the
message from your computer. If you are 
not a named addressee you must not use,
disclose, disseminate, distribute, 
copy, print or reply to this email. Views
or opinions expressed by an 
individual
within this email may not necessarily
reflect the views of X-on 
or its associated companies. Although X-on routinely
screens for viruses, 
addressees should scan this email and any attachments
for
viruses. X-on 
makes no representation or warranty as to the absence of viruses
in this 
email or any attachments.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180702/c13f9f16/attachment-0001.html>