Использование ISR4321 CUBE в качестве базового шлюза POTS-SIP
-
mode border-element Эта команда включает функцию Cube в маршрутизаторе, позволяя ему действовать в качестве пограничного контроллера сеансов (Session Border Controller, сокращенно SBC). Как уже неоднократно упоминалось, ваша конфигурация не требует, чтобы маршрутизатор действовал в качестве SBC, поскольку вы
не
маршрутизируете вызовы с одного IP-интерфейса на другой IP-интерфейс. Ваша конфигурация состоит из одного IP-интерфейса и одного TDM-интерфейса.
Для этого не требуется функция Cube
. Я бы посоветовал вам не включать функцию Cube с помощью команды mode border-element, если вам не нужна эта функция. Исходя из предоставленной вами информации, я предполагаю, что IP-адрес 172.16.160.10 не является тем, который вы определили как sip-server. В этом случае вступает в действие встроенная защита от обхода оплаты и блокирует трафик с неизвестного IP-адреса. Это не новость, эта функция присутствует в IOS уже много лет. ![Response Signature]
-
Настройка маршрутизатора — это только начало, но как определяется SIP-соединение с маршрутизатором в Asterisk? Вывод команды «debug ccsip mess» во время попытки Asterisk отправить вызов может предоставить полезную информацию.
-
Вы настраиваете традиционный голосовой шлюз TDM, поскольку один интерфейс основан на POTS. Для этого не требуется функциональность Cube, поскольку он не действует как контроллер границы сеанса (Session Boarder Controller, сокращенно SBC). Этот документ может быть вам полезен.
Объясните маршрутизацию вызовов Cisco IOS и IOS XE
. ![Response Signature]
-
Я знаю, что для этого не требуется функциональность CUBE, подойдет обычный ISR 29xx, и я уже создавал такой на 1760. Но у меня есть ISR. Как гласит шутка, бесплатно — это очень хорошая цена. LOL Кроме того, кто знает, что принесет будущее. Завтра меня может сбить автобус, и новый сотрудник может решить выбросить систему Asterisk (которая ничего не стоит) и заменить ее CUCM за 50 тысяч долларов или около того. Возможно, это маловероятно, но когда вы создаете системы, вы всегда думаете о будущем — к тому же ISR устанавливается в стойку, а для шлюза Grandstream FXO мне пришлось бы потратить еще 50 долларов на полку, lol. Серьезно, у нас в сети есть еще несколько 800-х, которые также служат голосовыми шлюзами 911 на других сайтах, поэтому я предпочитаю иметь дело с особенностями одного поставщика, а не нескольких. Сейчас магистраль в системе Asterisk не отображается как зарегистрированная в ISR, так что это проблема. Я посмотрю документы, на которые вы дали ссылку, и попробую еще кое-что. Рано или поздно я получу рабочую конфигурацию, а затем опубликую ее здесь, на случай, если кто-то еще заинтересуется.
-
Cube — это функция маршрутизаторов Cisco, которая работает на всех моделях после ISR 29xx/39xx. ![Response Signature]

