Re: [OpenSIPS-Users] re-homing calls
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.124192.168.56.120
──┬─ ──┬─
14:24:55.900819 │INVITE (SDP) │
+0.000562 │ ──> │
14:24:55.901381 │ 100 Giving it a try │
+0.00 │ <── │
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 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, w
Re: [OpenSIPS-Users] re-homing calls
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/
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 o
[OpenSIPS-Users] re-homing calls
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
