[Гoсть]

Нет, коллега, я уже давно отмучался.

А сюда зашел чисто случайно, увидев знакомое слово telematic.

К сожалению, не могу пройти мимо всякого рода самородков, так и тянет поощерить за бурную мозговую деятельность, направленную главным образом в унитаз :)

[Andrei]

 

Ну не всё так плохо, достаточно создать такие условия для шлюзов, чтобы у них не оставалось другой возможности, кроме общения через медиасервер. Это не так уж сложно и реализуемо несколькими методами. Тогда и "и волки будут сыты и овцы целки", т.е. и RFC будут соблюдены и гражданин майор в щастье.

И каким образом? Нарезать шлюзам мелкие подсеточки по 4 адреса? - это сколько ж интерфейсов на софтсвиче получится? Или гонять трафик через L3 железку с ip unnumbered?

[Deac]

Билят! Еще один рам-скан, сорри - мозго-клюй!

(это я про рязанского самородка с h323 в том месте куда едят).

НЕТУ БОЛЬШЕ H323! ТРУП ЭТО. Не откапывайте стюардесс, ребята. Они уже на енто дело не годятся совсем ведь.. :)

Вот ведь, лишь бы "отметиться в теме", нет бы почитать пару-тройку предыдущих страниц. :)

Никто не пытается гальванизировать H323, это был чисто риторический вопрос.

 

А вы RFC точно не по диагонали читали? Найдёте то место, где написано, что нам запрещено удалять Via и модифицировать другие заголовки?

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

Так сильно как в SIP, RFC пожалуй нигде не игнорируются.

 

И каким образом? Нарезать шлюзам мелкие подсеточки по 4 адреса? - это сколько ж интерфейсов на софтсвиче получиться? Или гонять трафик через L3 железку с ip unnumbered?

Именно так.

На софсвитче в любом случае получится 1(ОДИН) интерфейс и 1(ОДИН) IP адрес, это не его задача.

 

Первый способ - костыльный, но бронебойный:

На маршрутизаторе ядра сети - 1(ОДИН) сетевой интерфейс и туева хуча алиасов, что для любого современного оборудования не является проблемой.

Проблемой здесь является сильная затруднённость DHCP, но с этим можно мириться.

 

Второй способ "VLAN per VoIP_GW with ip unnum" - правильный, но требует дополнительных затрат, не таких уж значительных и не накладывает никаких ограничений.

 

Есть ещё третий способ - VPN. PPPoE или PPtP.

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

В случае с PPPoE - никаких минусов не обнаружено.

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

Хотя есть и приятные исключения - AudioCodes или AddPac, например.

[ram_scan]

НЕТУ БОЛЬШЕ H323! ТРУП ЭТО. Не откапывайте стюардесс, ребята. Они уже на енто дело не годятся совсем ведь.. :)

 

А чо, через SIP по человечьи в рамках стандарта хотя-бы q931 коды завершения передавать научились ? Или хантинг все-таки по человечески сделали, без трахотни с rr, которую кстати поддерживать необязательно ? Низнал, низнал. Пойду йаду выпью.

 

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

[telematic]

Вы еще SS7 в пользу сипа закопайте.

 

Так уже закапывают. SIP-T называется.

[ram_scan]

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

Так сильно как в SIP, RFC пожалуй нигде не игнорируются.

 

Феерические глупости. Вы точно хотя бы один RFC читали ? Дальше первой страницы ? Как раз там разжевываются термины may, should, must и им подобные.

 

Игнорирование RFC в реализации SIP стеков вызвана врожденной убогостью протокола как явления. Это фактически система взаимоисключающих параграфов, выполненная в виде забора из трех кривых досок, которые прибиты к слову "х.й", сбоку привязана калитка на проволоке, а чтобы все это не падало сгорожена система веревочек и подпорочек, причем забор падает если все веревочки привязать и все подпорочки поставить. А если вспомнить еще что калитки когда забор строился вообще не было задумано то совсем чудесно становится.