-
Если я правильно понял вашу проблему, у вас есть сервер Asterisk, подключенный к маршрутизатору через SIP, и к маршрутизатору подключена аналоговая линия для приема и совершения вызовов в PSTN, которая подключена к 0/2/1.
Ваша проблема заключается в том, что когда на эту линию POTS поступает вызов извне, он попадает на номер 8672455292 (предполагая, что этот номер находится на PBX). Однако, когда вы пытаетесь позвонить с Asterisk на внешний номер, это не работает. Если ваша проблема соответствует описанной выше, я бы предложил попробовать следующее: Проверьте настройки Asterisk.
Соберите отладочную информацию из шлюза с помощью «Debug Voice ccapi inout» и «Debug csip messages», чтобы увидеть, действительно ли звонки поступают на маршрутизатор и как они обрабатываются. Примечание: я вижу ACL, настроенный на маршрутизаторе; имеет ли это какое-либо влияние на звонки? ![Response Signature]
-
Вау, Роджер, ты вернулся и отредактировал свой первоначальный ответ мне, чтобы ДОБАВИТЬ то, что я сказал позже, о чем я споткнулся? А затем добавил несколько «ударов» по мне, сказав, что мне «несколько раз» говорили об этом. Когда это было? Ах да. ПОСЛЕ твоего первоначального сообщения. Я опубликовал свою полную конфигурацию, и ты мог бы просто ответить «тебе нужно добавить команду «no ip address trusted authenticate» и отправить меня по своим делам. Вместо этого ты отправил мне ссылку на документ, в котором об этом говорится много и только косвенно: в его конфигурации сказано: voice service voip no ip address trusted authenticate но не объясняется значение этого, и не упоминается «ограничение платы за звонки». В документации Cisco, на которую вы дали ссылку, не указано, что включение функции CUBE / SBC помешает устройству работать в качестве шлюза POTS. Фактически, в сложных средах VOIP, где ISR используется в качестве CUBE, вполне вероятно, что если в них задействован шлюз POTS, то в них БУДУТ использоваться порты POTS. В этом и заключается проблема — в документации Cisco не упоминается проблема изменения вывода отладки при использовании этой команды. IP-адреса в публичных сообщениях часто скрывают, изменяя их, это базовая мера безопасности. Ваше предположение верно. Поскольку в исходном сообщении я сказал, что настройка работала для входящих POTS-звонков, то логично, что если это верно, то фактические IP-адреса, которые используются, также верны. У меня есть 1700 с IOS 12. Я только что проверил, и нет, ограничение на звонки за пределы города в нем НЕ существует. Cisco добавила это в IOS 15.1(2)T и, как я полагаю, перенесла в основную версию в ISO 16. Я не называю это «много лет». Что еще более важно, практически все руководства в Интернете по использованию устройства Cisco в качестве голосового шлюза POTS, включая многие сообщения на этом форуме, были написаны
на основе старых версий IOS, таких как 12, в которых этого не было, поэтому в этих руководствах этого нет. Говоря о документации, гораздо лучшей ссылкой, чем ваша, была бы: Cisco Unified Border Element (CUBE) — Cisco Unified Border Element (CUBE) / SIP Trunking Solutions — Cisco " Cisco Unified Border Element для IP PBX сторонних производителей В этих примечаниях по применению подробно описаны конфигурации, которые следует использовать при подключении Cisco Unified Border Element к различным устройствам, не относящимся к Cisco, с использованием протокола SIP или H.323. К сожалению, поскольку все они были написаны ДО ios 15.1(2)T, в них об этом не говорится — за исключением... Подождите минутку — при нажатии на предложенную конфигурацию Zoom для IOS 14.1 появляется — барабанная дробь — конфигурация для ISO 17, в которой ЕСТЬ проблемное утверждение «toll block». Жаль, что я не наткнулся на эту примечание к приложению: Функция предотвращения мошенничества с оплатой в IOS Release 15.1(2)T Но вот оно — конечно, легко найти ссылки на документацию, предупреждающую о проблеме, ПОСЛЕ того, как вы поняли, в чем на самом деле заключается проблема. -
Извините, что вы считаете, что не получили желаемой/ожидаемой помощи. Где я вернулся и добавил ту информацию, о которой вы говорите? Я посмотрел историю изменений двух моих отредактированных ответов и никоим образом не могу увидеть то, что видите вы. ![image.png]
![image.png] Насколько я могу судить, я вернулся и исправил две орфографические ошибки. Документ, которым вы поделились, не применим к вашей конфигурации, поскольку у вас нет SBC, поэтому функциональность Cube не применима, и, на мой взгляд, документ, описывающий настройку Cube, также не применим. Команда, которую вы называете «
проблемным блоком
», имеет вполне оправданное применение. Она предназначена для того, чтобы никто не мог без разрешения отправлять VoIP-трафик через маршрутизатор. Включение этой функции — довольно рискованное дело, и я бы не рекомендовал вам этого делать. voice service voip no ip address trusted authenticate Как вы сказали, эта функция появилась в версии 15.1(2)T, которая, по моим подсчетам, вышла в 2010 году, то есть уже 15 лет назад, что, на мой взгляд, довольно давно. Чтобы получить более подробную информацию о том, как она работает и что можно сделать, чтобы убедиться в ее эффективности, прочитайте эту статью.
Функция предотвращения мошенничества с оплатой в IOS версии 15.1(2)T ![Response Signature]


