новые SBC, новый номер от ITSP, старый CUCM, телефон не звонит.
-
Я только что получил 2 новых CSR8000V. Они подключаются к нашему существующему ITSP, но будут обрабатывать новый диапазон номеров (в настоящее время в конфигурации только один номер). В CUCM 2 новых транка используют ту же конфигурацию, что и старая пара транков для старых CSR.
Я создал один новый DN во внутреннем разделе, предоставил ему привилегии национального css-набора и назначил его моему тестовому телефону на моем столе. Пока что все довольно просто. В конфигурации он выглядит так же, как и любой другой из наших 5-значных DN. Входящий вызов поступает на SBC, обрабатывается, передается на субсистемный телефон, но не может найти аппарат, на котором находится DN. На новых SBC происходит некоторая манипуляция с номерами. Входящие вызовы собираются dial peer 1 dial-peer voice 1 voip
description * WANSide INBOUND from ITSP L1 via ISP1 *
translation-profile incoming 100
call-block translation-profile incoming CALL_BLOCK
call-block disconnect-cause incoming call-reject
rtp payload-type comfort-noise 13
session protocol sipv2
incoming called-number <area/>37689
voice-class codec 1
no voice-class sip asserted-id
voice-class sip profiles 10 inbound
dtmf-relay sip-kpml sip-notify rtp-nte
no vad голосовой перевод-профиль 100
переводить вызывающий 100
переводить вызываемый 100 правило перевода голоса 100
правило 10 /^0/ /+44/ После запуска профиля перевода 100 входящий вызов собирается исходящими диалоговыми партнерами 3 или 5 (то же самое, но ориентированное на 2 разных абонента по предпочтению). dial-peer voice 3 voip
description * LANside OUTBOUND to IS-SUB01 *
профиль перевода исходящий PSTN_inbound_44
предпочтение 1
протокол сеанса sipv2
цель сеанса ipv4:10.42.18.72
пункт назначения e164-pattern-map 50
класс голоса sip bind control интерфейс источника GigabitEthernet1
класс голоса sip привязка медиа интерфейс источника GigabitEthernet1
dtmf-ретрансляция sip-kpml sip-уведомление rtp-nte
кодек g711alaw
нет vad класс голоса e164-pattern-map 50
описание * ЯВНОЕ ВХОДНОЕ ОТНОШЕНИЕ ДЛЯ CUCM *
e164 +44<область>37689 профиль перевода голоса PSTN_inbound_44
перевод вызова 10
перевод вызываемого номера 11 правило перевода голоса 10
правило 1 /^+44(.%)/ /80\1/ правило перевода голоса 11
правило 1 /^+44<area/>(37689)/ /\1/ Входящий вызов на внутренний номер 37689 поступает в CUCM, но, несмотря на то, что он настроен как линия на моем телефоне, SIP-сообщение возвращает SIP/2.0 404 Not Found от абонента. Если DN находится на телефоне, почему CUCM не может перенаправить вызов на телефон? Я не могу понять, что я упустил. Я надеялся, что, написав это, я смогу прояснить для себя, что я сделал и, следовательно, что я упустил, но я ничего не могу понять. Номер закреплен за моим телефоном, поэтому я не могу понять, что я здесь упустил. ![NathanMillward_1-1748963090711.png] ![NathanMillward_0-1749198509747.png] ![NathanMillward_2-1748964017290.png] Я собрал данные debug ccsip и debug voip dialpeer inout, но ответ там не найден, потому что эта часть, похоже, работает нормально.
А журнал sdl просто сообщает мне, что номер не найден. ![NathanMillward_3-1748964322426.png] Буду благодарен, если кто-нибудь подскажет, что я упустил.
Спасибо,
Натан.
-
Спасибо всем, кто внес свой вклад. Очень сложно обнаружить проблему в такой конфигурации, особенно на расстоянии, но примерно час назад она была решена. Проблема была в магистрали CUCM. У нас есть 2 «старых» CSR8000v и 2 новых, которые я только что установил. Они предназначены для обработки некоторых определенных номеров от нашего существующего ITSP, чтобы отвести эти вызовы от старых SBC. В конфигурации CUCM я настроил новые магистрали так же, как и для старых SBC, никаких изменений не требовалось. Однако в одном из новых SBC появилась галочка, которую я просто не смог заметить. Другой член команды, посмотрев на это свежим взглядом, заметил ее. На магистрали этой галочки не должно было быть ![NathanMillward_0-1749729559257.png] В пуле устройств для SBC нет CSS-преобразования для чего-либо: ![NathanMillward_1-1749729757345.png] Поэтому я могу только догадываться, не зная, для чего это нужно, что вместо того, чтобы ничего не делать, вызов попадает в другой раздел и не может быть маршрутизирован, но DNA говорит, что он может быть маршрутизирован. В то же время внутренние вызовы на новый номер работали нормально (я не проверял это, пока не получил сообщение от Люка). С удалением этой галочки и работой входящих вызовов я могу продолжить остальную часть того, что мне нужно сделать. Еще раз спасибо.
Натан.
-
Внутренний раздел, в котором находится номер каталога в пространстве поиска вызовов, установленном как используемый для входящего CSS на SIP-транке в CM для SBC? Вы выполнили DNA для транка? Если да, то что он показывает? ![Response Signature]
-
Привет, Роджер, спасибо, что посмотрел. Все DN находятся в разделе «Внутренний». Мы не используем другие разделы для каких-либо номеров. Входящий CSS является «Внутренним» на всех линиях, и раздел «Внутренний» уже находится в этом CSS. Думаю, следующие изображения помогут тебе это понять: старый пример работающего номера 95223 и новый номер 37689. ![NathanMillward_0-1749029015517.png] ![NathanMillward_1-1749029045958.png] ![NathanMillward_3-1749029115041.png] Я провел trunk DNA на старом SBC01 и новом SBC03: вызов на номер 37689 не может поступить через магистраль с SBC01, потому что вызов не отправляется на этот SBC от ITSP, но обработка CUCM остается такой же, как только SBC выполнил свою работу по преобразованию и отправил вызов дальше. Я не думаю, что я что-то упустил, или я ошибаюсь?
Старый SBC01 ![NathanMillward_4-1749030694363.png] Новый SBC03 ![NathanMillward_5-1749030739434.png]
-
Стоит добавить, что я могу звонить. Исходящий вызов с нового DN обрабатывается CUCM должным образом, обрабатывается принимающим диалоговым партнером на новом SBC, проходит через исходящий перевод и отправляется дальше диалоговым партнером, обращенным к ITSP. ![NathanMillward_0-1749034085478.png] Я до сих пор не понял, что я сделал не так в CUCM для входящего вызова.
-
Мне все кажется в порядке. Думаю, вам придется тщательно изучить журналы SDL. Должно быть что-то, что заставляет CM отвечать с кодом 404. ![Response Signature]
-
Я просмотрел журналы SDL и выбрал то, что, на мой взгляд, имеет отношение к делу. Я сделал исходящий звонок. Ответили. Повесили трубку. Позвонил снова и получил сообщение «Вы набрали неправильный номер». В приложенном отрывке из журналов (здесь он не отображается должным образом) есть явная строка !!ERROR!!. Но я не могу понять, в чем проблема. Я удалил DN и начал заново, но безрезультатно. Я просто не могу понять, в чем проблема.
-
Привет, Нейтан, Не мог бы ты активировать отладочное сообщение ccsip на своем SBC и опубликовать результат неудачного вызова? Спасибо С уважением Карло Пожалуйста, оценивайте все полезные сообщения «Чем больше вы помогаете, тем больше вы узнаете»
-
Привет снова, Еще один совет: В отчете «План маршрута» найдите расширение пункта назначения и посмотрите, есть ли еще одна запись в разделе BLANK. Это может быть причиной такого поведения. Сообщите нам, пожалуйста. С уважением Карло Пожалуйста, оценивайте все полезные сообщения «Чем больше вы помогаете, тем больше вы узнаете»
-
Спасибо, Карло. Легко ответить на этот вопрос, прежде чем я соберу отладочные данные SBC. ![NathanMillward_0-1749197570471.png]
-
Второй пост в моей ветке за сегодня. Вот вывод SBC о моем неудачном вызове.
Правильные исходящие dial peers совпадают с выводом debug dialpeer. Пробует оба этих абонентских адреса. Получает 404 для обоих. Затем окончательное сообщение «No outbound dialpeer» (Нет исходящего dialpeer) для ITSP, что, по моему неточному пониманию, означает «Я попробовал 2 пути для ответа, но теперь больше нечего пробовать».
Я буду смотреть на это, пока мой мозг не вытечет из ушей! В какой-то момент будет всемогущее «НЕТ» с падением лицом вниз.Постоянно получал сообщения о недействительном типе файла для отладки, поэтому пришлось возиться, пока не нашел тип файла, который был бы принят, но файл не открывается в TranslatorX. Сохранение файла в формате MS-DOS работает для TranslatorX, но не для загрузки.
Попробовал еще раз, скопировав вывод из консоли в новый txt-файл. Все равно не получается для публикации. ![NathanMillward_0-1749203550843.png]
-
Привет, Хатан, посмотрите на новую конфигурацию магистрали и проверьте, правильно ли вы указали IP-адрес для нового SBC. Не мог бы ты также прислать нам одну из своих трассировок SDL, чтобы мы могли ее проанализировать? Большое спасибо С уважением Карло Пожалуйста, оценивайте все полезные сообщения «Чем больше вы помогаете, тем больше вы узнаете»
-
Извините за задержку с ответом. Конфигурация магистрали CUCM ![NathanMillward_0-1749560075666.png] Конфигурация магистрали SBC03: интерфейс GigabitEthernet1
описание LANSide SBC03 к CUCM
ip адрес 10.42.18.104 255.255.255.192
ip nat outside
negotiation auto
no mop enabled
no mop sysid Набор номера на субсеть dial-peer voice 3 voip
description * LANside OUTBOUND to IS-SUB01 *
translation-profile outgoing PSTN_inbound_44
preference 1
session protocol sipv2
session target ipv4:10.42.18.72
destination e164-pattern-map 50
voice-class sip bind control source-interface GigabitEthernet1
voice-class sip bind media source-interface GigabitEthernet1
dtmf-relay sip-kpml sip-notify rtp-nte
codec g711alaw
no vad
Профиль перевода voice translation-profile PSTN_inbound_44
translate calling 10
translate called 11 Правила перевода правило перевода голоса 10
правило 1 /^+44(.%)/ /80\1/ правило
перевода голоса 11
правило 2 /^+4415245(6798.)/ /\1/
правило 3 /^+4415242(37689)/ /\1/ Карта шаблонов класс голоса e164-pattern-map 50
описание * ЯВНАЯ ВХОДНАЯ КАРТА для CUCM *
e164 +441524237689 Звонок доходит до субсистемы, но затем появляется небольшая проблема в виде сообщения «404 Not Found / Unallocated Number» (404 Не найдено / Неприсвоенный номер), хотя у меня есть зарегистрированный клиент Jabber, ожидающий звонка (то же самое происходит, если я ввожу DN на стационарном телефоне). ![NathanMillward_1-1749560340154.png] Я не нахожу никаких подсказок от cway, только то, что я уже знаю. ![NathanMillward_2-1749561329632.png] Прилагаю запрошенный SDL.
-
Привет, Нейтан, Спасибо за ответ. Пожалуйста, войдите в Pub через ssh, выполните команду utils dbreplication runtimestate и опубликуйте результат. Также попробуй направить твой dialpeer 3 на CUCM PUB и посмотри, работает ли это. Еще раз спасибо С уважением Карло Пожалуйста, оценивайте все полезные сообщения «Чем больше вы помогаете, тем больше вы узнаете»
-
Добрый вечер, Карло (ну, для тебя, наверное, уже утро).
dbrepl выглядит неплохо. ![NathanMillward_0-1749582252231.png]
Dial peer 3 нацелен на издателя (10.42.18.71) — нераспределенный номер.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти