O FSV-4PFS 4 Port T1/E1 FailSafe Device конечно же.

в смысле при использовании FSV-4PFS 4 Port T1/E1 FailSafe Device придётся покупать платы от дигиум на 4E1 2шт.

На "сегодняшний день", и на "завтрашний" тоже - сомнения излишни. Изучайте принципы работы сетевых протоколов и АТС!

спасибо, засчитано.

интересно, что вы скажете, внимательно прочитав это:
http://www.cs.columbia.edu/techreports/cucs-011-04.pdf

Что конкретно в этом документе?

а вот как ЭТО сделано у IBM:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/csip_sessionfail.html

ну какбэ это очевидно
но сессии вы все равно потеряете, хотя разговор может и не прерваться.

вообще было бы заманчиво добавить в астериск механизм реалтайм репликации состояния. вот это бы позволило реализовать "горячее" резервирование. аналогичный подход релизован в мере на двух уровнях: на каждой машине запущено по два процесса, один из которых активный, а другой - точно такой же (включая состояние всех переменных и тд). при сбое первого он нещадно убивается и все на лету переходит на второй. такой же алгоритм реализован при работе двух физических серверов

потеря сессии означает потерю разговора - разве не так?
идея в том, чтобы не происходило потери сессии при потере физического сервера.

вот кстате вариант с OpenSER (который, как я понимаю, умеет делать репликацию состояния)
www.unc.edu/~cschlatt/docs/SIP_failover_and_redundancy.pdf

Репликация состояния? Достаточно реплицировать информацию о Contact. Астериск ее хранить в AstDb. Ее можно держать на DRBD узле, и при падении основного сервера резервный мгновенно перехватывает IP, подымает Asterisk на актуальной AstDb.
В ситуации сбоя основного сервера звонки рвутся, но юзеры тут же перезванивают, и Asterisk знает, где кто зарегистрирован (с какого ip и порта).
Описанное выше в астериске не делал, делал на FS. Работает отлично.