LINUX.ORG.RU
ФорумAdmin

Телефония в ынтерпрайзе (E1/2,SIP,PSTN)

 , ,


0

1

ВНИМАНИЕ: речь идет об Ыинтерпрайзе, а не о компаниях с 20-100 сотрудниками.

Собственно, хотелось бы узнать, как в нормальном ынтерпрайзе организована работа с внешней линией (внутренние проблемы, типа voip vlan, qos, wifi (ни дай б-г) тут НЕ будем обсуждать) и самим оператором.
Собственно, для бизнеса телефония часто является весьма критичной, а её отключение (или некорректная работа) может стоить компании убытков или недополученной прибыли (особенно, когда у вас коллцентр на 500 тел).
Соответственно, мне бы хотелось узнать, как организуются внешние каналы связи и сопряжение с ними.
PSTN сразу отпадает - долгий набор, толстенные кабели с кучей жил, шумы, сложность тестирования и обслуживания.
SIP - не знаю, как у спец компаний, но та же mango telecom глючит периодически (то с МГТС не могут дозвониться до них, то с чужой линии звонки начинают проходить, то «у нас проблема при обновлении ПО». Причём это далеко не один раз). Про всякие сипнеты даже говорить не приходится - тут вообще адовая жопа. Плюс может быть проблема со стороны интернет-провайдера у sip-провайдера (у нас то будут резервные каналы, а у них - хрен знает в каком ДЦ стоят сервера и всё ли внутри ДЦ дублируется).
Получается, что E1-4 - это наиболее интересный вариант, т.к. с того конца Ынтерпрайзное оборудование должно быть, у вас гарантированный канал к ним, у них выше - тоже, астериски не обновляют, вообще стараются АТСки не трогать. Только вот вопрос: как узнать, точно ли ваш E1-провайдер даже использует (обязательно резервированную) ATM/SDH/PDH, а тупо подключил E1-карту или E1-SIP-шлюз в обычный комп и дальше подключается через SIP к вышестоящему оператору?

И следующий вопрос: можно ли каким-либо образом заставить оператора давать тебе не только E1, но и SIP, при этом SIP из другого своего ДЦ/офиса? Т.е. если у них упадёт одна АТСка с E1-4, то у нас всё будет через другую их АТСку приходить?

И как можно организовать приём входящих вызовов в случае проблем у оператора? Если что-то типа BGP?

Когда пришел в компанию стоял Панас + Е1 к прову. По мере роста компании, в том числе потребности в телефонии появилась необходимость увеличения как внутренних номеров так и внешних линий. Постепенно в течении 2-х месяцев мигрировал всех с панаса на астер. Купили плату на 4 потока Е1. Пока решали вопрос с прокладкой дополнительных потоков Е1, заключили договор с другим провом на исходящую связь по SIP, да так на них и остались. Качество СИП хорошее - количество каналов неограничено.

Итог: Е1 остался, но по сути на нем висели только московские номера на входящую связь, которые взяли со времен панаса. Все остальные номера (8800 и т.д.) по SIP, вся исходящая связь - SIP, по Е1 пускаю только международную связь от ТОПов (надо же как то его использовать). В сутки по СИП исходящая около 20000 звонков (Исходящий кол центр), входящая 2000. Пускаю с разных географически распределенных мест (офисов в разных городах), по входящей настроил через прова на 2 IP (два сервера, в ДЦ и офисе)

aeX1pu2b
()
Ответ на: комментарий от ktulhu666

Если они - не чернорабочие, то, думаю, да. :)

Трубок раза в два меньше где-то.

А можно перечислить оборудование, количество таймслотов, сколько платили оператору, и что за конвертор (тупо какая-то проприетарная хрень, которая витуху E1 в оптику преобразует, без управления. т.е. медиаконвертор?)?

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

Таймслотов 30 штук.

Да, некий Cronyx, выдал пров. По сути медиаконвертер, две коробки, между ними 2 волокна, из них - E1. Всё тупо :)

Зачем h323 можно подключить к астериску же

Можно, только для этого нужно каждому телефону выдать статический адрес и до *каждого* сделать h323 транк! Это такой феерический бред и геморрой, что я даже заморачиваться с этим не стал.

