[SR-Users] kamailio-5.0.5 active/passive pcs/cluster with rtpengine - how to fix calls after failover

Daniel-Constantin Mierla miconda at gmail.com
Wed Jan 10 12:58:50 CET 2018


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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto:miconda at 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 at lists.kamailio.org <mailto:sr-users at 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 -- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180110/f0ae59ce/attachment.html>


More information about the sr-users mailing list