[Voicemaster]

2Voicemaster:

 

Может надо завести проектик, вики там, начать roadlist писать...может они есть уже?

 

Тем более, что под это дело у большей части местных участников, afaik, найдутся as-ки, платформы, прочие ресурсы, оборудование, желание, судя по комментам.

 

На чем дело-то встало, собствено?

 

Частично есть. Да, планировал завести небольшой блог + форум, чтобы это начать описывать.

 

 

А дело пока встало за следующим:

 

Не вопрос: это будет бесплатный базовый сервис системы.

 

Вопрос: это надо кому-нибудь вообще ? ;-)

 

 

Вот эти соображения и хотелось бы услышать.

 

На этот вопрос: "это надо кому-нибудь вообще ?" пока у меня ответа нет.

 

Но делать похоже надо при любых раскладах.

 

.

 

 

[leveler]

Давай уже делать. А там разберёмся, надо или нет. ;)

[Voicemaster]

Давай уже делать. А там разберёмся, надо или нет. ;)

"Путь в тысячу ли начинается с одного шага" - (с) Лао Дзэ

 

Уже начал. К началу следующей недели, наверно, что-то уже выложу в сеть. Пока самый больной вопрос - время.

 

.

 

[Monstreek]

а вы уже определились что делать то? :)

[Voicemaster]

а вы уже определились что делать то? :)

 

Да. Большой географически распределённый SoftSwitch с тяготением к IMS архитектуре.

 

.

 

[McUrex]

Да. Большой географически распределённый SoftSwitch с тяготением к IMS архитектуре.

JFYI!

А почему столь монопольное отношение к подобному проекту, если не секрет?

Почему бы не собраться за чашечкой (пиво, кофе, чаю, водки - нужное подчеркнуть) и обсудить с такими же $voicemasters[] про это, в целом не определиться со списком заинтересованых участников?

Во-первых, можно было бы говорить о бОльшем в рамках проекта.

Во-вторых, резонно предположить, что больше рук будет обеспечивать некоторые показатели эффективности возможного проекта, такие как срочность тех или иных работ, направленость действий в целом?

Чего одному лямку то тянуть, смысл?

 

 

[McUrex]

На этот вопрос: "это надо кому-нибудь вообще ?" пока у меня ответа нет.

Думаю на этот вопрос можно будет ответить после первого теста подобной системы, не раньше.

 

[Voicemaster]

Да. Большой географически распределённый SoftSwitch с тяготением к IMS архитектуре.

JFYI!

А почему столь монопольное отношение к подобному проекту, если не секрет?

В первую очередь я бы хотел искренне очень извиниться, если кто-либо увидел горделивое "Я" и/или ЧСВ в моих постах.

 

Монопольное... ну, конечно же, нет. Любое взаимодействие в виде идей, обсуждения, критики, кода, ресурсов разумеется только welcome, но очень не хотелось бы остановиться на "говорильне".

 

С другой стороны надо понимать, что мы собираемся строить, т.к. проектировать и делать сервис на 1-10M users не самая технически простая задача.

 

Почему бы не собраться за чашечкой (пиво, кофе, чаю, водки - нужное подчеркнуть) и обсудить с такими же $voicemasters[] про это, в целом не определиться со списком заинтересованых участников?

Буду только рад ! Территориально сейчас в Москве, центр, время после 20:00.

 

Во-первых, можно было бы говорить о бОльшем в рамках проекта.

Да, идей очень много.

 

Во-вторых, резонно предположить, что больше рук будет обеспечивать некоторые показатели эффективности возможного проекта, такие как срочность тех или иных работ, направленость действий в целом?

Да, полностью согласен. Работы очень много и очень разной.

 

 

Чего одному лямку то тянуть, смысл?

* глубокий вздох...

 

Резонно. Всех geek'ов приглашаю на пиво. Будет много кода и драйва. $ будет мало.. или много, но сильно потом ;-)

 

.

Изменено 9 июля, 2009 пользователем Voicemaster

[leveler]

Как успехи?

[nag-f]

Это все круто, только не ясно, как люди с аналогового телефона будут звонить 434775993@domain.ru.

Мне видится создание единой системы (свободной) регистрации своих SIP_ID@domain.ru к идентификатору системы, которые в свою очередь могут управляться (маршрутизироваться в нужную стороны) на анологии dns, только проприетарной для этой системы.

[...]

С "аналогового" телефона (ATA) пользователи будут просто набирать *434775993, где * будет означать требование запроса в ENUM (хотя это тоже всё опционально и обсуждаемо).

 

