отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
1237
Просмотры
10
Полезный материал
14
Ответы
CSCO10603512
Beginner

Debug ISDN PRI

Добрый день.

Подскажите, пожалуйста, существует ли возможность на станции BE 3000 посмотреть какие номера передаются на городскую АТС в E1 потоке?

2 УТВЕРЖДЕН. РЕШЕН.

Утвержденные решения
Pavel Teplov
Enthusiast

Да, для этого вы можете включить режим откладки и после посмотреть журнал.

Просмотреть решение в исходном сообщении

Журнал надо распаковать подходящим архиватором(например, 7zip достаточно всеядный), после чего отдельные файлы можно просмотреть в любом текстовом редакторе/просмотрщике, понимающем LF в качестве разделителя строк(большинство браузеров, WordPad и другие).

Просмотреть решение в исходном сообщении

14 ОТВЕТ 14
Pavel Teplov
Enthusiast

Да, для этого вы можете включить режим откладки и после посмотреть журнал.

Павел, спасибо за оперативный ответ

Журнал вытянул, теперь встает вопрос чем можно просмотреть его содержание?

Журнал надо распаковать подходящим архиватором(например, 7zip достаточно всеядный), после чего отдельные файлы можно просмотреть в любом текстовом редакторе/просмотрщике, понимающем LF в качестве разделителя строк(большинство браузеров, WordPad и другие).

Василий, спасибо!

Теперь мне стало понятно в чем проблема.

Звонок на межгородный номер уходит в следующем виде:

2013/01/22 07:52:48.481|CC|SETUP|32925780|32925781|121277|89221234567|89221234567

Где 121277 городской номер выделенный оператором для нас.

А вызов на городской номер в таком виде:

2013/01/22 07:52:31.887|CC|SETUP|32925777|32925778|6666|83452123456|83452123456


Где 6666 внутренний номер абонента. В таком виде оператор работать категорически отказывается.

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

Если звонок производился с той же линии и  External Caller ID у пользовательской линии такой, как требуется, то единственное, что можно проверить - классификацию вызовов в номерном плане (OnNet = внутри компании, OffNet = выход в город). Для городских(любого типа) номеров должно стоять OffNet. Других настроек, влияющих на формирование номера звонящего, я не вижу.

Картинка получилась следующая.

При соединении с ТСОП номер звонящего абонента устанавливается соответствующий номеру локальной линии когда номер вызываемого абонента формируется в "шаблоне схем набора номера". Т.е. абонент набирает "9"+ 6 цифр (а зачем набирать 11, если в городе 6-значная схема набора?), а мы с помощью шаблона убираем 9 (код выхода в город) и добавляем 8+код города и в разделе "обработка вызова" устанавливаем опцию "маршрутизировать вызов".

Обойти это можно если в том же шаблоне не маршрутизировать вызов, а "транслировать вызов".

Все правильно сделали.

Я только не понял вашу фразу "Обойти это можно если..."

Зачем "обходить"?

Чуть побробнее про "обойти" и оставшуюся проблему.

Станции явно не хватает инструмента работы с номером звонящего.

У PRI транка поведение следующее:

1. Если пытаться манипулировать с номером вызываемого абонента и ставить "галку" "маршрутизировать вызов", то в транк улетает "номер линии" в качестве номера звонящего. В моем случае это внутренние дополнительные добавочные номера. Все бы хорошо, но оператор такие вызовы сбрасывает - требует городской номер.

2. Если манипулировать с номером вызываемого абонента и ставить "галку" "транслировать вызов", то в транк улетает "Идентификатор внешнего вызывающего абонента" (т.е. городской номер) в качестве номера звонящего. В этом случае вызовы через оператора начинают работать, НО жизнь подбрасывает новую задачку:

У этой же станции есть SIP транк к другой корп. станции - CUCM. Так вот, вполне логично, чтобы при звонках через SIP транк в качестве CLID получать как раз номер линии, а на практике прилетает все тот же городской номер... Ну, думаю, "как обойти" теперь уже понятно из опыта с PRI транком и...

У SIP транка поведение принципиально отличается:

Вне зависимости от манипуляций в "шаблоне схем набора номера" в качестве АОНа передается "идентификатор внешнего вызывающего абонента".

В сухом остатке: либо работает город, тогда при звонках между двумя узлами корпоративной сети в качестве АОН BE3000 отдает городской номер, либо наоборот - внутри корп. сети корректно работает АОН, но не работает город.

Есть ли способ "выкрутиться"?

P.S. Отследить по логам что передается по SIP транку не получается. Т.е. в логах один номер, в дампах, отловленных по дороге другой

Единственный реалистичный вариант исправить поведение станции - открыть запрос в центре технической поддержки(TAC).

SIP-транк считается подключением к городской сети(как, впрочем, и все остальные подключения). С этой точки зрения зафиксированное поведение на транке усовно-правильное(а зафиксированное поведение на E1 - условно-ошибочное). В полном CUCM это поведение регулируется настройками на разных этапах маршрутизации. В ближайшее время буду обновлять свой прибор до 8.6.5 - возможно там уже эти возможности могли появиться в интерфейсе BE-3000.

Модель номерного построена исходя из предположения, что у всех абонентов есть прямой входящий номер и, соответственно, его внешнюю версию отправляют как CLID на внешние АТС.

P.S. логов много, в разных файлах собирается информация разной детальности и с разных этапов жизненного цикла CUCM.

Василий, спасибо.

Буду благодарен, если вы выложите в эту ветку возможности 8.6.5 с точки зрения манипуляции номером звонящего.

Вот несколько из того, что может появится (пока нет официального выпуска 8.6.5, то нужно понимать, что это может измениться)

  • Автоматическая регистрация телефонов, через голосовое меню
  • мини CallCenter: очередь звонков на группу операторов, свой звуковой файл для информирования во время ожидания в очереди, отображение статуса очереди на экране IP-телефона
  • Технология выживаемости удаленного офиса (SRST)
  • Интеграция с облачной  CRM системой salesforce.com

Также посмотрите документы, которые я недавно опубликовал о поддержке SIP-транков между несколькими BE3000 или BE3000 и Cisco UCM/BE6000

Ждем аналогичный документ по настройке SIP транка между BE 3000 и CUCME :)

не будет.... акцент на станции на базе ПО на сервере, то есть на базе "большого" Callmanager.

Callmanager express - это ПО на базе ISR. Для этой ниши будет только BE3000 развиваться.

С точки зрения настройки BE3000 - все то же самое, что и для стыковки с CUCM или с BEx000. Отличия будут только на стороне CME, поскольку он настраивается по-другому. А если в центре будет CUCM или с BEx000 и CME как один из филиалов, то все сводится к сценарию BE3000 и Cisco UCM/BE6000