<div dir="ltr"><div>Hi Răzvan,</div><div><br></div><div>First of all, thanks for looking into this.<br></div><div><br></div><div>So, here's what's in that picture, I had to rebuild my entire lab, so ips changed:</div><div><br></div><div>192.168.56.124 is asterisk, sending a call to a floating ip</div><div>192.168.56.120 is a floating ip, managed by keepalived, with opensips/rtpengine</div><div><br></div><div>And this is what happens:</div><div>- asterisk sends a call through the primary opensips/rtpengine</div><div>- call is established<br></div><div>- network on the primary opensips fails (note that the opensips service is still running, but there's no network, no access to the shared mongodb, no rtp)</div><div>- secondary opensips/rtpengine takes the floating ip and re-INVITEs the call</div><div>- asterisk accepts the in-dialog INVITE and rtp is re-established through the secondary opensips/rtpengine<br></div><div>- network on the primary opensips is restored</div><div>- primary opensips takes the floating ip back and re-INVITEs the call</div><div>- asterisk replies with "500 Invalid CSeq"</div><div><br></div><div><span style="font-family:monospace">              192.168.56.124                192.168.56.120<br>          ──────────┬─────────          ──────────┬─────────<br>  14:24:55.900819   │        INVITE (SDP)         │<br>        +0.000562   │ ──────────────────────────> │<br>  14:24:55.901381   │     100 Giving it a try     │<br>        +0.000000   │ <────────────────────────── │<br>  14:24:55.901381   │     100 Giving it a try     │<br>        +0.002552   │ <<<──────────────────────── │<br>  14:24:55.903933   │         180 Ringing         │<br>        +3.008060   │ <────────────────────────── │<br>  14:24:58.911993   │        200 OK (SDP)         │<br>        +0.001352   │ <────────────────────────── │<br>  14:24:58.913345   │             ACK             │<br>                    │ ──────────────────────────> │<br>                    │      RTP (g711a) 2255       │<br>  14:24:58.970785   │10700 ────────────────> 13650│<br>                    │      RTP (g711a) 2104       │<br>       +45.796826   │10700 <──────────────── 13650│<br>  14:25:44.710171   │        INVITE (SDP)         │<br>        +0.001247   │ <────────────────────────── │<br>  14:25:44.711418   │        200 OK (SDP)         │<br>        +0.000309   │ ──────────────────────────> │<br>  14:25:44.711727   │             ACK             │<br>                    │ <────────────────────────── │<br>                    │      RTP (g711a) 4033       │<br>  14:25:44.714624   │10700 ────────────────> 18640│<br>                    │      RTP (g711a) 2189       │<br>       +44.573254   │10700 <──────────────── 18640│<br>  14:26:29.284981   │        INVITE (SDP)         │<br>        +0.000196   │ <────────────────────────── │<br>  14:26:29.285177   │      500 Invalid CSeq       │<br>        +0.000224   │ ──────────────────────────> │<br>  14:26:29.285401   │             ACK             │<br>       +53.726523   │ <────────────────────────── │<br>  14:27:23.011924   │             BYE             │<br>        +0.006234   │ ──────────────────────────> │<br>  14:27:23.018158   │      500 Invalid CSeq       │<br>                    │ <────────────────────────── │</span></div><div><br></div><div><br></div><div><br></div><div>the commands I use to move the call when the ip floats are:</div><div><span style="font-family:monospace">opensips-cli -x mi clusterer_shtag_set_active test1/1<br>while IFS='' read -r callid; do<br>  opensips-cli -x mi dlg_send_sequential callid=${callid} mode=challenge body=inbound<br>done < <(opensips-cli -x mi dlg_list | jq -r '.Dialogs[] | .callid')</span><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 Jun 2024 at 12:49, Răzvan Crainea <<a href="mailto:razvan@opensips.org">razvan@opensips.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, Alberto!<br>
<br>
Unfortunately the image you provided that shows how to migrate calls <br>
back to the primary server does no longer work. Can you please re-share <br>
it, or, explain what you want to show/prove in that image? Is the <br>
re-INVITE sent and properly accepted?<br>
<br>
Best regards,<br>
<br>
Răzvan Crainea<br>
OpenSIPS Core Developer / SIPhub CTO<br>
<a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">http://www.opensips-solutions.com</a> / <a href="https://www.siphub.com" rel="noreferrer" target="_blank">https://www.siphub.com</a><br>
<br>
On 5/31/24 12:15 AM, Alberto wrote:<br>
> Hi,<br>
> <br>
> I'm testing<br>
> <a href="https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/" rel="noreferrer" target="_blank">https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/</a><br>
> and I have a problem with re-homing calls from the backup server back to<br>
> the primary server.<br>
> <br>
> My configuration is as follows:<br>
> shared mongodb : 172.20.2.19<br>
> opensips virtual floating ip : 172.20.2.20<br>
> opensips-0 : 172.20.2.21<br>
> opensips-1 : 172.20.2.22<br>
> <br>
> to float the ip, i'm using keepalived monitoring both the network and the<br>
> opensips process.<br>
> When it detects the virtual ip has become available locally, keepalived<br>
> does this:<br>
> <br>
> opensips-cli -x mi clusterer_shtag_set_active testtag/1<br>
> opensips-cli -x mi dlg_list | jq -r '.Dialogs[] | .callid' | while IFS=''<br>
> read -r callid; do<br>
>    opensips-cli -x mi dlg_send_sequential callid=${callid} mode=challenge<br>
> body=inbound<br>
> done<br>
> <br>
> Now I'm testing 2 scenarios, in the first one the opensips process on the<br>
> primary server terminates, in the second scenario the network to the<br>
> primary server is interrupted.<br>
> In both cases I expect calls to be re-homed to the backup server (which<br>
> always happens) and to come back to the primary server when the problem has<br>
> been resolved (which doesn't always happen).<br>
> <br>
> Here's the breakdown of the 2 tests.<br>
> <br>
> So, when I start a call through opensips-0 and then kill the opensips<br>
> process, the virtual ip floats to the secondary server, and all calls are<br>
> migrated to the backup server.<br>
> When the opensips process is restarted, the ip floats back to the primary<br>
> server and all calls are migrated back.<br>
> All good here.<br>
> <br>
> However, when I start a call through opensips-0 and pull the network cable,<br>
> the virtual ip floats to the secondary server and all calls are migrated.<br>
> But, when the network is restored and the ip floats back to the primary<br>
> server, calls fail to migrate back.<br>
> In the screenshot attached here you can see the invite that should migrate<br>
> the calls back to the primary server.<br>
> <a href="https://ibb.co/m4trL1Y" rel="noreferrer" target="_blank">https://ibb.co/m4trL1Y</a><br>
> Note that in this second scenario opensips loses connectivity, but it<br>
> doesn't restart.<br>
> <br>
> I tried to do `opensips-cli -x mi dlg_cluster_sync` and/or `opensips-cli -x<br>
> mi dlg_restore_db` on the primary server before the tag is set to active<br>
> and calls are migrated back, but it didn't help.<br>
> <br>
> I hope this makes some sense.<br>
> Is there any other info or test I can provide?<br>
> Thanks<br>
> AR<br>
> <br>
> <br>
> Hi,<br>
> <br>
> I'm testing <br>
> <a href="https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/" rel="noreferrer" target="_blank">https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/</a> <<a href="https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/" rel="noreferrer" target="_blank">https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/</a>> and I have a problem with re-homing calls from the backup server back to the primary server.<br>
> <br>
> My configuration is as follows:<br>
> shared mongodb : 172.20.2.19<br>
> opensips virtual floating ip : 172.20.2.20<br>
> opensips-0 : 172.20.2.21<br>
> opensips-1 : 172.20.2.22<br>
> <br>
> to float the ip, i'm using keepalived monitoring both the network and <br>
> the opensips process.<br>
> When it detects the virtual ip has become available locally, keepalived <br>
> does this:<br>
> <br>
> opensips-cli -x mi clusterer_shtag_set_active testtag/1<br>
> opensips-cli -x mi dlg_list | jq -r '.Dialogs[] | .callid' | while <br>
> IFS='' read -r callid; do<br>
>    opensips-cli -x mi dlg_send_sequential callid=${callid} <br>
> mode=challenge body=inbound<br>
> done<br>
> <br>
> Now I'm testing 2 scenarios, in the first one the opensips process on <br>
> the primary server terminates, in the second scenario the network to the <br>
> primary server is interrupted.<br>
> In both cases I expect calls to be re-homed to the backup server (which <br>
> always happens) and to come back to the primary server when the problem <br>
> has been resolved (which doesn't always happen).<br>
> <br>
> Here's the breakdown of the 2 tests.<br>
> <br>
> So, when I start a call through opensips-0 and then kill the opensips <br>
> process, the virtual ip floats to the secondary server, and all calls <br>
> are migrated to the backup server.<br>
> When the opensips process is restarted, the ip floats back to the <br>
> primary server and all calls are migrated back.<br>
> All good here.<br>
> <br>
> However, when I start a call through opensips-0 and pull the network <br>
> cable, the virtual ip floats to the secondary server and all calls are <br>
> migrated.<br>
> But, when the network is restored and the ip floats back to the primary <br>
> server, calls fail to migrate back.<br>
> In the screenshot attached here you can see the invite that should <br>
> migrate the calls back to the primary server.<br>
> <a href="https://ibb.co/m4trL1Y" rel="noreferrer" target="_blank">https://ibb.co/m4trL1Y</a> <<a href="https://ibb.co/m4trL1Y" rel="noreferrer" target="_blank">https://ibb.co/m4trL1Y</a>><br>
> Note that in this second scenario opensips loses connectivity, but it <br>
> doesn't restart.<br>
> <br>
> I tried to do `opensips-cli -x mi dlg_cluster_sync` and/or `opensips-cli <br>
> -x mi dlg_restore_db` on the primary server before the tag is set to <br>
> active and calls are migrated back, but it didn't help.<br>
> <br>
> I hope this makes some sense.<br>
> Is there any other info or test I can provide?<br>
> Thanks<br>
> AR<br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div>