<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Wow, this has turned into quite a debate.<br>
<br>
I think HA could be the killer app that catapults FS into the<br>
mainstream. Even if not full implemented today, laying the groundwork<br>
to allow for call state synchronization with a standby box would be a<br>
great leap ahead of any other platform I'm aware of.<br>
<br>
Although not fully analogous, if you want to see an example of state<br>
mirroring look at Cisco SNAT. This synchronizes NAT entries to a<br>
standby router so that IP conversations are not reset when switchover<br>
occurs.<br>
<br>
Imagine running just two boxes and having a fully redundant and<br>
mirrored configuration where when the primary box fails, the caller<br>
hears only a momentary 'hiccup' then conversation continues on....<br>
<br>
Tom</blockquote><div><br>AFAIK all commercial B2BUA/Proxy/SBCs all have the ability to share/exchange session/call states in real-time such that where implemented as active/passive configuration, current states are viewable on the passive member machine, although only few have the ability to influence and/or Mod/Add/Chg these sessions from the passive member. These states are usually maintained in a DB which in some cases is RAMDISK resident. In our proprietary solution, we have a web-based GUI to manage the 'cluster' where a change made in any one member (we allow 4 total members, where 1 is a master and 3 backups (Geographically remote, if needed)) propagates the changes in the DBs of all members including that of the active/master. Hence real-time control and modifications are possible. We do this over a proprietary but very simple TCP based protocol where this information is exchanged beteween the members. <br>
<br>Other solutions out there e.g. Nextone uses the technique as was mentioned earlier in one of the posts, where a Virtual IP is configured for every interface as a virtual/logical interface which is what is configured in all UAs/Clients to connect to. A dedicated network port for a heartbeat type mechanism tells the other members if they're 'still there'. If not, rapid failover occurs where theVirtual IP is transferred to the passive member via a gratuitous ARP to the upstream switch (for people worried about the switch being a point of failure, we have configured ours with EtherChannel or Trunking so as to allow tables to be shared by both switches) upon which all requests are now sent to the new Master. Mind you, all of this happens within msecs and although it's never happened in a Live scenario, during testing, none of the calls were dropped when the switch/failover occurred other than a brief period of silence (enough for someone to say 'hello?') and boom the call's back on.<br>
<br>I know nothing about the architecture of FS or I'd be able to make more qualified comments but clearly it's not an impossible task or 'a first' but seeing the limited number of developers working on FS, it might be a little while before it happens here, but I have no clue what the current state is even. I'm sure with people like Anthony's calibre around, it might not be that big a deal :)<br>
<br>Cheers,<br>\RR</div></div></div>