<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 6, 2018 at 2:43 AM, Olivier <span dir="ltr"><<a href="mailto:oza.4h07@gmail.com" target="_blank">oza.4h07@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Hello,<br><br></div>I'm currently trying to configure a passive Asterisk instance that must backup an active Asterisk instance.<br></div><div>Each instance is connected this way:<br></div><div>PSTN <---> Gateway <-- SIP --> Asterisk <-- SIP --> endpoints or IPBXs<br></div><div><br></div><div>Most endpoints connect through registration.<br></div><div><br></div></div>With chan_sip, Asterisk saved registration data in its database with lines such as:<br>/SIP/Registry/spa3102         <wbr>                    : <a href="http://192.168.64.207:5060" target="_blank">192.168.64.207:5060</a>:<a href="http://3600:7013:sip:spa3102@192.168.64.207:5060" target="_blank">3600:7013:<wbr>sip:spa3102@192.168.64.207:<wbr>5060</a><br><br></div>Reading such lines in active instance and copying them back in passive instance, I think you had a mean to have a passive instance ready to treat calls coming from PSTN as soon as it would become active (I never experimented with this).<br><br></div>Now, with PJSIP, Asterisk saves registration data with lines such as :<br></div>/registrar/contact/foobar: {"via_addr": ... }<br><br><br><br></div><div>Have you tried to copy such registration data from one instance to an aother one ?<br></div><div>What happened then ?<br><br></div><div>Best regards<br></div></div>
<br></blockquote><div><br></div><div>Well.......</div><div><br></div><div>First, you should probably just use a database that is not running on the same instance as Asterisk. You're assuming that when Asterisk dies on an instance that it's only Asterisk that is having a problem - in more critical failures, the AstDB (SQLite3) is going to be long gone as well. In less critical (but still severe) failures, Asterisk will probably just be restarted via safe_asterisk or something similar. With an external database such as MySQL/PostreSQL, you can have one instance of Asterisk store the registration information in the database (using Sorcery/realtime), and, if it dies, have a spare start up and use the same database for its backing storage. It will pick up the registration information, endpoint objects, etc.</div><div><br></div><div>That being said: yes, if you can find a way to get that JSON blob from one AstDB into another - and yes, there are ways that are sneaky but mostly involve shenanigans and/or custom code - than a second instance of Asterisk will understand and read that JSON just fine. Assuming it was told to get that information from its AstDB via Sorcery as well.</div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Matthew Jordan<br>Digium, Inc. | CTO<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div></div>