Здравствуйте, Mamut, Вы писали:

N>>Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны,

M>Сессия — supervisor, диалог(диалоги?) — его дочерние процессы.
M>Более того, так как сессий может быть много, то над сессиями ставится еще один супервайзер.
M>Наврное, так, я просто специфики VoIP не знаю

Точно не знаете. Сессия SIP — это взаимодействие сторон с обменом SDP в пределах диалога. Сессия относится к диалогу как 1:1, если диалог сессионный (есть ещё диалоги подписки и есть смешанные), но схема состояний у них разная (достаточно, например, различия между early и late offer model — синхронизация состояний сдвинута у одного на шаг относительно другого). Супервизор тут никоим боком не годится (разве что делать из процесса диалога супервизор на один дочерний процесс — сессионный — но это получается дикий изврат).

N>>и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими.
M>Для большинства этих связей скорее всего можно обойтись простым receive.

Да понятно, что оно будет receive — других примитивов приёма от других процессов/узлов вроде нет:)