[ram_scan]

Вы еще SS7 в пользу сипа закопайте.

 

Так уже закапывают. SIP-T называется.

 

SIP-T - обычный туннель. Тупой до безобразия. Принципиально не отличающийся ни от TDMoE ни от TDMoIP технологии. Только в отличие от TDMoIP оно непрозрачное, а в отличие от h323 этим костылем можно пользоваться только точка-точка. Причем если добавить в него немножко интеллекта, то получится велосипед в виде второго h323. Только в h323 в отличие от сипа при его реализации ASN парсер хоть в виде грамматики по человечьи описать можно.

[leveler]

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

Так сильно как в SIP, RFC пожалуй нигде не игнорируются.

Спасибо, поржал. )

 

Так уже закапывают. SIP-T называется.

Телематик, вы SIP-T с SIP Trunking не путаете? )

[telematic]

Телематик, вы SIP-T с SIP Trunking не путаете? )

Видимо, путаю :-)

Ну вы уж простите старого директора, я всё больше по вершкам :-)

[leveler]

Да я понимаю, должность не та. Всё нормально. )

 

SIP-T - это когда SS7 оборачивают в SIP для транзитной передачи через IP сеть, например.

 

А когда между софтсвичами гуляет просто SIP, его величают SIP Trunking! Некоторые (не будем говорить кто, хотя это Протей) даже умудряются в SIP добавить свой собственный заголовок Category для передачи категории абонента. )

 

Deac, а вы знаете, что такое B2BUA?

[telematic]

Некоторые (не будем говорить кто, хотя это Протей) даже умудряются в SIP добавить свой собственный заголовок Category для передачи категории абонента. )

 

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

[Mikler]

Вообще на операторских шлюзах должен быть LI, дальше никакой великой проблемы нет. SSW соединился с шлюзом СОРМ, он в его сторону должен передовать состояние наблюдаемых абонентов. Идет соединение, СОРМ шлюз сказал абонентскому по SNMP, а форкни ка мне TX RX, абонентский шлюзик форкает. В идеале свичи должны тоже поддерживать возможность форкнуть помеченные пакеты, шлюз отслеживает где ближе чтобы не создавать нагрузку на сеть и форкает с ближайшего к себе узла. Вас почитаешь думаешь, знаете толк в извращениях.

[Deac]

Феерические глупости. Вы точно хотя бы один RFC читали ? Дальше первой страницы ? Как раз там разжевываются термины may, should, must и им подобные.

Пытался читать RFC 2543 и RFC 3261, не нашёл там указаний(SHOULD, MUST) на то как должны ходить медиапотоки, одни рекомендации. Если что пропустил - прошу ткнуть пальцем. На всякий случай напомню - SDP это отдельный протокол и к SIP-у имеет отношение такое же как и RTP/TCP/UDP/пр., т.е. "оно" его использует.

Ваше видение SIP, как такового, коментировать не буду. :)

 

Спасибо, поржал. )

На здоровье! :)

 

Deac, а вы знаете, что такое B2BUA?

Да нет конечно же! Просветите?

 

Вообще на операторских шлюзах должен быть LI

Операторский, это какой?

Идет соединение, СОРМ шлюз сказал абонентскому по SNMP, а форкни ка мне TX RX, абонентский шлюзик форкает.

А не могли бы подсказать соответствующий OID, например для AudioCodes: http://www.snmplink.org/cgi-bin/nd/m/Ent/A/AudioCodes/AudioCodes/

[Mikler]

1. Операторский, это какой?

 

2. А не могли бы подсказать соответствующий OID, например для AudioCodes: http://www.snmplink.org/cgi-bin/nd/m/Ent/A/AudioCodes/AudioCodes/

1. У Сиско системс есть. У Элтекс на некоторых шлюзах, я участвовал в реализации этих фич. А всё остальное уже к другим вендорам.

