kamailio-5.0.5 active/passive pcs/cluster with rtpengine - how to fix calls after failover
4 Jan
2018
4 Jan
'18
2:21 p.m.
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my frontend-kamailio (udp/tcp
5060, udp/tcp 5061-tls and tcp websocket-secure) i noticed the following
scenarios:
1) Plain RTP: just stocks a few seconds and flows. Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client brings audio
back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active call. I know that
there is NO way to recover this call - because of the temporay DTLS
certificate due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to do. Works nice.
For scenario2) i need something to "remember its SDES/RTP calls and send
them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls - IMHO the best
for that.
How can i fire-up these tasks to get an "clean-up" or "reinvite" after
an
failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
5 Jan
5 Jan
10:49 a.m.
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my frontend-kamailio
(udp/tcp 5060, udp/tcp 5061-tls and tcp websocket-secure) i noticed
the following scenarios:
1) Plain RTP: just stocks a few seconds and flows. Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client brings audio
back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active call. I know
that there is NO way to recover this call - because of the temporay
DTLS certificate due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to do. Works nice.
For scenario2) i need something to "remember its SDES/RTP calls and
send them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls - IMHO the
best for that.
How can i fire-up these tasks to get an "clean-up" or "reinvite"
after
an failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
11:45 a.m.
Hi Daniel,
Yes, they are.
At this point I using only one redis key space for both rtpengines. I just
fire it up on the backup machine so it reads the RTP sessions from redis.
Both rtpengines had the same configuration. Only one is active.
But I found the nice redis key space separated and active / active -
multiple rtpengine feature for it. Not implemented this at the moment.
Am 05.01.2018 8:49 vorm. schrieb "Daniel-Constantin Mierla" <
miconda(a)gmail.com>gt;:
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my frontend-kamailio (udp/tcp
5060, udp/tcp 5061-tls and tcp websocket-secure) i noticed the following
scenarios:
1) Plain RTP: just stocks a few seconds and flows. Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client brings audio
back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active call. I know
that there is NO way to recover this call - because of the temporay DTLS
certificate due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to do. Works nice.
For scenario2) i need something to "remember its SDES/RTP calls and send
them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls - IMHO the best
for that.
How can i fire-up these tasks to get an "clean-up" or "reinvite"
after an
failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
1:07 p.m.
Hello Daniel,
hello List,
for a better understanding i attached the "pcs status" and "pcs
config"
output -
to show up how things are located and colocated.
It maybe also nice for other people that try to do the same.
The Services rtpengine_service and kamailio_service running always on the
same box.
The same is for the external ip (kamailio_vip_ext) and the internal ip
(kamailio_vip_int).
[root@sipedge1 ~]# pcs status
Cluster name: viercom_sipedge_office_cluster1
Stack: corosync
Current DC: sipedge1 (version 1.1.16-12.el7_4.4-94ff4df) - partition with
quorum
Last updated: Fri Jan 5 10:59:31 2018
Last change: Fri Jan 5 10:59:28 2018 by root via cibadmin on sipedge1
2 nodes configured
4 resources configured
Online: [ sipedge1 sipedge2 ]
Full list of resources:
kamailio_vip_ext (ocf::heartbeat:IPaddr2): Started sipedge1
kamailio_vip_int (ocf::heartbeat:IPaddr2): Started sipedge1
kamailio_service (systemd:kamailio): Started sipedge1
rtpengine_service (systemd:rtpengine): Started sipedge1
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
[root@sipedge1 ~]# pcs config
Cluster Name: viercom_sipedge_office_cluster1
Corosync Nodes:
sipedge1 sipedge2
Pacemaker Nodes:
sipedge1 sipedge2
Resources:
Resource: kamailio_vip_ext (class=ocf provider=heartbeat type=IPaddr2)
Attributes: cidr_netmask=29 ip=212.XX.XX.XX nic=bond0
Operations: monitor interval=10s (kamailio_vip_ext-monitor-interval-10s)
Resource: kamailio_vip_int (class=ocf provider=heartbeat type=IPaddr2)
Attributes: cidr_netmask=24 ip=172.20.YY.YY
Operations: monitor interval=10s (kamailio_vip_int-monitor-interval-10s)
Resource: kamailio_service (class=systemd type=kamailio)
Operations: monitor interval=10s timeout=30s
(kamailio_service-monitor-interval-10s)
start interval=0 on-fail=restart timeout=30s
(kamailio_service-start-interval-0)
Resource: rtpengine_service (class=systemd type=rtpengine)
Operations: monitor interval=10s timeout=30s
(rtpengine_service-monitor-interval-10s)
start interval=0 on-fail=restart timeout=30s
(rtpengine_service-start-interval-0)
Stonith Devices:
Fencing Levels:
Location Constraints:
Resource: kamailio_service
Resource: rtpengine_service
Ordering Constraints:
start kamailio_vip_ext then start kamailio_service (kind:Mandatory)
start kamailio_vip_int then start kamailio_service (kind:Mandatory)
start kamailio_vip_int then start rtpengine_service (kind:Mandatory)
start kamailio_vip_ext then start rtpengine_service (kind:Mandatory)
Colocation Constraints:
Resource Sets:
set kamailio_vip_int kamailio_service kamailio_vip_ext kamailio_service
kamailio_vip_int rtpengine_service kamailio_vip_ext rtpengine_service
setoptions score=INFINITY
Ticket Constraints:
Alerts:
No alerts defined
Resources Defaults:
No defaults set
Operations Defaults:
No defaults set
Cluster Properties:
cluster-infrastructure: corosync
cluster-name: viercom_sipedge_office_cluster1
dc-version: 1.1.16-12.el7_4.4-94ff4df
have-watchdog: false
no-quorum-policy: ignore
stonith-enabled: false
Quorum:
Options:
--
Kind Regards
*Karsten Horsmann*
9 Jan
9 Jan
3:36 p.m.
Hello,
maybe not directly related to the issue, but could be better to separate
rtpengine on its own system, likely it requires less failover scenarios,
so active calls are not affected at all if you have to do a failover for
the signaling server...
Anyhow, as you trigger a failover and you know it is not going to
recover the active calls, you can close them via dialog module.
Cheers,
Daniel
On 05.01.18 09:45, Karsten Horsmann wrote:
Hi Daniel,
Yes, they are.
At this point I using only one redis key space for both rtpengines. I
just fire it up on the backup machine so it reads the RTP sessions
from redis.
Both rtpengines had the same configuration. Only one is active.
But I found the nice redis key space separated and active / active -
multiple rtpengine feature for it. Not implemented this at the moment.
Am 05.01.2018 8:49 vorm. schrieb "Daniel-Constantin Mierla"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my frontend-kamailio
(udp/tcp 5060, udp/tcp 5061-tls and tcp websocket-secure) i
noticed the following scenarios:
1) Plain RTP: just stocks a few seconds and flows. Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client brings
audio back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active call. I
know that there is NO way to recover this call - because of the
temporay DTLS certificate due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to do. Works nice.
For scenario2) i need something to "remember its SDES/RTP calls
and send them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls - IMHO
the best for that.
How can i fire-up these tasks to get an "clean-up" or "reinvite"
after an failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
7:56 p.m.
Hello Daniel,
yes the extra rtpengine server would also an solution but what is if that
fails. Two of them are maybe or more.
But that makes the public ip stuff more tricky.
And I found the dialog modules (there are two of them) would be also a good
idea. But brings more complexity to kamailio.cfg.
Thanks for the hints.
Am 09.01.2018 1:36 nachm. schrieb "Daniel-Constantin Mierla" <
miconda(a)gmail.com>gt;:
Hello,
maybe not directly related to the issue, but could be better to separate
rtpengine on its own system, likely it requires less failover scenarios, so
active calls are not affected at all if you have to do a failover for the
signaling server...
Anyhow, as you trigger a failover and you know it is not going to recover
the active calls, you can close them via dialog module.
Cheers,
Daniel
On 05.01.18 09:45, Karsten Horsmann wrote:
Hi Daniel,
Yes, they are.
At this point I using only one redis key space for both rtpengines. I just
fire it up on the backup machine so it reads the RTP sessions from redis.
Both rtpengines had the same configuration. Only one is active.
But I found the nice redis key space separated and active / active -
multiple rtpengine feature for it. Not implemented this at the moment.
Am 05.01.2018 8:49 vorm. schrieb "Daniel-Constantin Mierla" <
miconda(a)gmail.com>gt;:
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my frontend-kamailio (udp/tcp
5060, udp/tcp 5061-tls and tcp websocket-secure) i noticed the following
scenarios:
1) Plain RTP: just stocks a few seconds and flows. Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client brings audio
back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active call. I know
that there is NO way to recover this call - because of the temporay DTLS
certificate due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to do. Works nice.
For scenario2) i need something to "remember its SDES/RTP calls and send
them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls - IMHO the best
for that.
How can i fire-up these tasks to get an "clean-up" or "reinvite"
after an
failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
--
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
10 Jan
10 Jan
2:58 p.m.
Hello,
On 09.01.18 17:56, Karsten Horsmann wrote:
Hello Daniel,
yes the extra rtpengine server would also an solution but what is if
that fails. Two of them are maybe or more.
But that makes the public ip stuff more tricky.
And I found the dialog modules (there are two of them) would be also a
good idea. But brings more complexity to kamailio.cfg.
the ims_dialog module should
be used mainly together with the other ims
modules, otherwise is recommended to use the dialog module.
Of course if you want to add more stuff, the config gets more complex.
Tracking active calls with dialog is not something big though, just call
dlg_manage() for all requests belonging to a dialog, like INVITE,
CANCEL, ACK, BYE ... more complexity comes when you want to do active
call limits, prepaid, etc ...
Anyhow, near to zero downtime HA is not something easy no matter the
system, SIP/VoIP or not, ...
Cheers,
Daniel
Thanks for the hints.
Am 09.01.2018 1:36 nachm. schrieb "Daniel-Constantin Mierla"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
maybe not directly related to the issue, but could be better to
separate rtpengine on its own system, likely it requires less
failover scenarios, so active calls are not affected at all if you
have to do a failover for the signaling server...
Anyhow, as you trigger a failover and you know it is not going to
recover the active calls, you can close them via dialog module.
Cheers,
Daniel
On 05.01.18 09:45, Karsten Horsmann wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hi Daniel,
Yes, they are.
At this point I using only one redis key space for both
rtpengines. I just fire it up on the backup machine so it reads
the RTP sessions from redis.
Both rtpengines had the same configuration. Only one is active.
But I found the nice redis key space separated and active /
active - multiple rtpengine feature for it. Not implemented this
at the moment.
Am 05.01.2018 8:49 vorm. schrieb "Daniel-Constantin Mierla"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my
frontend-kamailio (udp/tcp 5060, udp/tcp 5061-tls and tcp
websocket-secure) i noticed the following scenarios:
1) Plain RTP: just stocks a few seconds and flows.
Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client
brings audio back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active
call. I know that there is NO way to recover this call -
because of the temporay DTLS certificate due the rtpengine
start-up.
So i thought - for scenario1) i dont need anything to do.
Works nice.
For scenario2) i need something to "remember its SDES/RTP
calls and send them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls -
IMHO the best for that.
How can i fire-up these tasks to get an "clean-up" or
"reinvite" after an failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
11 Jan
11 Jan
4:37 p.m.
Hello Daniel,
oh then there are three or more dialog modules in kamailio. I mean this
modules:
https://kamailio.org/docs/modules/5.0.x/modules/dialog_ng.html
https://kamailio.org/docs/modules/5.0.x/modules/dialog.html
and you are right - HA Setups are not simple. Like SIP - the S is also not
for simple :).
Thanks for the hint.
2018-01-10 12:58 GMT+01:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
On 09.01.18 17:56, Karsten Horsmann wrote:
Hello Daniel,
yes the extra rtpengine server would also an solution but what is if that
fails. Two of them are maybe or more.
But that makes the public ip stuff more tricky.
And I found the dialog modules (there are two of them) would be also a
good idea. But brings more complexity to kamailio.cfg.
the ims_dialog module should be used mainly together with the other ims
modules, otherwise is recommended to use the dialog module.
Of course if you want to add more stuff, the config gets more complex.
Tracking active calls with dialog is not something big though, just call
dlg_manage() for all requests belonging to a dialog, like INVITE, CANCEL,
ACK, BYE ... more complexity comes when you want to do active call limits,
prepaid, etc ...
Anyhow, near to zero downtime HA is not something easy no matter the
system, SIP/VoIP or not, ...
Cheers,
Daniel
Thanks for the hints.
Am 09.01.2018 1:36 nachm. schrieb "Daniel-Constantin Mierla" <
miconda(a)gmail.com>gt;:
--
Mit freundlichen Grüßen
*Karsten Horsmann*
Hello,
maybe not directly related to the issue, but could be better to separate
rtpengine on its own system, likely it requires less failover scenarios, so
active calls are not affected at all if you have to do a failover for the
signaling server...
Anyhow, as you trigger a failover and you know it is not going to recover
the active calls, you can close them via dialog module.
Cheers,
Daniel
On 05.01.18 09:45, Karsten Horsmann wrote:
Hi Daniel,
Yes, they are.
At this point I using only one redis key space for both rtpengines. I
just fire it up on the backup machine so it reads the RTP sessions from
redis.
Both rtpengines had the same configuration. Only one is active.
But I found the nice redis key space separated and active / active -
multiple rtpengine feature for it. Not implemented this at the moment.
Am 05.01.2018 8:49 vorm. schrieb "Daniel-Constantin Mierla" <
miconda(a)gmail.com>gt;:
--
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on a
pacemaker/corosync cluster
in front of an internal kamailio siprouter and media-services.
If i did an "pcs node standby" to failover my frontend-kamailio (udp/tcp
5060, udp/tcp 5061-tls and tcp websocket-secure) i noticed the following
scenarios:
1) Plain RTP: just stocks a few seconds and flows. Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my client brings audio
back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an active call. I know
that there is NO way to recover this call - because of the temporay DTLS
certificate due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to do. Works nice.
For scenario2) i need something to "remember its SDES/RTP calls and send
them an REINVITE"
And for scenario3) i should just hangup all WebRTC calls - IMHO the best
for that.
How can i fire-up these tasks to get an "clean-up" or "reinvite"
after
an failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
--
Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
5:08 p.m.
Hello,
On 11.01.18 14:37, Karsten Horsmann wrote:
Hello Daniel,
oh then there are three or more dialog modules in kamailio. I mean
this modules:
https://kamailio.org/docs/modules/5.0.x/modules/dialog_ng.html
https://kamailio.org/docs/modules/5.0.x/modules/dialog.html
dialog_ng was renamed to ims_dialog few major releases ago. The html
file was likely propagated by the copy of the folder, but it should not
be listed in the index page. I will remove the file anyhow.
Cheers,
Daniel
and you are right - HA Setups are not simple. Like SIP - the S is also
not for simple :).
Thanks for the hint.
2018-01-10 12:58 GMT+01:00 Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>:
Hello,
On 09.01.18 17:56, Karsten Horsmann wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hello Daniel,
yes the extra rtpengine server would also an solution but what is
if that fails. Two of them are maybe or more.
But that makes the public ip stuff more tricky.
And I found the dialog modules (there are two of them) would be
also a good idea. But brings more complexity to kamailio.cfg.
the
ims_dialog module should be used mainly together with the
other ims modules, otherwise is recommended to use the dialog module.
Of course if you want to add more stuff, the config gets more
complex. Tracking active calls with dialog is not something big
though, just call dlg_manage() for all requests belonging to a
dialog, like INVITE, CANCEL, ACK, BYE ... more complexity comes
when you want to do active call limits, prepaid, etc ...
Anyhow, near to zero downtime HA is not something easy no matter
the system, SIP/VoIP or not, ...
Cheers,
Daniel
Thanks for the hints.
Am 09.01.2018 1:36 nachm. schrieb "Daniel-Constantin Mierla"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
maybe not directly related to the issue, but could be better
to separate rtpengine on its own system, likely it requires
less failover scenarios, so active calls are not affected at
all if you have to do a failover for the signaling server...
Anyhow, as you trigger a failover and you know it is not
going to recover the active calls, you can close them via
dialog module.
Cheers,
Daniel
On 05.01.18 09:45, Karsten Horsmann wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
--
Mit freundlichen Grüßen
*Karsten Horsmann* Hi Daniel,
Yes, they are.
At this point I using only one redis key space for both
rtpengines. I just fire it up on the backup machine so it
reads the RTP sessions from redis.
Both rtpengines had the same configuration. Only one is active.
But I found the nice redis key space separated and active /
active - multiple rtpengine feature for it. Not implemented
this at the moment.
Am 05.01.2018 8:49 vorm. schrieb "Daniel-Constantin Mierla"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
are kamailio and rtpenigine on same system?
Cheers,
Daniel
On 04.01.18 12:21, Karsten Horsmann wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
<http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
Hello List,
and also an happy new year to everyone.
I use CentOS 7.4.x with kamailio 5.0.5 and rtpengine on
a pacemaker/corosync cluster
in front of an internal kamailio siprouter and
media-services.
If i did an "pcs node standby" to failover my
frontend-kamailio (udp/tcp 5060, udp/tcp 5061-tls and
tcp websocket-secure) i noticed the following scenarios:
1) Plain RTP: just stocks a few seconds and flows.
Everything fine.
2) SDES/RTP: silence - but REINVITE manually in my
client brings audio back. Need improvement.
3) DTLS/RTP WebRTC: silence - all clients shows an
active call. I know that there is NO way to recover
this call - because of the temporay DTLS certificate
due the rtpengine start-up.
So i thought - for scenario1) i dont need anything to
do. Works nice.
For scenario2) i need something to "remember its
SDES/RTP calls and send them an REINVITE"
And for scenario3) i should just hangup all WebRTC
calls - IMHO the best for that.
How can i fire-up these tasks to get an "clean-up" or
"reinvite" after an failover?
scenario legend:
1) unencrypted call
2) TLS/SDES encrypted call
3) DTÖS WebRTC encrypted call
--
Kind Regards
*Karsten Horsmann*
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda
<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - www.asipto.com <http://www.asipto.com>
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
<http://www.kamailioworld.com>
2507
days inactive
2514
days old
8 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Karsten Horsmann