Здравствуйте, netch80, Вы писали:
N>Hi,
N>рассматривал ли кто применимость Erlang для реализации VoIP softswitch (для определённости — на SIP)? Интересует не принципиальная применимость, а качественные оценки адекватности подходов. YXA видел, речь не о ней (а о слое выше — диалоги, сессии).
Ну, вроде как Эриксон рассматривал, нет? Разве у AXD301 нет функциональности VoIP softswitch?
.
Вот что пишет Ульф Вигер:
http://www.erlang.org/pipermail/erlang-questions/2003-February/007383.html
Check out the AXD 301 telephony-over-packet media gateway.
I'm sure it fits the profile pretty well. Its control system
is mostly written in Erlang, and it uses e.g. OTP's H.248.
http://www.ericsson.com/about/publications/contact/pdf/c19_02/14.pdf
http://www.erlang.se/publications/Ulf_Wiger.pdf
The Erlang/OTP platform is by far the best middleware you
can find for this kind of thing. I've not seen anything that
event comes close.
/Uffe
On Thu, 13 Feb 2003, Farzin_B23 SOORI wrote:
>Dear Per;
>I am new to erlang.But i have some good experience in VoIP
>deployment;Specially i work in carrier grade level like as
>transmission the voice and signaling traffic of a high density
>telecomm switch on a IP based platform.Now i am in the selection
>phase of a real time and distributed platform to deploy my Megaco based VoIP
>system on top of it...
>So i want to ask you as a profession that , how much the erlang
>platform is hopefull for my goal? Is it scalable enough to develope
>a carrier grade system like the one i mentioned?why?
>Can you tell me some large scale and carrier grade applications
>developed with erlang so far?
>Which guys in ericsson are the most profession in erlang?
>thank you
>sincerely
>Soori
N>Из того что получилось в нашем исследовании — например, прохождение всей сигнализации через один сокет (для наиболее типичного случая — UDP) и необходимость держания базы текущих диалогов является серьёзным препятствием расщеплению на слабозависимые параллельные процессы. Уровень диалога и уровень сессии очень сильно связаны, и при том что у них разные FSM — строить их в разных процессах становится весьма накладно, поэтому надо изобретать multi-FSM аналог gen_server. Достаточно много междиалогового взаимодействия (transfer, parking...), связей с внешними источниками (биллинг, RTP прокси), автоматы получаются понятными, но громоздкими. Очень желательным была замена кода на ходу, но тотальная замена работающим процессам сомнительна (иногда перестройка логики идёт очень радикальная).
Не могу сказать — я не в теме задачи. Однако, распараллелить можно что угодно
. Мы полгода назад параллелили сервер обработки котировок в познавательных целях — так там тоже сначала казалось, что масштабируемую систему сделать нельзя. Потом получилось просто и красиво.
N>Вот по всему сказанному я в раздумьях — не пропустил ли я какой-то глобальной полезности Erlang+OTP по сравнению с текущей реализацией? Руководящие и направляющие материалы прочитаны и местами законспектированы, включая главный диссер и доку с сайта, радости они не принесли Легко рассказывать про тривиально параллелящиеся случаи (как у Джо пример провайдерского POP3 прокси), но вполне себе телекомовская задача у меня — уже смущает.
Я, честно говоря, не понимаю, как Питоновское решение в такой задаче может быть проще и иметь хоть какие-то преимущества перед Эрлангом — он здесь по всем пунктам рлангу проигрывает.
1) Erlang/OTP должен лучше работать при пиковой нагрузке, он быстрее, и у него рилтаймовое время отклика.
2) На Elrang/OTP существенно, на порядок проще сделать отказустойчивое приложение.
3) Конечные автоматы на Эрланге записываются радикально проще и декларативнее, чем на Питоне, благодаря паттерн-матчингу и атомам.
4) Язык проще питона, изучается самым обыкновенным программистом за ОДНУ неделю.