2. А не моглибы вы обратится в AudioCodes.

[Deac]

1. У Сиско системс есть. У Элтекс на некоторых шлюзах, я участвовал в реализации этих фич. А всё остальное уже к другим вендорам.

Из чего заключаю, "операторский" - такой, кот. Вы полагаете как "операторского класса".

И сеть на PAP2T(коих многие тыщи стоит по России) пролетает, т.к. в нём вообще нет SNMP.

 

2. А не моглибы вы обратится в AudioCodes.

Мог бы, но по Вашему описанию полагал что имеется опыт построения подобной схемы.

[ram_scan]

Пытался читать RFC 2543 и RFC 3261, не нашёл там указаний(SHOULD, MUST) на то как должны ходить медиапотоки, одни рекомендации. Если что пропустил - прошу ткнуть пальцем. На всякий случай напомню - SDP это отдельный протокол и к SIP-у имеет отношение такое же как и RTP/TCP/UDP/пр., т.е. "оно" его использует.

Ваше видение SIP, как такового, коментировать не буду. :)

 

 

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

 

Специально открыл RFC 3261. Для вас персонально цитирую:

 

3 Terminology

 

In this document, the key words "MUST", "MUST NOT", "REQUIRED",

"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT

RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as

described in BCP 14, RFC 2119 [2] and indicate requirement levels for

compliant SIP implementations.

[leveler]

Рам, не корми тролля, а то тему замусорим совсем.

[Deac]

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

Во всех моих предыдущих постах, имеющих отношение к SIP, речь шла именно о медиапотоках и на рекомендации о них(указаний то нет) можно класть "всё что угодно".

 

Так вот, идите RFC до просветления перечитывать, потом приходите обратно позориться.

Пришёл позориться.

Признаю, что в контексте указанной ram_scan цитаты, мои слова могут и должны быть истолкованы как непонимание принципов RFC.

Mea culpa, прочёл Confiteor RFC 2119 пять раз.

Единственно, оч. удивило, что он ссылается сам на себя.

[Aleck_K]

telematic, спасибо за ответы. Для себя понял, что нужно еще раз внимательно посмотреть на Броадворкс, за два года многое изменилось. В частности, раньше интеграторы не хотели даже говорить о внедрении решения меньше 10К портов, да и с железом требования были очень жесткие. В принципе, лимит на 10к портов не смущает, главный минус для меня был в том, что Броадсофт жестко навязывает бизнес-схемы продаж. То есть фактически нельзя предложить клиенту тот набор фич и ДВО, какой ему нужен, можно только давать пакетами, сформированными Броадсофтом. Содержимое пакетов в рамках лицензии менять было нельзя. В результате у меня получалось, что наше текущее "стандартное" предложение (3 телефона + автоматический факс + автоинформатор на входящих вызовах) можно реализовать только самым дорогим пакетом лицензий, в котором стоимость за порт превышает разумную и конкурентную стоимость. Кроме того, мы вынуждены подключать "зоопарк" CPE-ек и ограничиться списком совместимости не можем. Единственное, что мы можем потребовать от клиентского оборудования, т.е. то, что работает практически у всех, это базовый вызов и DTMF по RFC2833. Все управление ДВО со стороны клиента осуществляется по DTMF. Броадсофт это, вроде, поддерживает фичей Incall service activation, но она доступна только в самом дорогом пакете. Было бы очень интересно посмотреть, какие фичи и какими пакетами вы будете предлагать своим абонентам.

Изменено 1 ноября, 2011 пользователем Aleck_K

[ASV]

