9 Jan
2018
9 Jan
'18
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