Остались несколько поликомов дорогих, которые тоже только h323 умеют, с ними скорее всего погеморроюсь и настрою.

Я правильно понимаю, что раньше подключались к этому же провайдеру через E1?

Да, провайдер тот же, вышестоящие у него МТС, Билайн и еще кто-то, подробностей я не знаю.

Если у вас физический линк до прова, и оборудование (и маршруты), которые он использует, одинаковое для E1 и для SIP, то, ИМХО, SIP тут даже лучше, т.к. поддерживает большую безопасность (да и сам канал можно зашифровать IPSec или openvpn), проще отладка и мониторинг, да и на один канал 100мбит можно 1600+ разговоров иметь.

Да, мне тоже больше нравится. Е1 это какой-то тёмный лес, особенно в авае, как его мониторить хрен знает :) Если бы я был телефонистом, а не админом, то может было бы наоборот. А тут обычный IP, всё просто и понятно.

Повезло. Обычно в ОпСоСе или провайдере ТП нужна чтобы отбиться от юзеров. Соединиться с админами там почти нереально.

Да, у нас внутренняя нумерация телефонов общая, так что позвонить напрямую админу провайдерской АТСки не проблема, и это радует. Как-то звонил в билайн - проклял всё...

Можете более подробно рассказать об устройстве сети, стыке с провайдером, оборудовании на стороне провайдера, с какими проблемами столкнулись, изолируете ли Вы внутренние трубки от обычной LAN?

С провайдером L2 стык цыскиными свичами в двух местах, территориально разнесенных (в пределах бизнес-квартала). Резервирование на этом уровне через STP с заниженными таймингами, клал один из интерфейсов - STP сходилось за 5-7 секунд.

Дальше у прова на двух роутера поднят виртуальный IP через какой-то из vrrp/glbp/hsrp и он стоит у нас дефолтным шлюзом.

Ну а дальше у прова уже 2 или 3 аплинка в мир, но к телефонии это не особо относится уже.

У прова АТСки всё те же (что б им не ладно было) Аваи, SIP бордер вроде SBC Acme, хз что за зверь, дела не имел.

Трубки, конечно, в нескольких отдельных вланах сидят, на SVI интерфейсах изолированы акцес-листами от других сетей, видят только астериск (все звонки идут через него т.к. СБ хочет иногда слушать, что говорят люди :)

blind_oracle ★★★★★
()
Ответ на: комментарий от ktulhu666

С чего бы это? Ставим шлюз FXO/FXS-SIP

Так вот. Любого, кто даже предложит поставить компании шлюз с FXO (кроме бэкапов) следует сжигать током низкого напряжения.

И вот почему. Как известно каждому школьнику, телефонный аппарат подсоединен по двум проводам. Гарнитура же, подсоединена по четырем. Поэтому, внутри обычного телефонного аппарата происходит преобразование четырехпроводной линии в двухпроводную. Делается это крайне просто и никаких полупроводниковых компонентов не требуется, но... Но как бы хорошо не шел процесс преобразования, что-бы не применялось, какая-то часть сигнала все-равно уйдет обратно. Это называется «ближнее эхо».

Ближнее эхо — один из классических багов, ставших фичами. Ставшим настолько, что тру-цифровые системы (IP-телефоны, сотовые телефоны) его эмулируют, ибо некомфортно. Они же эмулируют эффект наводок в аналоговой телефонной линии, ибо тоже некомфортно.

Долгие годы, баг не считался багом, пока не появились цифровые системы передачи данных. В широкополосных системах на ближее эхо (когда сигнал из передатчика попадает с собственный же приемник) в принципе пофиг, хотя конечно же, оно крадет полосу, а ее, как известно, мало не бывает. Но в узкополосных системах, тех же самых обычных модемах, ближнее эхо фатально.

Для минимизации эффектов были изобретены схемы эхоподавления. Сначала как система фильтров + ФАПЧ, затем, как и серьезные системы цифровой обработки сигналов. И в настоящий момент, любая система связи просто немыслима без наличия схем эхоподавления, примерно как любой современный автомобиль немыслим без колеса.