telematic, спасибо за ответы. Для себя понял, что нужно еще раз внимательно посмотреть на Броадворкс, за два года многое изменилось. В частности, раньше интеграторы не хотели даже говорить о внедрении решения меньше 10К портов, да и с железом требования были очень жесткие. В принципе, лимит на 10к портов не смущает, главный минус для меня был в том, что Броадсофт жестко навязывает бизнес-схемы продаж. То есть фактически нельзя предложить клиенту тот набор фич и ДВО, какой ему нужен, можно только давать пакетами, сформированными Броадсофтом. Содержимое пакетов в рамках лицензии менять было нельзя. В результате у меня получалось, что наше текущее "стандартное" предложение (3 телефона + автоматический факс + автоинформатор на входящих вызовах) можно реализовать только самым дорогим пакетом лицензий, в котором стоимость за порт превышает разумную и конкурентную стоимость. Кроме того, мы вынуждены подключать "зоопарк" CPE-ек и ограничиться списком совместимости не можем. Единственное, что мы можем потребовать от клиентского оборудования, т.е. то, что работает практически у всех, это базовый вызов и DTMF по RFC2833. Все управление ДВО со стороны клиента осуществляется по DTMF. Броадсофт это, вроде, поддерживает фичей Incall service activation, но она доступна только в самом дорогом пакете. Было бы очень интересно посмотреть, какие фичи и какими пакетами вы будете предлагать своим абонентам.

 

 

Как обстоят дела сейчас:

 

1. Собственно требования вендора именно в 10000 абонентов я не помню. Году в 2006м-7м было 5000 абонентов, потом и оно смягчилось. Сейчас есть некий "порог" - сумма начиная с которой BSOFT считает для себя интересным заниматься проектом. Т.е. предварительно спецификация согласовывается с вендором и он "дает добро" на проект.

 

2. По железу - возможность установки на 2 сервера под WM появилась как раз год-полтора назад, когда вышел 16й релиз.

 

3. Фичи - покупаются пакетами, клиенту же вы можете формировать какие угодно пакеты. Если я не прав - пусть меня поправят.

 

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

 

5. Сейчас Фича - Incall service activation действительно включена в самый "богатый" пакет - Premium Enterprise. НО! она доступна и в рамках еще двух пакетов, которые являются "апгрейдом" для "основных пакетов". Это собственно пакет - "PERSONAL MOBILITY package" для пакетов типа "Enterprise" и "Consumer Mobility" Pack - для пакетов типа "Residential".

[telematic]

3. Фичи - покупаются пакетами, клиенту же вы можете формировать какие угодно пакеты. Если я не прав - пусть меня поправят.

 

Всё правда. В интерфейсе два окошечка, в левом набор ДВО, в правом - ДВО, присвоенные абоненту. Из левого в правое и наоборот стрелочками можно ДВО по одному гонять.

 

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

 

Сейчас ставим Элтексовские шлюзы. На тесте вроде взлетели. Будем включать живых абонентов.

[Gimli_r]

Все управление ДВО со стороны клиента осуществляется по DTMF.

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

Так вот, что касается преднастроенного - его можно включать/выключать/настраивать либо с телефонного аппарата, используя старкоды и донабор, а можно управлять всеми ими через web интрефейс и это намного удобнее :)

Активируемые во время звонка сервисы страдают от глючности среднестатистических noname CPEшек обычно сильнее, но и на этот случай есть обходные маневры: можно перенести обработку In-Call ДВО по максимуму на BroadWorks, заставив CPE только передавать события hookflash и уже на свиче отрабатывать всякие трансферы, а что нет возможности отработать с помощью hookflash - отрабатывать опять таки через web клиента CommPilot Callmanager, это такое приложение для браузера - которое позволяет пользователю управлять обработкой вызовов в реалтайме.

[ram_scan]

можно перенести обработку In-Call ДВО по максимуму на BroadWorks, заставив CPE только передавать события hookflash и уже на свиче отрабатывать всякие трансферы, а что нет возможности отработать с помощью hookflash - отрабатывать опять таки через web клиента CommPilot Callmanager, это такое приложение для браузера - которое позволяет пользователю управлять обработкой вызовов в реалтайме.

 