Аналогия с DNS тут весьма уместна (DNS based). С "проприетарной" системой - категорически нет. База данных должна быть полностью открытой к использованию для всех.

 

Решается этот вопрос созданием сервиса ENUM, который позволяет "резолвить" E.164 телефонный номер в SIP URI. Например :

 

tel: +7 900 000 00 01 => sip:user1@domain1.ru

tel: +7 495 000 00 01 => sip:user1@domain1.ru

tel: +7 900 000 00 02 => sip:user2@domain2.ru

tel: +7 900 000 00 03 => sip:user3@domain3.ru

 

Технически - это записи в DNS зоне вида:

 

$ORIGIN 1.0.0.0.0.0.0.9.7.enum.domain.tld
IN NAPTR 100 10 "u" "E2U+sip"  "!^.*$!sip:user1@domain1.ru
IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:user1@domain1.ru

 

 

Таким образом может осуществляться бесшовная интеграция классической телефонной сети с адресацией E.164 и SIP сети.

 

Подробнее можно почитать на:

 

http://ru.wikipedia.org/wiki/ENUM

http://en.wikipedia.org/wiki/Telephone_number_mapping

http://www.itu.int/osg/spu/enum/

http://www.ietf.org/html.charters/enum-charter.html

 

 

Ключевая возможность - возможность "прямого" (без зоны/мг/мн) вызова из домена в домен. Фактически - это снос иерархической телефонной структуры и появление сети full mesh поверх IP, сиречь радикальное снижение стоимости коммуникаций и их отличная гибкость.

 

 

Пользоваться таким сервисом должны иметь возможность все, начиная от DNS запросов и заканчивая транферами зоны и её частичное делегирование операторам.

 

 

Разумеется, конструктив, критика и предложения очень приветствуются.

 

.

Для построения таких сервисов наиболее целесообразно использовать принципы распределенных систем. В частности одними из примеров таких таких систем можно рассматривать протокол DHT в bitTorrent, распределенная система контроля версий git, да в конце концов закрытый протокол Skype.

 

Ведь если вдуматься в специфику работы торрента. Какая разница, что передставляет собой передаваемая информация, кусочки файлов или звуковую информацию. В этом направлении уже давно работают, как коммерческие компании так и коллективы энтузиастов... есть достаточно неплохие результаты. Однако существующие протоколы сигнализации (SIP, H.323), существующие алгоритмя кодирования звука, транспортные протоколы RTP... не пригодны для построения таких распределенных систем и ориентированы на сети с гарантированной доставкой данных или поддержкой QoS, что неприемлимо при построении массовых распределенных сервисов, тем более в тех масштабах о которых идет речь. Если говорить о сопряжении с оборудованием телекоммуникационных компаний в точке демаркации - то там наиболее целесообразно устанавливать конвертеры протоколов. Собственно один из таких, хотя и неудачных примеров, является конвертер H.323-SIP когда то разработанных для меры.

Изменено 27 июля, 2009 пользователем nag-f

[ram_scan]

Ведь если вдуматься в специфику работы торрента. Какая разница, что передставляет собой передаваемая информация, кусочки файлов или звуковую информацию. В этом направлении уже давно работают, как коммерческие компании так и коллективы энтузиастов... Собственно существующие протоколы сигнализации (SIP, H.323), существующие алгоритмя кодирования... не пригодня для построения таких распределенных систем.

Собственно вполне очевидно почему. Если в торренте мне вобщем-то изофаллично, за два часа ко мне файл приедет, или за три, в какой последовательности он из кусков соберется, и отвалился ли какой-то сидер, то для реалтайм трафика такой фокус не проходит. Даже если очень хочется.

 

Скайп в этом смысле тоже кстати мимо тазика, потому-как система централизованная. И супернодой клиент становится по команде с сервера. Вообще внутри оно SIP за мелкими исключениями.

[nag-f]

Собственно вполне очевидно почему. Если в торренте мне вобщем-то изофаллично, за два часа ко мне файл приедет, или за три, в какой последовательности он из кусков соберется, и отвалился ли какой-то сидер, то для реалтайм трафика такой фокус не проходит. Даже если очень хочется.

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

 

Скайп в этом смысле тоже кстати мимо тазика, потому-как система централизованная. И супернодой клиент становится по команде с сервера. Вообще внутри оно SIP за мелкими исключениями.

Skype - это типичный пример такой распределенной системы. Да, задача авторизации, и назначения супер нодов выполняется централизованно.

Изменено 27 июля, 2009 пользователем nag-f

[GHhost]

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

[ram_scan]

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

