Comments 58
Большое спасибо за пост. Сейчас он мне очень пригодится так как пишу дипломку по теме IP-телефонии и буду испытывать и сравнивать разные решения для построения малой VoIP сети.
Расскажите, пжлста, про IP АТС от Panasonic (напр NCP1000). Есть ли у панаса преимущества перед астериском. Как астриск и панас дружат с SIP провайдерами (типа дом.ру и бит-телеком). Может быть в следующей статье. Было б полезно.
Панас – дорого и геморройно. Ибо деревянно. Астериск куда лучше.
Я, честно говоря, никогда не работал с панасониками, так что сказать ничего не могу. Насчет астериска — он по-моему дружит с чем угодно, хотя были определенные проблемы при попытке подружить его с циской.
У панаса политика «негарантирования» совместимости со сторонним железом) Т.е. теоретически должно, но «мы не гарантируем». Три года столкнулся с такой проблемой, в итоге вместо платы для панаса за 80 т.р. купил VoIP шлюз за 30. В плане аналога Панасоник — классные станции, надежные. Надежные они и под цифровую связь, но совместимость и гибкость настройки, конечно, слабовата.
На мой взгляд статья бесполезная чуть более, чем полностью. Понять из нее как и что работает все равно невозможно. Лучше бы уж плюсы/минусы расписали.
Еще одно явление, характерное для IP-телефонии — джиттер. Суть его состоит в том, что отправленные пакеты по ряду причин могут прибыть к получателю в неверном порядке.
Ну нет… Джиттер — вариация задержки. В идеальных условиях пакеты, отправленные с интервалом в 20мс, будут приняты получателем с тем же интервалом в 20мс вне зависимости от RTT, и их можно сразу декодировать и озвучивать. На практике, первый пакет дойдет за 50мс, следующий за 40мс, следующий за 150мс, и так далее. В таких условиях нельзя сразу воспроизводить звук, иначе беда, дошедший за 150мс пакет будет отброшен. Нужен буфер, в который пакеты набираются, что в свою очередь увеличивает задержку в разговоре.
А переупорядочивание пакетов — исключительно редкое явление. Сейчас никто не делает попакетной балансировки.
да, спасибо, действительно некорректно написал
> А переупорядочивание пакетов — исключительно редкое явление. Сейчас никто не делает попакетной балансировки.
Может и не делает, но мы регулярно сталкиваемся с переупорядочиванием пакетов. И как это у провайдера получается
Может и не делает, но мы регулярно сталкиваемся с переупорядочиванием пакетов. И как это у провайдера получается
Регулярно — в смысле действительно постоянно, то есть из десятка пакетов хотя бы пара перепутается местами? Такое и TCP очень плохо переносит — обычно он приравнивает такое к потерянному пакету.
А если изредка, в момент перемаршрутизации, когда N-ный пакет шел по одному линку, а N+1-й и последующие по другому — это нормально.
«Как получается»? Да запросто. На старом железе можно сказать «ip cef load-sharing per-packet». Новое уже так не умеет — и хорошо.
А если изредка, в момент перемаршрутизации, когда N-ный пакет шел по одному линку, а N+1-й и последующие по другому — это нормально.
«Как получается»? Да запросто. На старом железе можно сказать «ip cef load-sharing per-packet». Новое уже так не умеет — и хорошо.
Да, регулярно — это постоянно. Из десятка не знаю, вот результат тестирования ttcp
Datagrams (max data segment is 1460 bytes):
Rcvd: 611 (out of order: 145), with data: 600, total data bytes: 819200
Да, подтверждаю tcp от Windows (с дефолтными настройками) такое переносит плохо, а TCP от linux нормально это обрабатывает.
Это магистральный провайдер, который нам дает MPLS VPN.
Datagrams (max data segment is 1460 bytes):
Rcvd: 611 (out of order: 145), with data: 600, total data bytes: 819200
Да, подтверждаю tcp от Windows (с дефолтными настройками) такое переносит плохо, а TCP от linux нормально это обрабатывает.
Это магистральный провайдер, который нам дает MPLS VPN.
То, что вы описали — это ошибка конфигурации, без вариантов. Собираете дамп пакетов, заводите заявку, раз в час пинаете их.
Пинали год. Пока «само» не починилось. А может и не починилось но уже просто все к этом привыкли.
В процессе пинание вышли на верхушку компании — это тоже не помогло. Инженеры компании клянутся, что нигде нет никаких параллельных путей.
В процессе пинание вышли на верхушку компании — это тоже не помогло. Инженеры компании клянутся, что нигде нет никаких параллельных путей.
Инженеры компании клянутся, что нигде нет никаких параллельных путей.
Тут надо не клясться, а тестировать. Пусть высунут в ваш VRF несколько интерфейсов на разных участках пути, ну и IP SLA до нескольких сразу. Мы такое не раз делали, к примеру, в случае дропов где-то не пойми где на канале. После такого проблема редко решается более чем за день.
Дима, поверь, это делалось. Когда они высовывали другие участки — проблем нет, а на составном — есть :)
Ну значит плохо тестировали. Мы в таких случаях призываем в офис сервис-менеджера и начальника управления, проводим с ними беседу на тему «вокруг так много замечательных провайдеров», и после этого проблема волшебным образом самоустраняется.
Если не трудно. Объясните как вписываются в ip телефонию аналоговые модемы и факсы. Например есть офисная сеть, есть ip АТС (например Asterisk), есть шлюзы FXS и FXO (для подключения аналоговых абонентов внутри сети и подключения нашей ip АТС к аналоговым линиям провайдера). Будут ли в такой конфигурации работать аналоговые факсы и модемы? Какие протоколы для этого должны поддерживать шлюзы (T.30, T.38)? Какая максимальная скорость доступна? Заранее благодарю.
Зависит от возможностей шлюза. Сейчас большинство моделей поддерживают Т.38, однако это не означает, что все будет работать на 100%. Бывают, что разные реализации Т.38, его инициации и возврата на 711-й делают передачу факсов просто невозможной. Ну и кроме того, если по дороге есть NAT, то с вероятностью 95% факс по Т.38 передаваться не будет.
Из практики по asterix факсы бегают нормально по кодеку g711, факс модем максимум выжимает 4800 бит в секунду, pos терминалы (для работы с картами) работают нормально (там скорости смешные по v24 или v32). По g729, который сильно жмет работал только голос.
g711 сам по себе поддерживает факсы без необходимости переключаться на Т.38, поэтому если в офисной сети используется g711, и шлюзы его поддерживают, то факсы должны, в теории (и как пока показывала практика), работать. Если же в сети в приоритете g729, то шлюзы должны уметь T.38, но при переключении возникают разные странные проблемы, так что 100% гарантии работоспособности не дать.
Тоже диплом будет по подобной теме, только нужно много математики, помимо практической части хочу рассмотреть несколько протоколов. Не подскажете качественных источников подобного? Желательно книги на русском/английском.
как минимум, “Протокол SIP. Справочник”. Б. С. Гольдштейн, А. А. Зарубин, В. В. Саморезов.
Очень полное описание протокола.
Очень полное описание протокола.
А какие протоколы собираетесь рассматривать? Сигнализации? Или передачи голоса? Или передачи видео? Или контроля?
SIP — все в RFC. Смотрите в RFC — книг нормальных по SIP я не нашел.
H.323 — смотрите на сайте itu — ссылки тут en.wikipedia.org/wiki/H.323#ITU-T_Recommendations_of_the_H.323_System
MGCP — RFC
RTP — RFC
RTCP — RFC
и т.д.
SIP — все в RFC. Смотрите в RFC — книг нормальных по SIP я не нашел.
H.323 — смотрите на сайте itu — ссылки тут en.wikipedia.org/wiki/H.323#ITU-T_Recommendations_of_the_H.323_System
MGCP — RFC
RTP — RFC
RTCP — RFC
и т.д.
> Из преимуществ Cisco CallManager следует отметить в первую очередь знаменитую техническую поддержку корпорации Cisco. При соответствующем уровне контракта на обслуживание, любая проблема, начиная с вопросов по настройке и заканчивая вышедшим из строя оборудованием, будет решена практически мгновенно. Поэтому Cisco CallManager подойдет компаниям, готовым платить немалые деньги, но и получать при этом высочайшее качество обслуживания.
Это просто ложь.
Не мгновенно и не высочайшее. Готовьтесь открыть тикет и ждать час минимум, пока с вам свяжется инженер (даже если открыли с высоким приоритетом). А потом готовтесь, что ваш тикет, в зависимости от сложности будет вичеть от дня до нескольких месяцев. При этом если тикет не на тему «как включить галочку» — то его еще, скорее всего, решить не смогут.
Это просто ложь.
Не мгновенно и не высочайшее. Готовьтесь открыть тикет и ждать час минимум, пока с вам свяжется инженер (даже если открыли с высоким приоритетом). А потом готовтесь, что ваш тикет, в зависимости от сложности будет вичеть от дня до нескольких месяцев. При этом если тикет не на тему «как включить галочку» — то его еще, скорее всего, решить не смогут.
Да ладно вам… За йеменцев не скажу, они традиционно деревянные, но в нашем TACе сидят очень грамотные ребята.
Правда, у CUCM есть и другие преимущества. Он офигительно прост и удобен в работе, чертовски стабилен (я на нем вроде ни одного бага не видел) и при этом отлично масштабируется.
Только:
«до 30000 абонентов» — это на кластер, а не на сервер.
«программно-аппаратный комплекс» — нет в нем ничего аппаратного. Последние версии вообще рекомендовано виртуализировать.
Правда, у CUCM есть и другие преимущества. Он офигительно прост и удобен в работе, чертовски стабилен (я на нем вроде ни одного бага не видел) и при этом отлично масштабируется.
Только:
«до 30000 абонентов» — это на кластер, а не на сервер.
«программно-аппаратный комплекс» — нет в нем ничего аппаратного. Последние версии вообще рекомендовано виртуализировать.
Русский TAC, польский TAC — выше всяких похвал. Но все равно не мгновенно. :) Ребята в русском таке перегружены.
Про простоту CUCM-а я бы сильно поспорил. Прост для чего? Например как на нем просто для 5-ти сотен телефонов изменить какой-то параметр, причем значение этого параметра для всех 5-ти телефонов не одинаковое?
Про стабильность — лично две недели назад запилил два бага с помощью TAC-а. Сейчас еще один баг между TAC-ом и программистами cucm-а завис. На этих выходных обновлял его (накатывал SU). Так это «создание» при перезагрузке впало в кому на полчаса, потом сказала «дискам капец. Timeout» и не запустила сервисы. Перезагрузка — и все как по маслу. И так на каждом сервере :) Или еще бага как AXL вытаскивает удаленных пользователей и выдает их за живых :)
И еще претензия к CUCM-у — уж больно через версии он скачет. 7-8-9 — покупать не успеваешь, а разработчики фиксить баги.
Про простоту CUCM-а я бы сильно поспорил. Прост для чего? Например как на нем просто для 5-ти сотен телефонов изменить какой-то параметр, причем значение этого параметра для всех 5-ти телефонов не одинаковое?
Про стабильность — лично две недели назад запилил два бага с помощью TAC-а. Сейчас еще один баг между TAC-ом и программистами cucm-а завис. На этих выходных обновлял его (накатывал SU). Так это «создание» при перезагрузке впало в кому на полчаса, потом сказала «дискам капец. Timeout» и не запустила сервисы. Перезагрузка — и все как по маслу. И так на каждом сервере :) Или еще бага как AXL вытаскивает удаленных пользователей и выдает их за живых :)
И еще претензия к CUCM-у — уж больно через версии он скачет. 7-8-9 — покупать не успеваешь, а разработчики фиксить баги.
До сих пор сидим на 6ке. Только сейчас купили 9.
Но все равно не мгновенно.
По severity 3 — да, час-два может потребоваться подождать (обычно оно и не горит). По более высоким — оператор сразу переводит на инженера.
Например как на нем просто для 5-ти сотен телефонов изменить какой-то параметр, причем значение этого параметра для всех 5-ти телефонов не одинаковое?
Подготовить CSV в екселе, затем BAT. А еще лучше продумать архитектуру так, чтобы делать такое не потребовалось, благо он позволяет. Мне не требовалось.
Про стабильность — лично две недели назад запилил два бага с помощью TAC-а.
Если не секрет — что за линейка? Или вы уже на 9? Любой цисковод знает, что НЕ НАДО сразу переводить прод на новую мажорную версию. 9-й еще и года не исполнилось :)
И еще претензия к CUCM-у — уж больно через версии он скачет.
Циска же. И баги в большинстве своем чинятся без мажорных апдейтов. Вон под 7 до сих пор SU выходят.
1. Это зависит от продукта. Или от расположения звезд на небе. У меня было что я висел на телефоне 1.5 часа при отказе сети и ждал пока найдут инженера.
2. Ну да. То есть получается, чтобы обновить один параметр — то надо — экспортировать телефоны, удалить их, импортировать телефоны (и молится, что импортер не сломается). А в это время пользователи без телефонов сидят. Я так не делаю, я предпочитаю через axl телефоны настраивать. Но это каждый раз программу писать. Не тянет это на легкость конфигурирования. Не требовалось — значит не было достаточного опыта эксплуатации.
3. 8.6.x. И посмотри в багтуле сколько тикетов открытых на эту mature версию.
4. ну да, Зато под 6.1 su больше не выходят.:)
2. Ну да. То есть получается, чтобы обновить один параметр — то надо — экспортировать телефоны, удалить их, импортировать телефоны (и молится, что импортер не сломается). А в это время пользователи без телефонов сидят. Я так не делаю, я предпочитаю через axl телефоны настраивать. Но это каждый раз программу писать. Не тянет это на легкость конфигурирования. Не требовалось — значит не было достаточного опыта эксплуатации.
3. 8.6.x. И посмотри в багтуле сколько тикетов открытых на эту mature версию.
4. ну да, Зато под 6.1 su больше не выходят.:)
2. Опыт эксплуатации есть. Есть инфраструктура на тысячи телефонов и сотни шлюзов. Но я вот думаю — и не могу придумать, зачем такое. Разве что смена плана нумерации, или ext phone number mask хитрый прописать…
3. Ну не глючит седьмая версия :) Пару раз пытался поймать ее на косяках, уже радовался, запускал трейсы (единственное отвратительное в CUCM), чтобы сразу всё к кейсу приложить — и находил собственный косяк.
3. Ну не глючит седьмая версия :) Пару раз пытался поймать ее на косяках, уже радовался, запускал трейсы (единственное отвратительное в CUCM), чтобы сразу всё к кейсу приложить — и находил собственный косяк.
2. Например, прописывание другой CSS для группы телефонов. Причем для одной группы — один CSS, для второй группы — другой CSS. Причем это просто так не отфильтровать, чтобы BAT-ом запустить изменение двух групп.
3. Не глючит — значит вы счастливчик. Кто-то ведь заводит все эти баги из багтула, которые потом фиксятся? Ну вот баг навскидку — Я не видел 7-ку, но я почти уверен, что на сайте «Cisco Unified Communications Manager CDR Analysis and Reporting» прикладывается (или не прикладывается совсем) правильный css на главной странице. Дизайна попросту нет. Это было так и в 6-й версии и в 8-й.
Я понимаю что баг косметический, но меня он крайне удивляет — уж настолько явный и настолько легко чинящийся. Ан нет.
3. Не глючит — значит вы счастливчик. Кто-то ведь заводит все эти баги из багтула, которые потом фиксятся? Ну вот баг навскидку — Я не видел 7-ку, но я почти уверен, что на сайте «Cisco Unified Communications Manager CDR Analysis and Reporting» прикладывается (или не прикладывается совсем) правильный css на главной странице. Дизайна попросту нет. Это было так и в 6-й версии и в 8-й.
Я понимаю что баг косметический, но меня он крайне удивляет — уж настолько явный и настолько легко чинящийся. Ан нет.
2. А цель-то какая?
Да и в BATе можно тупо перечислить DNы, а дальше уже одним кликом применить к группе нужный CSS. И я плохо представляю себе что-либо радикально более удобное. Все равно потребуется перечислять список номеров.
3. Выглядит странно. Работает полноценно.
Да и в BATе можно тупо перечислить DNы, а дальше уже одним кликом применить к группе нужный CSS. И я плохо представляю себе что-либо радикально более удобное. Все равно потребуется перечислять список номеров.
3. Выглядит странно. Работает полноценно.
2. Можно перечислить 10 телефонов за раз по их SEPid. Долго и муторно. Радикально более удобное — это как в BAT-е сделано обновление пользователей — дал CSV файл в котором userid и то поле что меняешь — и все поменялось. Быстро и удобно. Для телефонов такую штуку не запилили.
3. Так про все что угодно можно сказать. :)
3. Так про все что угодно можно сказать. :)
UFO just landed and posted this here
У Cisco есть call manager express который работает на рутерах. Для небольших офисов самое оно.
Важно не забывать, что сеть SDH (на ней строится традиционная сеть телефонии) до сих пор является самой оптимальной по скорости передачи голосовой информации. IP-сеть хорошо, но там каждый узел вносит заметные задержки в распространение сигнала. Фактически IP сети стали пригодны для передачи голосового трафика без дискомфорта дла абонентов лишь во времена внедрения гигабитных каналов. До сих пор реальные операторы связи придерживаются правила: на близких дистанциях (район с деревнями) допустимо IP, всё что дальше (междугородняя/международная связь) до сих пор SDH сеть с E1. Впрочем, чего там разбираться. Есть жёсткие требования к качеству связи, которую традиционные операторы обязаны выполнять. Сеть IP там не всегда справиться сможет, особенно если учесть, что кроме голосового трафика по IP сети течёт ещё и менее предсказуемый по объёмам интернет.
UFO just landed and posted this here
сеть SDH (на ней строится традиционная сеть телефонии) до сих пор является самой оптимальной по скорости передачи голосовой информации.
Сейчас и междугородку все активно переводят на IP. Это дешевле и удобнее. Я уж не говорю о том, что даже в моей конторе ЦО в Москве может общаться с дальним заМКАДьем вроде Владивостока поверх GRE/IPSec туннелей поверх обычных IP VPN каналов связи, и характеристики связи будут на высоком уровне.
Ну и «SDH сеть с E1» очень не вяжется с «самой оптимальной по скорости передачи голосовой информации». Когда говорят о скорости, я представляю себе гигабиты, а не миллисекунды, с которыми особых проблем нет. Да, некоторые операторы любили мультиплексировать десятки Е1 потоков, но все пытаются избавиться от этого безумия.
кроме голосового трафика по IP сети течёт ещё и менее предсказуемый по объёмам интернет.
А QoS на что? Если настроить правильно, то при 100% утилизации канала ни один голосовой пакет не дропнется и не задержится в очереди. Для крупных операторов вроде РТТ, ТТК на своей сети это не такая уж и проблема.
UFO just landed and posted this here
Эффективность SDH при передаче голосового трафика значительно выше.
Учитывая, что многие ограничиваются тем самым E1, не поднимаясь выше — не факт :) Потребность в отдельной инфраструктуре еще больше мешает.
И надежность, и резервирование маршрутов у SDH тоже гораздо выше и быстрее.
Правильно настроенная пакетная сеть приближается к этим значениям. FRR сходится за примерно 50мс. Это уже тот уровень, когда можно сказать «этого достаточно».
Почему через IP-телефонию SMS не устраивают?
Зачем передавать SMS через IP-телефонию? Ничего, что это немного разные штуки (одна — текст, другая — голос в реальном времени)?
Возможно потому, что стоимость СМС оператора слишком высока, особенное если рассылать их например всем для активации по 10000 в день? :)
И все-таки, какое отношение имеет передача сообщений к IP-телефонии?
Вам мало решений либо на XMPP, либо на email=>XMPP и тому подобных?
Вам мало решений либо на XMPP, либо на email=>XMPP и тому подобных?
Иногда удобно скинуть короткий текст на IP телефон
Например человек на переговорах и у него с собой дектовская айпи трубка
xmpp и подобные тоже не поддерживаются «железными телефонами», а только софтфоном (спарк и тд)
В 11 версии астериска есть текстовые сообщения, но опять же нет поддержек у «железа»
Например человек на переговорах и у него с собой дектовская айпи трубка
xmpp и подобные тоже не поддерживаются «железными телефонами», а только софтфоном (спарк и тд)
В 11 версии астериска есть текстовые сообщения, но опять же нет поддержек у «железа»
возможно я просто что-то не то знаю про XMPP но отправить рассылку на 1000 телефонов задешево оно не помогает. Или я не знаю как — подскажите.
Еще как устраивают — rfc3428
> случайная задержка распространения пакета
Имхо лучше говорить «вариация задержки» — так по крайней мере во многих документах. «Случайная задержка» же подразумевает разделение на случайные и стабильные задержки, что не так очевидно и в добавок не совсем верно.
Размер джиттер буфера надо выставлять с учетом реакции сети на аварии, например если время схождения 50мс, то и и размер буфера стоит ставить больше. Также надо смотреть как работает оборудование и какие тайминги для перезапроса потерянных пакетов, которые например на радио по дефолту достаточно большие — до 0.5 с, что для Voip уже слишком много.
Краем уха слышал что до 100мс задержки вполне комфортны, но они учитывают всю задержку, а размер джиттер-буфера прибавляется к средней задержке на сети. На практике не чувствовал проблем при увеличении джиттер буфера до 40-50мс.
Решений привели как-то странно.
для мелких офисов и провайдеров — asterisk вне конкуренции, причем не важно сколько там абонентов — можно и сотню тысяч забить без проблем, важно какой трафик — грубо говоря сколько звонков одновременно и тут сервер держит от сотни до тысячи, в зависимости от мощности и тюнинга.
для сетей покрупнее — есть огромное количество решений — каждый из грандов телефонии как минимум может предложить свое, главное в них — распределение нагрузки на кластера, поскольку железо там такое-же.
Имхо лучше говорить «вариация задержки» — так по крайней мере во многих документах. «Случайная задержка» же подразумевает разделение на случайные и стабильные задержки, что не так очевидно и в добавок не совсем верно.
Размер джиттер буфера надо выставлять с учетом реакции сети на аварии, например если время схождения 50мс, то и и размер буфера стоит ставить больше. Также надо смотреть как работает оборудование и какие тайминги для перезапроса потерянных пакетов, которые например на радио по дефолту достаточно большие — до 0.5 с, что для Voip уже слишком много.
Краем уха слышал что до 100мс задержки вполне комфортны, но они учитывают всю задержку, а размер джиттер-буфера прибавляется к средней задержке на сети. На практике не чувствовал проблем при увеличении джиттер буфера до 40-50мс.
Решений привели как-то странно.
для мелких офисов и провайдеров — asterisk вне конкуренции, причем не важно сколько там абонентов — можно и сотню тысяч забить без проблем, важно какой трафик — грубо говоря сколько звонков одновременно и тут сервер держит от сотни до тысячи, в зависимости от мощности и тюнинга.
для сетей покрупнее — есть огромное количество решений — каждый из грандов телефонии как минимум может предложить свое, главное в них — распределение нагрузки на кластера, поскольку железо там такое-же.
Sign up to leave a comment.
Основы IP-телефонии, базовые принципы, термины и протоколы