mirror of https://github.com/sipwise/rtpengine.git
Thoughts on that topic so far: There's one thing to keep also in mind. What do we do if the call changes (streams) and the backup node is notified ? Currently we only know (by subscribing to the 'notifier-' prefix that in fact it has changed, but we don't know what has changed in detail. Subscribing to everything would lead to the problem that we have to take care about synchronising the the new streams with the old ones. Without having a look at the code that might be a lot of effort and ... I guess that's why richard likes to ... have clean states of the calls. Synchronizing is always a mess. Easier to delete and setup new. I thought about the following solution for makes things more abstract and easier to understand: 1. Whenever that call on a backup node (foreign call) has seen a packet (also timers are started then), we do not process any notification by a redis notification for this call (caus' the RTP-IP has already been switched). More precise and abstract that means: If a node has taken over the responsibility for that call (by having seen a packet), it assumes that notifications from the former node to be dropped. The call will be deleted when either the timer fires or (for other companies) the control channel address has also been switched and via that channel the call is deleted. 2. If a call has not seen a packet (inactive call on the backup node, seen as not responsible for that call but could become so), we accept all commands for that call on the backup node in the same way as on the original node. That means also deletions in-between and so on. I mean if the original node does it, why not accepting to do the same way on the backup node ?pull/225/head
parent
bf38f151ba
commit
fd3e2342c1
Loading…
Reference in new issue