Как отсутствует ? Bandwidth там вполне себе присутствует. А на h323 пирах например оставшаяся и требуемая полоса анонсируется в ARQ/RRQ, поэтому собсно нет больших проблем сделать хантинг на набиолее вкусное с точки зрения качества направление.

[GHhost]

я не про bandwidth, тот же rtcp коим средства получения показателей не ограничиваются не на всех пирах присутствует в реальной жизни даже на межоператорском рынке, если делать чтото новое и масштабное то целесообразно подумать бы об этом тоже, про h323 я так понял тут никто не думает вообще, а зря на мой взгляд.

[nag-f]

я не про bandwidth, тот же rtcp коим средства получения показателей не ограничиваются не на всех пирах присутствует в реальной жизни даже на межоператорском рынке, если делать чтото новое и масштабное то целесообразно подумать бы об этом тоже, про h323 я так понял тут никто не думает вообще, а зря на мой взгляд.

Честно говоря, в своей жизни с более сложным протоколом чем H.323 я еще не встречался. Не зря CISCO в своей поддержке этого протокола останвилась помоему на 2-й. H.323 - по сути являлся переходным протоколом сигнализации и фактически на ранних этапах был спроектирован как расширение SS7 (Q.931). Дальше началось самое интересное, вставала необходимость в добавлении того либо иного функционала... и понеслось.... 1,2,3,4,5,6... версия. Довелось достаточно долго и плотно работать с этим протоколом. Вот недавно вводил поддержку 6-й версии... Хочется выразится резко, скажу мягче, этот протокол разрабатывали не инженеры, а лататели дыр. Будущего у этого протокола сигнализации абсолютно никакого, SIP - это протокол настоящего, ну а в будущем, как я уже говорил будут доминировать распределенные, децентрализованные системы, разработки которых активно ведутся во всем мире в том числе и на просторах СНГ.

 

Как мне видятся подобные проекты. Небольшие операторы IP-телефонии собираются. Обсуждают проблемы. И выдвигают новый независимый открытый! стандарт, под него ведется разработка надежных, отлаженных OpenSource решений, далее все этого стандарта придерживаются. В будущем распространенность такого стандарта сделает его дешевым и массовым, крупным телекомам некуда будет деваться и прийдется переходить на этот стандарт. Идти от обратного, от телекома, PSTN сети - нонсенс, иначе получим H.323v7... :)

 

 

Изменено 27 июля, 2009 пользователем nag-f

[GHhost]

У сипа тоже костылей хватает, h323 разрабатывался скорее как isdn поверх ip а не расширение SS7 который вообще то еще оди стек протоколов сигнализации, и сип на транзите иногда выглядит весьма плохо, это вобщем то уже холивар, всему свое место, меня как оператора больше беспокоит таки качество, если ктото гдето начал терять пакеты на какомто направлении то хочется рубануть это направление через 5 секунд а не через полдня когда ктонить это заметит.

[nag-f]

У сипа тоже костылей хватает, h323 разрабатывался скорее как isdn поверх ip а не расширение SS7 который вообще то еще оди стек протоколов сигнализации, и сип на транзите иногда выглядит весьма плохо, это вобщем то уже холивар, всему свое место, меня как оператора больше беспокоит таки качество, если ктото гдето начал терять пакеты на какомто направлении то хочется рубануть это направление через 5 секунд а не через полдня когда ктонить это заметит.

Существую такие Softswitch класс 4 (h.323/SIP), с модулями динамической маршрутизации, в том числе и на основе состояния канала, ACD, ASR....

Изменено 27 июля, 2009 пользователем nag-f

[GHhost]

существуют, вы их покупать будите для реализации это идеи? на 100K абонентов? думаю про "скинуца" можно сразу тогда забыть, а вот о контроле этих же праметров сразу на уровне сети подумать можно, ACD, ASR это из тех параметров которые гарантированно работают в любой ситуации не зависимо ни от протоклов ни от реализаций, но из на мой взгляд таки маловато для полной картины, в ашке кстати есть H.460.9 что на мой взгляд более правильное решение, чтото подобное можно ввести и в сип на данном проeкте.

[GHhost]

кстати крупные телекому в некоторых странах в том числе и в снг ведут разработки в сторону как бы прикрыть к примеру скайп:) поетому двигать телекомы протоколами и обьемами может быть трудновато иногда.

[nag-f]

существуют, вы их покупать будите для реализации это идеи? на 100K абонентов? думаю про "скинуца" можно сразу тогда забыть, а вот о контроле этих же праметров сразу на уровне сети подумать можно, ACD, ASR это из тех параметров которые гарантированно работают в любой ситуации не зависимо ни от протоклов ни от реализаций, но из на мой взгляд таки маловато для полной картины, в ашке кстати есть H.460.9 что на мой взгляд более правильное решение, чтото подобное можно ввести и в сип на данном проeкте.

