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 <[email protected] > <mailto:[email protected]>>: > > 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" >> <[email protected] <mailto:[email protected]>>: >> >> 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" >>> <[email protected] <mailto:[email protected]>>: >>> >>> 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 >>>> [email protected] >>>> <mailto:[email protected]> >>>> 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 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
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
