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