У вас есть практика программирования или вы просто администрируете готовые системы? Вы можете назвать мне хотя бы одну OpenSource библиотеку H.323 которая проходит самый приитивный стресс тест? OpenH323 "сыпется" из 4000 тестов на 127-м! О каком промышленном использовании таких открытых-бесплатных продуктов может идти речь? О какой поддержке H.460.9 идет речь за бесплатно да и вобще, кто реализовал его функционал в хотя бы примитивном объеме?!!!!

Вы поймите - либо нужно разрабатывать единый! открытый! абсолютно новый! стандарт, либо платить приличные средства за приличное программное обеспечение. Доделывать SIP чем то непонятным, так получите через два три года ту же ситуацию что и H.323.... Когда каждый разработчик интерпритирует стандарт по своему в итоге полностью совметимого оборудования или программного обеспечения практически не существует... это нонсенс!!!

Изменено 27 июля, 2009 пользователем nag-f

[GHhost]

У вас есть практика программирования или вы просто администрируете готовые системы?

 

и то и другое.

 

Вы можете назвать мне хотя бы одну OpenSource библиотеку H.323 которая проходит самый приитивный стресс тест?

OpenH323 "сыпется" из 4000 тестов на 127-м!

О каком промышленном использовании таких открытых-бесплатных продуктов может идти речь?

 

на каких тысячах тестов вы это делали? дайте ссылку я попробую.

 

О какой поддержке H.460.9 идет речь за бесплатно да и вобще, кто реализовал его функционал в хотя бы примитивном объеме?!!!!

 

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

 

Вы поймите - либо нужно разрабатывать единый! открытый! абсолютно новый! стандарт, либо платить приличные средства за приличное программное обеспечение. Доделывать SIP чем то непонятным, так получите через два три года ту же ситуацию что и H.323.... Когда каждый разработчик интерпритирует стандарт по своему в итоге полностью совметимого оборудования или программного обеспечения практически не существует... это нонсенс!!!

 

а сейчас мы имеем мало того что каждый протокол хренова совместим между собой так еще и кучу разных протоколов, sip sipt sigtran mgcp h323 +куча проприетарных, еще 1 хотите? плюс отсутствие какой либо нормальной динамической маршрутизации для телефонии как класса. зачем мы сейчас об этом тут говорим? чтоп выяснить какой протокол круче чтоли?

 

P.S. чет я так и не понял почему у меня квотинг не работает

[nag-f]

а сейчас мы имеем мало того что каждый протокол хренова совместим между собой так еще и кучу разных протоколов, sip sipt sigtran mgcp h323 +куча проприетарных, еще 1 хотите? плюс отсутствие какой либо нормальной динамической маршрутизации для телефонии как класса. зачем мы сейчас об этом тут говорим? чтоп выяснить какой протокол круче чтоли?

Суть такова, что современные протоколы сигнализации, транспортные протоколы, алгоритмы кодирования, принципы маршрутизации - морально устарели и не позволяют организовать массовые сервисы, того класса, которые обсуждаются в теме. С появлением skype - стало ясно, что будущее за такими сервисами. Skype опирается на принципы построения распределенных систем. Для этого предложен распределенный протокол сигнализации, транспортный протокол, кодек допускающий определенных % потери информации при доставке данных.. Популярность такого сервиса доказала правильность выбора концепции. Однако такой протокол закрыт. Логично было бы разработать открытый-стандарт такого распределенного протокола, транспортных прооколов, кодеков... и позволить небольшим операторам строить такие сети. Тогда есть шанс реализовать предложенную автором идею. Делать это на базе технологий SIP/H.323/RTP/RTCP/Ulaw/Alaw/G.723/G.729, да еще на базе сырых OpenSource решений - это притягивание мертвого за уши.

Изменено 27 июля, 2009 пользователем nag-f

[GHhost]

честно сказать обосраца, у скайпа с маршрутизацией между операторами сильно лучше чтоли?:) максимум как ево можно рассматривать это как транспорт.

[nag-f]

честно сказать обосраца, у скайпа с маршрутизацией между операторами сильно лучше чтоли?:) максимум как ево можно рассматривать это как транспорт.

Никто не запрещает предложить и разработать, что то лучше. Как я уже говорил ведутся такие разработки и исследования в области перспективных технологий передачи мультимедийных данных.

Изменено 27 июля, 2009 пользователем nag-f