Здраствуйте, Коллега.

Некоторое время назад я сталкивался со схожими проблемами и они так же были связаны с SIP-ом.
SIP, как сигнальный протокол еще сыроват по сравнению с его собратьями из SS7 и IN, но использовать его уже как-то можно.
Я думаю, что за этот пост меня выгонят из форума, но истина дороже.
Так вот мой Вам совет, не экспериментируйте на столь низких уровнях как транспорт, парсинг и уровень транзакций с интерпретаторами (даже если они с jit-прослойкой). Сделайте эти уровни на С или любом другом компилируемом инструменте и только transaction user (и выше) отдайте интерпретатору (какому захотите, фнкциональному или императивному). На этих уровнях интерпретаторы (эрланг в особенности) могут показать свои лучшие возможности (особенно при постороении распределнной системы повышенной надежности на основе какой-либо схеме избыточности).
Причина почему я Вам рекомендую поступить так проста. Обработка SIP трафика задача хоть и распараллеливаемая, но "сильносвязанная", т.е. части стека очень активно взаимодействуют между собой и разделять их на псевдо-процессы, обменивающиеся сообщениями — трата ценных рессурсов. Используйте на этих уровнях живые процессоры, процессы и потоки и средства их взаимодействия.
Я бы рекомендовал Вам, в качестве примера весьма эффективного SIP решения посмотреть на реализацию OpenSER (www.openser.org). Если будете смотреть, то обратие внимание на то как сделан парсинг, и как осуществляется межпроцессное взаимодействие (там есть некоторые UNIX tips).

Удачи!

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

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

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

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

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

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

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