<div dir="ltr">Hi All,<div><br></div><div>Just wondering if this mail came through? Be very interested in hearing if anyone has any ideas regarding a "multi-master" rtp proxy service. </div><div><br></div><div>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 (<a href="https://github.com/ngvoice/rtpengine-redis-plugin">https://github.com/ngvoice/rtpengine-redis-plugin</a>)</div><div><br></div><div>Best Regards,</div><div><br></div><div>Callum</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 27, 2018 at 11:45 AM Callum Guy <<a href="mailto:callum.guy@x-on.co.uk">callum.guy@x-on.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi All,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>Current Setup</b></div><div>Two identical CentOS 7.5 instances running OpenSIPs 2.3.3 and RTPProxy 2.0.0. </div><div>The servers have individual IP addresses 172.18.0.111 and 172.18.0.112.</div><div>External traffic hits a single static public IP (<b><i>8.8.8.8</i></b> for illustrative purposes) which forwards SIP+RTP traffic to a floating IP address <b><i>172.18.0.110</i></b> (keepalived) which is owned by the current master instance. </div><div>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).</div><div><br></div><div><b>OpenSIPs/RTPProxy Setup</b></div><div>RTPProxy is served on a local socket “unix:/var/run/rtpproxy/rtpproxy.sock”. </div><div>When an INVITE is being processed we run "rtpproxy_offer(“rfo”, [<i style="font-weight:bold">8.8.8.8</i> or <b><i>172.18.0.110</i></b> ])" in accordance with the request direction.</div><div>When any reply is received our onreply_route will invoke "rtpproxy_offer(“rfo”, [<b><i>8.8.8.8</i></b> or <b><i>172.18.0.110</i></b> ])" again in accordance with the request direction.</div><div><br></div><div>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?</div><div><br></div><div>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!</div><div><br></div><div>Many thanks,</div><div><br></div><div>Callum</div></div>-- <br><div dir="ltr" class="m_6635304469553592673gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Callum Guy<div>Head of Information Security</div><div>X-on</div></div></div>
</blockquote></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Callum Guy<div>Head of Information Security</div><div>X-on</div></div></div>
<br>
<p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt;text-align:justify"><font size="3" face="Verdana"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></font></p><img src="https://www.x-on.co.uk/email/footer/banner-surgeryconnect-june-july.jpg"><br><p><font size="4"><span style="font-size:8px;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span><b><sup><font face="Verdana">0333 332 0000 | <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a> | <sub> </sub></font></sup></b></font><font size="4"><b><sub><sup><font face="Verdana"><a href="https://www.linkedin.com/company/x-on" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a> <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a> <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a></font></sup></sub> </b></font>
<span style="font-size:6.0pt;font-family:Verdana;color:black"><br>X-on
is a trading name of Storacall Technology Ltd a limited company registered in
England and Wales.<br>
Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead,
Herts, HP3 9SD. Company Registration No. 2578478.<br>
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 <span>+44(0)333 332 0000</span> and delete the<br>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. </span><span style="font-size:6.0pt;font-family:Verdana;color:black">Views
or opinions expressed by an individual<br>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<br>for
viruses. X-on makes no representation or warranty as to the absence of viruses
in this email or any attachments.</span></p>
<p><span style="font-size:6.0pt;font-family:Verdana;color:black"></span><font size="2"><span style="font-size:6.0pt;font-family:Verdana;color:black"></span></font></p>