А причем же тут FXO? А FXO тут ровно при том, что в его недрах происходит преобразование 4-х проводной линии в двухпроводную. А значит часть сигнала пойдет назад и а) полежит в буферах кодека; б) полежит в джиттер буфере адаптера; в) полежит в сетевом стеке на передающей и принимающей сторонах; г) полежит в буферах принимающей стороны; д) попадет в ухо. Как результат - уже настоящее или как его называют - дальнее - эхо в трубке. FAIL.

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

Вопрос, почему в некоторых типах цифровых систем телефонии, например DECT или проприетарные цифровые телефоны проблем с эхо не стоит, я оставлю не самостоятельную проработку.

Также на самостоятельную проработку оставлю вопрос почему должен использоваться кодек g.711. Хинт, факторов как минимум два.

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

Я с тобой несколько несогласен: я совершал звонки даже в сетях, которые использовали FXO и(!) FXS шлюзы (ТФОП и внутренние трубки - всё аналог) с астериском. И при этом всё работало хорошо и никакого режущего уха эха (но не сказать, что его вообще не было). Думаю, это зависит от ПО и начинки шлюзов. Если говорить про PCI-карточки, то да: таких админов нужно рубить топором, т.к. я ни разу не видел, оно работало без эха. Конечно, чистый SIP лучше, но, ИМХО, Вы слишком критичны.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

FXS шлюзы

С FXS никаких проблем и быть не должно. При преобразовании двухпроводной в четырехпроводную линию эха не возникает (по крайней мере, возникает не больше чем от любого другого телефонного аппарата).

но не сказать, что его вообще не было

Вот-вот. Эходав работает, но...

ИМХО, Вы слишком критичны.

ИМХО, мы обсуждаем ынтырпрайз. А в ынтырпрайзе пионерия и экономия на спичках в конченом счете выходят боком. Кроме того, был бы MGCP и относительно умный шлюз... Может быть было бы и лучше. Но SIP давно уже овладел IP-телефонией...

Насчет SIP vs. E1. Если компания крупная и сидит в своем здании, то однозначно E1. Если мелкая и постоянно переезжает, то SIP. Альтернативщики, кажется, научились готовить SIP, но пока... Нда...

Кстати, хороший философский вопрос: астериск и SIP против брендовой АТС и E1. Сразу ясно, что в первом случае в компании ценят человеческий капитал. Сразу ясно что в первом случае компания не страшится делать ошибки. Сразу ясно, что в первой компании сильна ориентация на результат (иначе бы по кой выбрали столь гибкое решение как Астериск). И т.д. и т.п. Это еще одни дополнительный аспект выбора.

Macil ★★★★★
()
Ответ на: комментарий от ktulhu666

Если говорить про PCI-карточки

Интересно. Как я понимаю, хотя сам никогда не видел, в дигмиумских карточках присутствует аппаратный модуль эхоподавления. Но, сцуко, опциональный.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Но, сцуко, опциональный.

Неконфигурабельный и не адаптивный. Если использовать карточку в сторону АТСки, то он нормально у знакомового не работал, так ещё и busy постоянно не определялось. Кончилось тем, что он в сердцах молотком убил карточку (даже фотку кидал :) ) и купил дешевый шлюз от длинка, с которым у него всё сразу завелось.

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

так ещё и busy постоянно не определялось

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

Macil ★★★★★
()
Ответ на: комментарий от Macil

Подобная хрень есть и в настройках карточки. Только вот АТСка была нестандартная, а бывало ещё, что busy с удаленного конца передавался, поэтому было ещё 2 busy. А шлюзы, видимо, имеют более совершенный алгоритм определния busy, потому что у него без настройки оба busy отрабатывали. :)

ktulhu666 ☆☆☆
() автор топика
Ответ на: комментарий от ktulhu666

А как вопросы резервирования решаются, кстати? В смысле внутри офиса, а не внешние линки.

Не знаю, никогда не сталкивался. Если у про Астериск, то у Дигмиума есть какие-то девайсы с подробным описанием схем включения.

Macil ★★★★★
()
Ответ на: комментарий от ktulhu666

А как вопросы резервирования решаются, кстати?

У меня просто виртуалка в кластере и всё, этого достаточно.

blind_oracle ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.