Вот еще бы в СИПе была предусмотрена передача хукфлэш, было бы все более-менее решабельно... А так необходимо городить систему костылей (замену хукфлэша) для того чтобы заменить другой костыль (обработку ДВО на ЦПЕ). "Эффективных манагеров" продвинувших в свое время сип в телефонию убивать в зародыше надо за такое. Чем MGCP плохо было ?

[Gimli_r]

Вот еще бы в СИПе была предусмотрена передача хукфлэш, было бы все более-менее решабельно... А так необходимо городить систему костылей (замену хукфлэша) для того чтобы заменить другой костыль (обработку ДВО на ЦПЕ). "Эффективных манагеров" продвинувших в свое время сип в телефонию убивать в зародыше надо за такое. Чем MGCP плохо было ?

Господа-товарищи, ну довольно уже "вбросов"! Сколько можно. Есть тема выбора свича, есть обсуждение конкретных реализаций, в cлучае с BW говорим про SIP. Трагедию неумолимости прогресса переживайте уже внутри себя, чесслово!

 

Так вот, если возвращаться к конкретной реализации передачи hookflash - BroadWorks пользует SIP INFO вот примерно такого вида (входящие от CPE):

INFO sip:10.0.1.141:5060 SIP/2.0 
Content-Type:application/broadsoft 
Call-ID:BW1518050266020403014-96731439222646@10.0.1.141 
CSeq:1 INFO 
From:"3010050303 
NSS"<sip:3010050303@10.0.1.141;User=phone>;tag=00000000000060E3000C3DB2 
To:"3010050301 NSS"<sip:0301@10.0.1.141;User=phone>;tag=931769837-1049314685266 
Via:SIP/2.0/UDP 10.254.25.1:23072 
User-Agent:AmethystUAv0.0.0 
Supported:100rel,timer 
Max-Forwards:10 
Content-Length:17 

event flashhook

 

Предвосхищая вопросы ненавистников SIP - да, это проприетарное расширение SIP метода INFO. Заголовок Content-Type=application/broadsoft, в теле сообщения могут быть

event <event name>

play tone <tone name>

stop <tone name>

и некоторые другие, документация существует и она исчерпывающая.

[Aleck_K]

Нет и еще раз нет.

Вот в этом-то и состоит главная печаль, что управление incall сервисами штатно не реализуется через ДТМФ :( Хук-флэш - не (всегда) правильное решение. Во-первых, работает он только на ограниченном списке устройств (BSOFT-compatible) ибо проприетарная реализация. Да, этот список хорош, все уважаемые вендоры там есть и оператор может выбрать CPE для своих клиентов на любой вкус. BTW, уверен, что и елтекс скоро появится в списке. Но даже с этим списком (шлюзов), флеш должен еще поддерживаться аналоговым телефоном, подключенным к шлюзу. Более того, аналоговый телефон и шлюз должны быть совместимы по реализации флеша, а это далеко не всегда так. Во-вторых, без управления через ДТМФ теряется много очень интересных решений. Например, подключение внешнего (мобильного) номера в качестве добавочного виртуальной станции для реализации услуги "мобильный секретарь", при которой внутренний вызов экстеншна секретаря терминируется на внешний номер, причем при терминации сохраняется возможность делать, например, переводы или парковки. Услуга follow-me тоже получается ущербной, т.к. после ухода вызова за пределы платформы управлять сервисами нельзя. Еще пример услуги, которую не сделать без ДТМФ - запись разговора по требованию, когда во время разговора можно включить запись. Таких примеров из практики можно набрать очень много.

Всё правда. В интерфейсе два окошечка, в левом набор ДВО, в правом - ДВО, присвоенные абоненту. Из левого в правое и наоборот стрелочками можно ДВО по одному гонять.

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

Господа-товарищи, ну довольно уже "вбросов"!

+1! Предлагаю создать отдельную тему "SIP - говно, XYZ - рулит" специально для подобного холивара

Изменено 3 ноября, 2011 пользователем Aleck_K