Комментарии 58
Большое спасибо за пост. Сейчас он мне очень пригодится так как пишу дипломку по теме IP-телефонии и буду испытывать и сравнивать разные решения для построения малой VoIP сети.
-1
Недавно пробовал клиента надоумит на IP-телефонию внутри офиса на 15 чел. Наткнулся на полное непонимаение со стороны руководства. В итоге купили аналоговую мини АТС. Может такое замечание будет полезно для Вашего диплома.
+1
Расскажите, пжлста, про IP АТС от Panasonic (напр NCP1000). Есть ли у панаса преимущества перед астериском. Как астриск и панас дружат с SIP провайдерами (типа дом.ру и бит-телеком). Может быть в следующей статье. Было б полезно.
+1
Панас – дорого и геморройно. Ибо деревянно. Астериск куда лучше.
+6
Я, честно говоря, никогда не работал с панасониками, так что сказать ничего не могу. Насчет астериска — он по-моему дружит с чем угодно, хотя были определенные проблемы при попытке подружить его с циской.
0
У панаса политика «негарантирования» совместимости со сторонним железом) Т.е. теоретически должно, но «мы не гарантируем». Три года столкнулся с такой проблемой, в итоге вместо платы для панаса за 80 т.р. купил VoIP шлюз за 30. В плане аналога Панасоник — классные станции, надежные. Надежные они и под цифровую связь, но совместимость и гибкость настройки, конечно, слабовата.
0
На мой взгляд статья бесполезная чуть более, чем полностью. Понять из нее как и что работает все равно невозможно. Лучше бы уж плюсы/минусы расписали.
-1
Еще одно явление, характерное для IP-телефонии — джиттер. Суть его состоит в том, что отправленные пакеты по ряду причин могут прибыть к получателю в неверном порядке.
Ну нет… Джиттер — вариация задержки. В идеальных условиях пакеты, отправленные с интервалом в 20мс, будут приняты получателем с тем же интервалом в 20мс вне зависимости от RTT, и их можно сразу декодировать и озвучивать. На практике, первый пакет дойдет за 50мс, следующий за 40мс, следующий за 150мс, и так далее. В таких условиях нельзя сразу воспроизводить звук, иначе беда, дошедший за 150мс пакет будет отброшен. Нужен буфер, в который пакеты набираются, что в свою очередь увеличивает задержку в разговоре.
А переупорядочивание пакетов — исключительно редкое явление. Сейчас никто не делает попакетной балансировки.
+4
да, спасибо, действительно некорректно написал
0
> А переупорядочивание пакетов — исключительно редкое явление. Сейчас никто не делает попакетной балансировки.
Может и не делает, но мы регулярно сталкиваемся с переупорядочиванием пакетов. И как это у провайдера получается
Может и не делает, но мы регулярно сталкиваемся с переупорядочиванием пакетов. И как это у провайдера получается
0
Регулярно — в смысле действительно постоянно, то есть из десятка пакетов хотя бы пара перепутается местами? Такое и TCP очень плохо переносит — обычно он приравнивает такое к потерянному пакету.
А если изредка, в момент перемаршрутизации, когда N-ный пакет шел по одному линку, а N+1-й и последующие по другому — это нормально.
«Как получается»? Да запросто. На старом железе можно сказать «ip cef load-sharing per-packet». Новое уже так не умеет — и хорошо.
А если изредка, в момент перемаршрутизации, когда N-ный пакет шел по одному линку, а N+1-й и последующие по другому — это нормально.
«Как получается»? Да запросто. На старом железе можно сказать «ip cef load-sharing per-packet». Новое уже так не умеет — и хорошо.
0
Да, регулярно — это постоянно. Из десятка не знаю, вот результат тестирования 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.
0
То, что вы описали — это ошибка конфигурации, без вариантов. Собираете дамп пакетов, заводите заявку, раз в час пинаете их.
0
Пинали год. Пока «само» не починилось. А может и не починилось но уже просто все к этом привыкли.
В процессе пинание вышли на верхушку компании — это тоже не помогло. Инженеры компании клянутся, что нигде нет никаких параллельных путей.
В процессе пинание вышли на верхушку компании — это тоже не помогло. Инженеры компании клянутся, что нигде нет никаких параллельных путей.
0
Инженеры компании клянутся, что нигде нет никаких параллельных путей.
Тут надо не клясться, а тестировать. Пусть высунут в ваш VRF несколько интерфейсов на разных участках пути, ну и IP SLA до нескольких сразу. Мы такое не раз делали, к примеру, в случае дропов где-то не пойми где на канале. После такого проблема редко решается более чем за день.
0
Дима, поверь, это делалось. Когда они высовывали другие участки — проблем нет, а на составном — есть :)
0
Ну значит плохо тестировали. Мы в таких случаях призываем в офис сервис-менеджера и начальника управления, проводим с ними беседу на тему «вокруг так много замечательных провайдеров», и после этого проблема волшебным образом самоустраняется.
0
Если не трудно. Объясните как вписываются в ip телефонию аналоговые модемы и факсы. Например есть офисная сеть, есть ip АТС (например Asterisk), есть шлюзы FXS и FXO (для подключения аналоговых абонентов внутри сети и подключения нашей ip АТС к аналоговым линиям провайдера). Будут ли в такой конфигурации работать аналоговые факсы и модемы? Какие протоколы для этого должны поддерживать шлюзы (T.30, T.38)? Какая максимальная скорость доступна? Заранее благодарю.
+1
Зависит от возможностей шлюза. Сейчас большинство моделей поддерживают Т.38, однако это не означает, что все будет работать на 100%. Бывают, что разные реализации Т.38, его инициации и возврата на 711-й делают передачу факсов просто невозможной. Ну и кроме того, если по дороге есть NAT, то с вероятностью 95% факс по Т.38 передаваться не будет.
+1
Из практики по asterix факсы бегают нормально по кодеку g711, факс модем максимум выжимает 4800 бит в секунду, pos терминалы (для работы с картами) работают нормально (там скорости смешные по v24 или v32). По g729, который сильно жмет работал только голос.
+1
g711 сам по себе поддерживает факсы без необходимости переключаться на Т.38, поэтому если в офисной сети используется g711, и шлюзы его поддерживают, то факсы должны, в теории (и как пока показывала практика), работать. Если же в сети в приоритете g729, то шлюзы должны уметь T.38, но при переключении возникают разные странные проблемы, так что 100% гарантии работоспособности не дать.
+1
Тоже диплом будет по подобной теме, только нужно много математики, помимо практической части хочу рассмотреть несколько протоколов. Не подскажете качественных источников подобного? Желательно книги на русском/английском.
0
как минимум, “Протокол SIP. Справочник”. Б. С. Гольдштейн, А. А. Зарубин, В. В. Саморезов.
Очень полное описание протокола.
Очень полное описание протокола.
+1
А какие протоколы собираетесь рассматривать? Сигнализации? Или передачи голоса? Или передачи видео? Или контроля?
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
и т.д.
+1
> Из преимуществ Cisco CallManager следует отметить в первую очередь знаменитую техническую поддержку корпорации Cisco. При соответствующем уровне контракта на обслуживание, любая проблема, начиная с вопросов по настройке и заканчивая вышедшим из строя оборудованием, будет решена практически мгновенно. Поэтому Cisco CallManager подойдет компаниям, готовым платить немалые деньги, но и получать при этом высочайшее качество обслуживания.
Это просто ложь.
Не мгновенно и не высочайшее. Готовьтесь открыть тикет и ждать час минимум, пока с вам свяжется инженер (даже если открыли с высоким приоритетом). А потом готовтесь, что ваш тикет, в зависимости от сложности будет вичеть от дня до нескольких месяцев. При этом если тикет не на тему «как включить галочку» — то его еще, скорее всего, решить не смогут.
Это просто ложь.
Не мгновенно и не высочайшее. Готовьтесь открыть тикет и ждать час минимум, пока с вам свяжется инженер (даже если открыли с высоким приоритетом). А потом готовтесь, что ваш тикет, в зависимости от сложности будет вичеть от дня до нескольких месяцев. При этом если тикет не на тему «как включить галочку» — то его еще, скорее всего, решить не смогут.
0
Да ладно вам… За йеменцев не скажу, они традиционно деревянные, но в нашем TACе сидят очень грамотные ребята.
Правда, у CUCM есть и другие преимущества. Он офигительно прост и удобен в работе, чертовски стабилен (я на нем вроде ни одного бага не видел) и при этом отлично масштабируется.
Только:
«до 30000 абонентов» — это на кластер, а не на сервер.
«программно-аппаратный комплекс» — нет в нем ничего аппаратного. Последние версии вообще рекомендовано виртуализировать.
Правда, у CUCM есть и другие преимущества. Он офигительно прост и удобен в работе, чертовски стабилен (я на нем вроде ни одного бага не видел) и при этом отлично масштабируется.
Только:
«до 30000 абонентов» — это на кластер, а не на сервер.
«программно-аппаратный комплекс» — нет в нем ничего аппаратного. Последние версии вообще рекомендовано виртуализировать.
0
Русский 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 — покупать не успеваешь, а разработчики фиксить баги.
0
До сих пор сидим на 6ке. Только сейчас купили 9.
0
Но все равно не мгновенно.
По severity 3 — да, час-два может потребоваться подождать (обычно оно и не горит). По более высоким — оператор сразу переводит на инженера.
Например как на нем просто для 5-ти сотен телефонов изменить какой-то параметр, причем значение этого параметра для всех 5-ти телефонов не одинаковое?
Подготовить CSV в екселе, затем BAT. А еще лучше продумать архитектуру так, чтобы делать такое не потребовалось, благо он позволяет. Мне не требовалось.
Про стабильность — лично две недели назад запилил два бага с помощью TAC-а.
Если не секрет — что за линейка? Или вы уже на 9? Любой цисковод знает, что НЕ НАДО сразу переводить прод на новую мажорную версию. 9-й еще и года не исполнилось :)
И еще претензия к CUCM-у — уж больно через версии он скачет.
Циска же. И баги в большинстве своем чинятся без мажорных апдейтов. Вон под 7 до сих пор SU выходят.
0
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 больше не выходят.:)
0
2. Опыт эксплуатации есть. Есть инфраструктура на тысячи телефонов и сотни шлюзов. Но я вот думаю — и не могу придумать, зачем такое. Разве что смена плана нумерации, или ext phone number mask хитрый прописать…
3. Ну не глючит седьмая версия :) Пару раз пытался поймать ее на косяках, уже радовался, запускал трейсы (единственное отвратительное в CUCM), чтобы сразу всё к кейсу приложить — и находил собственный косяк.
3. Ну не глючит седьмая версия :) Пару раз пытался поймать ее на косяках, уже радовался, запускал трейсы (единственное отвратительное в CUCM), чтобы сразу всё к кейсу приложить — и находил собственный косяк.
0
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-й.
Я понимаю что баг косметический, но меня он крайне удивляет — уж настолько явный и настолько легко чинящийся. Ан нет.
0
2. А цель-то какая?
Да и в BATе можно тупо перечислить DNы, а дальше уже одним кликом применить к группе нужный CSS. И я плохо представляю себе что-либо радикально более удобное. Все равно потребуется перечислять список номеров.
3. Выглядит странно. Работает полноценно.
Да и в BATе можно тупо перечислить DNы, а дальше уже одним кликом применить к группе нужный CSS. И я плохо представляю себе что-либо радикально более удобное. Все равно потребуется перечислять список номеров.
3. Выглядит странно. Работает полноценно.
0
2. Можно перечислить 10 телефонов за раз по их SEPid. Долго и муторно. Радикально более удобное — это как в BAT-е сделано обновление пользователей — дал CSV файл в котором userid и то поле что меняешь — и все поменялось. Быстро и удобно. Для телефонов такую штуку не запилили.
3. Так про все что угодно можно сказать. :)
3. Так про все что угодно можно сказать. :)
0
НЛО прилетело и опубликовало эту надпись здесь
У Cisco есть call manager express который работает на рутерах. Для небольших офисов самое оно.
0
Важно не забывать, что сеть SDH (на ней строится традиционная сеть телефонии) до сих пор является самой оптимальной по скорости передачи голосовой информации. IP-сеть хорошо, но там каждый узел вносит заметные задержки в распространение сигнала. Фактически IP сети стали пригодны для передачи голосового трафика без дискомфорта дла абонентов лишь во времена внедрения гигабитных каналов. До сих пор реальные операторы связи придерживаются правила: на близких дистанциях (район с деревнями) допустимо IP, всё что дальше (междугородняя/международная связь) до сих пор SDH сеть с E1. Впрочем, чего там разбираться. Есть жёсткие требования к качеству связи, которую традиционные операторы обязаны выполнять. Сеть IP там не всегда справиться сможет, особенно если учесть, что кроме голосового трафика по IP сети течёт ещё и менее предсказуемый по объёмам интернет.
+1
НЛО прилетело и опубликовало эту надпись здесь
сеть SDH (на ней строится традиционная сеть телефонии) до сих пор является самой оптимальной по скорости передачи голосовой информации.
Сейчас и междугородку все активно переводят на IP. Это дешевле и удобнее. Я уж не говорю о том, что даже в моей конторе ЦО в Москве может общаться с дальним заМКАДьем вроде Владивостока поверх GRE/IPSec туннелей поверх обычных IP VPN каналов связи, и характеристики связи будут на высоком уровне.
Ну и «SDH сеть с E1» очень не вяжется с «самой оптимальной по скорости передачи голосовой информации». Когда говорят о скорости, я представляю себе гигабиты, а не миллисекунды, с которыми особых проблем нет. Да, некоторые операторы любили мультиплексировать десятки Е1 потоков, но все пытаются избавиться от этого безумия.
кроме голосового трафика по IP сети течёт ещё и менее предсказуемый по объёмам интернет.
А QoS на что? Если настроить правильно, то при 100% утилизации канала ни один голосовой пакет не дропнется и не задержится в очереди. Для крупных операторов вроде РТТ, ТТК на своей сети это не такая уж и проблема.
0
НЛО прилетело и опубликовало эту надпись здесь
Эффективность SDH при передаче голосового трафика значительно выше.
Учитывая, что многие ограничиваются тем самым E1, не поднимаясь выше — не факт :) Потребность в отдельной инфраструктуре еще больше мешает.
И надежность, и резервирование маршрутов у SDH тоже гораздо выше и быстрее.
Правильно настроенная пакетная сеть приближается к этим значениям. FRR сходится за примерно 50мс. Это уже тот уровень, когда можно сказать «этого достаточно».
-1
Почему через IP-телефонию SMS не устраивают?
0
Зачем передавать SMS через IP-телефонию? Ничего, что это немного разные штуки (одна — текст, другая — голос в реальном времени)?
0
Возможно потому, что стоимость СМС оператора слишком высока, особенное если рассылать их например всем для активации по 10000 в день? :)
0
И все-таки, какое отношение имеет передача сообщений к IP-телефонии?
Вам мало решений либо на XMPP, либо на email=>XMPP и тому подобных?
Вам мало решений либо на XMPP, либо на email=>XMPP и тому подобных?
0
Иногда удобно скинуть короткий текст на IP телефон
Например человек на переговорах и у него с собой дектовская айпи трубка
xmpp и подобные тоже не поддерживаются «железными телефонами», а только софтфоном (спарк и тд)
В 11 версии астериска есть текстовые сообщения, но опять же нет поддержек у «железа»
Например человек на переговорах и у него с собой дектовская айпи трубка
xmpp и подобные тоже не поддерживаются «железными телефонами», а только софтфоном (спарк и тд)
В 11 версии астериска есть текстовые сообщения, но опять же нет поддержек у «железа»
0
возможно я просто что-то не то знаю про XMPP но отправить рассылку на 1000 телефонов задешево оно не помогает. Или я не знаю как — подскажите.
0
Еще как устраивают — rfc3428
0
> случайная задержка распространения пакета
Имхо лучше говорить «вариация задержки» — так по крайней мере во многих документах. «Случайная задержка» же подразумевает разделение на случайные и стабильные задержки, что не так очевидно и в добавок не совсем верно.
Размер джиттер буфера надо выставлять с учетом реакции сети на аварии, например если время схождения 50мс, то и и размер буфера стоит ставить больше. Также надо смотреть как работает оборудование и какие тайминги для перезапроса потерянных пакетов, которые например на радио по дефолту достаточно большие — до 0.5 с, что для Voip уже слишком много.
Краем уха слышал что до 100мс задержки вполне комфортны, но они учитывают всю задержку, а размер джиттер-буфера прибавляется к средней задержке на сети. На практике не чувствовал проблем при увеличении джиттер буфера до 40-50мс.
Решений привели как-то странно.
для мелких офисов и провайдеров — asterisk вне конкуренции, причем не важно сколько там абонентов — можно и сотню тысяч забить без проблем, важно какой трафик — грубо говоря сколько звонков одновременно и тут сервер держит от сотни до тысячи, в зависимости от мощности и тюнинга.
для сетей покрупнее — есть огромное количество решений — каждый из грандов телефонии как минимум может предложить свое, главное в них — распределение нагрузки на кластера, поскольку железо там такое-же.
Имхо лучше говорить «вариация задержки» — так по крайней мере во многих документах. «Случайная задержка» же подразумевает разделение на случайные и стабильные задержки, что не так очевидно и в добавок не совсем верно.
Размер джиттер буфера надо выставлять с учетом реакции сети на аварии, например если время схождения 50мс, то и и размер буфера стоит ставить больше. Также надо смотреть как работает оборудование и какие тайминги для перезапроса потерянных пакетов, которые например на радио по дефолту достаточно большие — до 0.5 с, что для Voip уже слишком много.
Краем уха слышал что до 100мс задержки вполне комфортны, но они учитывают всю задержку, а размер джиттер-буфера прибавляется к средней задержке на сети. На практике не чувствовал проблем при увеличении джиттер буфера до 40-50мс.
Решений привели как-то странно.
для мелких офисов и провайдеров — asterisk вне конкуренции, причем не важно сколько там абонентов — можно и сотню тысяч забить без проблем, важно какой трафик — грубо говоря сколько звонков одновременно и тут сервер держит от сотни до тысячи, в зависимости от мощности и тюнинга.
для сетей покрупнее — есть огромное количество решений — каждый из грандов телефонии как минимум может предложить свое, главное в них — распределение нагрузки на кластера, поскольку железо там такое-же.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы IP-телефонии, базовые принципы, термины и протоколы