-
«Эта команда, которую вы называете «
проблемным блокированием»
, имеет вполне оправданное применение. Она предназначена для того, чтобы никто не мог без разрешения отправлять VoIP-трафик через маршрутизатор». Она совершенно ненужна и излишня, поскольку стандартный список доступа на внутреннем или внешнем интерфейсе может быть настроен так, чтобы выполнять ту же функцию. По умолчанию она отключена, так что на самом деле Cisco включила ее для тех, кто не знает достаточно о создании списков доступа и обеспечении безопасности своей сети, чтобы установить базовый ACL. «Включение этой функции — довольно рискованное дело, и я бы не рекомендовал вам этого делать. voice service voip no ip address trusted authenticate " Вы не знаете мою среду, поэтому не можете посоветовать мне, что лучше для моей среды. Cisco тоже не может. Дело в том, что в моей конкретной среде телефонная инфраструктура и инфраструктура VoIP находятся в отдельной виртуальной локальной сети, которая заблокирована от основной сети с помощью ACL на другом оборудовании, поэтому мне не нужно об этом беспокоиться. Но да, в качестве общего совета, лучше установить IP-адреса вовлеченных узлов. Еще лучше установить ACL на интерфейсах и избавиться от этой ерунды. Но все меры безопасности должны применяться ПОСЛЕ того, как все заработает. Правильный подход — сначала построить, а потом применять меры безопасности, а не начинать с применения мер безопасности, а потом пробивать в них дыры, из-за чего все ломается. И да, я знаю об этом конкретном религиозном споре в сфере сетей. Но основная причина выпуска сетевых устройств со всем заблокированным заключается в том, что конечные пользователи — идиоты, которые не понимают сетей и просто используют шаблонные настройки со 100% сетевым оборудованием, предоставленным одним поставщиком. Ну, вы можете взять свои однородные сети и засунуть их туда, где не светит солнце. Я создаю лучшие в своем классе сети, как и многие другие люди. Я приветствую Cisco в этой сфере и в некоторых из их продуктов — они это делают. Другие, ну, скажем так, другие их продукты — это дешевый дерьмовый китайский хлам с переклеенными этикетками, который будет позором для сетевого центра. Большая часть их низкокачественных продуктов Meraki такова. UCM и телекоммуникационное оборудование Cisco — это довольно уникальные вещи. Некоторые из их телекоммуникационных устройств, такие как CP-8865 с программным обеспечением 3PCC, — это произведения искусства. Или ISR4321, с которым я работаю. Другое их телекоммуникационное оборудование... чем меньше об этом говорить, тем лучше. Их телекоммуникационные специалисты, похоже, хотят быть одновременно на двух рынках — с одной стороны, на рынке проприетарного оборудования Cisco, которое продается по смешным ценам для дураков, с другой — на рынке лучших в своем классе решений, где люди собирают решения от разных поставщиков. Очень жаль, что они не могут решить, хотят ли они идти в лоб на лоб с тем, что осталось от Polycom и Sangoma, или же они хотят создавать продукты, которые можно использовать только с «золотыми наручниками». Когда-то они хотели идти в лоб на лоб только с лучшими в своем классе, но сегодня... сегодня я думаю, что они пошли на компромисс со своими принципами во многих вопросах. -
Давайте прекратим эту бессмысленную словесную перепалку, поскольку она ни к чему не приводит. ![Response Signature]

-
Как упомянул
@Roger Kallberg
в вашем случае, нет необходимости активировать Mode Border. ![Response Signature]
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти