[GHhost]

да я уже понял, надоело вобщем, то вы h323 от ss7 не отличаете, то у вас скайп маршрутизируется между операторами хорошо очень, то все открытые решения сырые на фоне того что фрисвичем к примеру еще в 2008 году у когото из кэрриеров sbc проприетарный кстати завалили, то странные вопросы задаете и путаете собственно маршрутизацию и транспорт, то говорите о ASR/ACD как качественные показатели хотя они косвенные, то какието 4000 тестов, я с 2000 года гдето занимаюсь войпом и примерно с того времени юзаю openh323 стек но ниразу не слышал о этих тестах, я уже даже не представляю чего в следующий рас от вас ожидать

[leveler]

Кстати. Вот такой вопрос. У нас есть абонбаза в ~300 номеров. Есть софтсвич H.323 (MVTS). Есть небольшое количество звонков. Опишите мне качественный алгоритм (или дайте ссылку), как мне с помощью анализа ASR/ACD выбирать текущего оператора?

 

При моём небольшом количестве звонков отследить качество конкретного направления (город-оператор) крайне тяжело. Кроме того, у вас ASR при звонке с кодом 17 улучшается или не изменяется (традиционный ли подсчёт ASR)?

 

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

[Mikler]

я не про 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... :)

1. H.323 - точно описан, у него мало граблей на которые можно наступать, и которые явно не описаны.

2. Он свободно проходит NAT потому, что мозг правильно работал когда его создовали.

3. Хорошо работает для конференций видео телефонии.

4. Понятное разделение сигнализационных каналов.

 

То что лежит в открытом доступе требует приложение головы и прямых рук и тогда оно будет работать как часы, OpenH323 это стек в который жостко встроины кодеки. Это не эталон надежности скажем так :)

PS:

SIP терминалы это к сожалению будущее :) IMS практичес ки у всех на нем.

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

[nag-f]

да я уже понял, надоело вобщем, то вы h323 от ss7 не отличаете,

Прошу не дополнять мои сообщения своими домыслами. Если что то не понятно или я не удачно высказался - уточните.

Поинтересуйтесь что общего у SS7 и семейства протоколов q.921,q.931

 

то у вас скайп маршрутизируется между операторами хорошо очень, то все открытые решения сырые на фоне того что фрисвичем к примеру еще в 2008 году у когото из кэрриеров sbc проприетарный кстати завалили, то странные вопросы задаете и путаете собственно маршрутизацию и транспорт, то говорите о ASR/ACD как качественные показатели хотя они косвенные

Покажите где яписал об этом. Я просто привел пример удачно-разработанной распределенной системы VoIP. И просто скромно заметил, что в мире ведутся разработки над подобными открытыми стандартами.

 

то какието 4000 тестов, я с 2000 года гдето занимаюсь войпом и примерно с того времени юзаю openh323 стек но ниразу не слышал о этих тестах, я уже даже не представляю чего в следующий рас от вас ожидать

Лично мне трудно себе представить методологию разработки ПО без тестирования. Существует масса коммерческого и некоммерческого ПО для верификации парсеров различных стеков протоколов в том числе масса таких синтетических тестов есть для стека H.323 К сожалению о тестах не слышали не только вы, но и разработчики openh323

Речь идет о тестах такого рода, например существуют бесплатные тестовые наборы:

 

Q.931 elementsElement Present/Subelement Default value

Protocol discriminator Always 0x08

Call reference Always Test-case number in binary

Message type Always 0x05

Sending complete Never -

Repeat indicator Never -

Bearer capability Always -

- Coding standard ITU-T

- Information transfer capability Speech

- Transfer mode Circuit mode

- Information transfer rate 64kbps

- User information layer 1 protocol G.711 A-law

Extended facility Only when tested Exceptional

Channel identification Never -

Facility Only when tested Exceptional

Progress indicator Never -

Network specific facilities Never -

Notification indicator Only when tested Exceptional

Display Always "test-case" + Test-case number in ASCII

Keypad facility Only when tested "keypad value"

Signal Only when tested Dial tone on

Calling party number Only when tested -

- Type of number Unknown

- Numbering plan ISDN/telephony (E.164)

- Number digits "12345678"

Calling party subaddress Never -

Called party number Only when tested -

- Type of number Unknown

- Numbering plan ISDN/telephony (E.164)

- Number digits "12345678"

Called party subaddress Only when tested -

- Type of subaddress NSAP

- Subaddress information "12345678"

Redirecting Number Never -

Transit network selection Never -

Repeat indicator Never -

Low layer compatibility Never -

High layer compatibility Never -

User-user Always -

- Protocol discriminator 0x05

- User information In separate table

.....

 

Таких тестов я провожу 4000. Даже такой примитивный набор тестов не проходит хваленый MVTS

 

Есть и коммерческие варианты.

 

Предоставьте любой публичный ip-адрес - я протестирую то ПО которое вы испоьзуете. Но если там референсный openh323 - то готовьтесь, что в нем практически сразу будут появляться фатальные ошибки.

Я работал с несколькими библиотеками h.323 в том числе и собственной разработки, могу сказать, что openh323 - худший из вариантов в плане надежности. Одним из результатов моей работы было получение версии библиотеки проходящей - этот и не один десяток других наборов для тестирования, в том числе и коммерческого. Со стеком знаком не понаслышке. Как человек сталкивающийся не с одним сетевый протоколом - могу утвержать, что стек H.323 - избыточен, очень сложен в реализации.

 

Не даю ссылку на тесты, по той простой причине - что любой пионер сможет выводить из строя любой свитч с референсным openh323.

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

[GHhost]

to nag-f 91.195.204.1 на 74872710014 звоните, насчет ss7 сами поинтересуйтесь сначало.

to mikler кодеки в openh323 жестко не встроены.

[nag-f]

to nag-f 91.195.204.1 на 74872710014 звоните, насчет ss7 сами поинтересуйтесь сначало.

to mikler кодеки в openh323 жестко не встроены.

Ваше программное обеспечение не прошло даже первого теста!!!

[GHhost]

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

 

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

[nag-f]

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

Первый valid - тест. Далее нет смысла тестировать. Дорабатывайте. Удачи.

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

[Voicemaster]

Как успехи?

 

Докладываю. Оно уже машет крыльями и летает.

 

текущее TODO:

 

- перевести проксирование RTP из userspace на kernel level

- доделывание user web интерфейса (дизайн делается, но не быстро..)

 

 

.

 

[GHhost]

причем тут валидность? вы же говорили сыро сыпеца/валица, даже хваленый мвтс а вы не можете завалить какойто мой сраный гнугк + фрисвич с опалом в статусе альфы, вы уж определитесь, или идите нах со своими тестами, у меня с сотнями операторов оно работает и ничего страшного не происходит, дорабатывать дорабатываем потихоньку не переживайте за нас:)

 

Как успехи?

 

Докладываю. Оно уже машет крыльями и летает.

 

текущее TODO:

 

- перевести проксирование RTP из userspace на kernel level

- доделывание user web интерфейса (дизайн делается, но не быстро..)

.

а стоит при таких масштабах ртп проксировать?

[nag-f]

причем тут валидность? вы же говорили сыро сыпеца/валица, даже хваленый мвтс а вы не можете завалить какойто мой сраный гнугк + фрисвич с опалом в статусе альфы, вы уж определитесь, или идите нах со своими тестами, у меня с сотнями операторов оно работает и ничего страшного не происходит, дорабатывать дорабатываем потихоньку не переживайте за нас:)

Вы не разработчик, вы шаман.

[Voicemaster]

а стоит при таких масштабах ртп проксировать?

 

Пока думаю, что да - почти полностью решается проблема с NAT'aми. На kernel level это будет достаточно дешёво.

 

Далее надо будет думать, об очень умном и хитром комплексе RTP proxy's, который надо бы раскидать по всей России на крупных узлах обмена трафиком и отдавать клиентам лучший по RTT/Jitter маршрут.

 

 

.

[GHhost]

to nag-f, уважаемый, а вы че не звонили то? решил тут вдруг посмотреть звоночки а их туда и нету, из гугла копипастите чтоли?:)

[Voicemaster]

 

* вежливо просит сильно не холиварить ;-)

 

 

.

[GHhost]

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

[Voicemaster]

[...]

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

Тут вопрос открыт. Стоит ли привязывать такой номер географически или к операторам ?

 

 

.

[GHhost]

Кстати. Вот такой вопрос. У нас есть абонбаза в ~300 номеров. Есть софтсвич H.323 (MVTS). Есть небольшое количество звонков. Опишите мне качественный алгоритм (или дайте ссылку), как мне с помощью анализа ASR/ACD выбирать текущего оператора?

 

При моём небольшом количестве звонков отследить качество конкретного направления (город-оператор) крайне тяжело. Кроме того, у вас ASR при звонке с кодом 17 улучшается или не изменяется (традиционный ли подсчёт ASR)?

 

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

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

 

Тут вопрос открыт. Стоит ли привязывать такой номер географически или к операторам ?

.

думаю к оператору лучше, ктото работает на своей местности а ктото в весь мир, ктото и так и так. смысл привязываца к географии какой?

[leveler]

Объясните не в двух словах, я никуда не тороплюсь.

[GHhost]

дело в том что я тороплюсь, а тема обширная и что у вас есть и что вы хотите узнать я не знаю, или спрашивайте чтото поконкретней или лучше куданить в irc тогда чтоп других не отвлекать

[leveler]

Я подожду, когда вы освободитесь. Мне совсем не к спеху. А вот информация, имхо, будет не только мне любопытна.

 

Но если стесняетесь что: icq - 296104788, jabber - bshp@jabber.ru.

[GHhost]

я освобождаюсь уже лет 5, боюсь долго будите ждать:)

[Monstreek]

в джаббере конференцию создайте, что бы за разговором могли следить и другие (если конечно не секрет) :)

[GHhost]

bshp@jabber.ru.чето в оффлайне

 

voip@conference.jabber.tula-ix.net.ru если че

[Monstreek]

к конференции кто нибудь подключится смог, или она не работает у всех?

[GHhost]

я смог, тока я не помню где она у меня висит, мошт снаружи и не доступна, сделайте еще гденить