kamailio-5.0.5 active/passive pcs/cluster with rtpengine - how to fix calls after failover
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
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:
- Plain RTP: just stocks a few seconds and flows. Everything fine.
- 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:
- unencrypted call
- TLS/SDES encrypted call
- DTÖS WebRTC encrypted call
-- Kind Regards *Karsten Horsmann*
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.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:
- Plain RTP: just stocks a few seconds and flows. Everything fine.
- 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:
- unencrypted call
- TLS/SDES encrypted call
- 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
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:
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@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: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@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>
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@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:
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@gmail.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:
- Plain RTP: just stocks a few seconds and flows. Everything fine.
- 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:
- unencrypted call
- TLS/SDES encrypted call
- 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
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@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: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@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: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@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>-- 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 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@gmail.com:
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@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:
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@gmail.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:
- Plain RTP: just stocks a few seconds and flows. Everything fine.
- 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:
- unencrypted call
- TLS/SDES encrypted call
- 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
-- 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,
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@gmail.com mailto:miconda@gmail.com>:
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, DanielThanks for the hints. Am 09.01.2018 1:36 nachm. schrieb "Daniel-Constantin Mierla" <miconda@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: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@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: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@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>-- 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>-- 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*
-
Daniel-Constantin Mierla -
Karsten Horsmann