[OpenSIPS-Users] re-homing calls
Alberto
alberto.rinaudo at gmail.com
Tue Jun 11 14:40:05 UTC 2024
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 <razvan at 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 at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240611/1504205c/attachment-0001.html>
More information about the Users
mailing list