Ошибка исходящего вызова через магистраль sip

Модератор: april22

Вернуться в Конфигурация и настройка Asterisk

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9

Проблему удалось решить? У меня такая же проблема!

Callerid подставляете? Extensions.conf приведите.

fromuser должен быть таким же, как логин в register
у вас астер шлет звонок от левого пользователя 1001 и провайдер законно вас отшивает. Обычно это правится корректным фромюзер. Вы точно рестартовали сип после внесения и сохранения изменений? 😉

Если вы столкнулись с невозможностью совершить исходящий звонок, прежде всего необходимо понять: сбой происходит на уровне вашей АТС 3CX, либо на уровне провайдера. Для того, чтобы это понять, совершите тестовый исходящий вызов (который будет неуспешным). Затем, обновите главную страницу веб-панели администрирования 3CX и в самом низу страницы, в Журнале событий сервера, проверьте, присутствует ли запись вида:

Call or Registration to 71234567890@******* has failed. Y.Y.Y.Y replied: 403 Auth Failed; from IP:Y.Y.Y.Y:5060

В указанном примере: 71234567890 – набранный вами номер, ******* – произвольное обозначение внешней линии, Y.Y.Y.Y – ip-адрес провайдера, через который должен был осуществляться этот вызов.

Обращаем внимание, в журнале событий 3CX всегда использует ip-адреса, даже если в настройках транка указано доменное имя SIP-сервера. Чтоб правильно понять запись в журнале событий, выясните ip-адрес вашего провайдера. Например, командой ping в командной строке Windows.

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

Если же запись с ошибкой, именно с ошибкой от провайдера, в журнале событий присутствует, то делаем вывод – АТС 3CX “выпустила” вызов наружу и отправила его провайдеру, провайдер ответил ошибкой, в связи с чем исходящий звонок не удался. Ниже приводим вероятные причины такого поведения провайдера:

• На вашем лицевом счете закончились деньги. Зайдите в личный кабинет провайдера и проверьте состояние счета. При необходимости, пополните счет.
• По какой-то причине SIP-транк 3CX не смог зарегистрироваться у провайдера, поэтому исходящие звонки через него не проходят. Зайдите в раздел “SIP транки” и обратите внимание, помечен ли нужный транк зеленым кружком. Если кружок красный, значит 3CX не может зарегистрировать SIP-транк у провайдера. Вероятные причины – проблемы с интернет соединением на вашем сервере 3CX, либо какой-то сбой у провайдера. В редких случаях ip-адрес провайдера может попасть в черный список 3CX. Проверьте состояние черного списка ip-адресов и удалите ip-адрес провайдера, если он там есть. Подробнее о черном списке – здесь. Если регистрация отсутствует, попробуйте выделить транк и нажать кнопку “Обновить регистрацию” в списке SIP-транков. После чего обновите страницу и проверьте состояние регистрации. Регистрацию у провайдера стоит проверять при условии, если транк использует авторизацию по логину и паролю. Если используется авторизация по ip-адресу, тогда нет смысла смотреть состояние регистрации – такой SIP-транк всегда будет выглядеть зарегистрированным, даже если оператор (по какой-либо причине) с вашей АТС не принимает ни одной SIP-команды.
• Ваше исходящее правило разрешает звонки через провайдера, но формат набираемого номера неверен. У каждого провайдера свой “стандарт” набираемого номера, у одного номер должен начинаться с “8”, у другого —  с “7”, у третьего – еще как-нибудь. Правильный формат набираемого номера лучше всего уточнить у провайдера и подкорректировать исходящее правило для приведения формата к нужному виду.
• Провайдер может отбивать исходящие звонки по причине того, что SIP-заголовки в сообщениях INVITE, которые генерирует 3CX при исходящем звонке, не соответствуют формату, который ожидает провайдер. В данном случае потребуется тонкая настройка SIP-транка. В свойствах любого SIP-транка во вкладке Исходящие параметры можно подстраивать SIP-заголовки, но сперва нужно получить от провайдера информацию, в каком заголовке и что именно требуется поменять. В таких случаях обычно делают захват трафика при совершении проблемного звонка, затем этот захват передают оператору, и он уже, анализируя его, сообщает вам, что не так, и что нужно поправить.
• Провайдер может отбивать исходящие звонки по причине того, что ваш исходящий номер, который передается в транк, некорректен. Проверьте значения, указанные в свойствах пользователя (добавочного номера) в поле “Исходящий Caller ID”, а также значения полей SIP-транка “Основной номер транка” (вкладка Основные в свойствах транка) и “Caller ID по умолчанию” (вкладка Caller ID в свойствах транка).

Задать свой вопрос

Отладка неполадок вызовов

Введение Проблемы с исходящими вызовами. Проблемы с входящими вызовами. Введение В работе с астериском, зачастую системные администраторы сталкиваются с вопросами: «Не могу дозвониться на номер 4951112233» или «У меня вызовы не работают» или «Почему мне не приходят вызовы, у меня телефон зарегистрирован». Для этого надо подключаться к консоли и смотреть лог звонка. Это может затрагивать […]

1. Введение
2. Проблемы с исходящими вызовами.
3. Проблемы с входящими вызовами.

Введение

В работе с астериском, зачастую системные администраторы
сталкиваются с вопросами: «Не могу дозвониться на номер 4951112233» или «У меня
вызовы не работают» или «Почему мне не приходят вызовы, у меня телефон
зарегистрирован». Для этого надо подключаться к консоли и смотреть лог звонка.
Это может затрагивать как исходящие правила набора, так и входящие. В этой
статье рассмотрим основные неполадки диалплана, также захватим моменты, если
вызов все таки уходит к оператору связи.

Проблемы
с исходящими вызовами

В данном блоке будем рассматривать возможные неполадки при
исходящих вызовах. Здесь можно выделить следующие проблемы:

• Не
  верный контекст вызова
• Не
  совпадение с правилами набора
• Ошибки
  кастомного диалплана

не
верный контекст

Теперь разберем каждый из разделов по порядку. Первым в
списке стоит не верный контекст. Под этим подразумевается, контекст, в
который включен внутренний номер. При попытке вызова вы услышите короткие
гудки. Первоначально надо зайти в консоль астериска командой asterisk -rvvv и попытаться
еще раз набрать с проблемного аппарата. У вас должно получиться что-то
подобное, как на изображении ниже.

Отладка: из изображения видим, что астериск
«ругается» на то, что не находит правила набора на номер 737 в контексте
internal. Для начала в консоли астериска введем команду dialplan show [email protected]internal. Из полученного
ответа будем исходить, как поступать дальше.

Астериск выдал нам
следующее: There is no
existence of ‘internal’ context. Это означает что такого контекста в
диалплане не существует, поэтому необходимо изменить значение параметра context для
внутреннего номера, с которого набираем. Это можно посмотреть в sip.conf в
значении context.

# asterisk -rvvv
# Call from '737' (192.168.170.105:5060) to extension '737' rejected because extension not found in context 'internal'.
> dialplan show [email protected]

Не
совпадение с правилами набора

Если вы
указали уже существующий контекст, но при попытке набора также слышите короткие
гудки, тогда снова заходим в консоль астериска и производим набор с проблемного
устройства.

Отладка:
в данном примере при попытке вызвать номер 4951112233 произошла ошибка и вызов
сбросился. Смотрите изображение ниже.

В консоли
видим похожее сообщение, как в примере выше. Не спешите делать те же самые
действия, выполним похожую операцию.

> dialplan   show local   

Нам выдаст
похожую картину, как на скриншоте ниже.

Из вывода
следует, что в контексте local разрешены вызовы только на номера в формате XXX. Исправить это можно,
перенеся extension в контекст, где разрешено совершать вызовы наружу или
добавить правило набора на городские/мобильные номера.

Ошибки
кастомного диалплана

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

Отладка: на изображении выше мы находим оповещение об
ошибке WARNING[30855]. Оно гласит, что нет команды Got для экстеншена. (No application ‘Got’ for extension). Она
появилась сразу после выполнения команды NoOp. Значит, ошибка, где в написании диалплана. И в тексте
ошибки указывается где именно ошибка (from-internal, 84951112233, 2)

на втором приоритете. Посмотрим выполнение диалплана ранее
известной нам командой.

Из ответа видим, что в приоритете указано правило в
контексте from-internal-custom. И вторым пунктом
выполнения диалплана стоит приложение Got(outrt-2,,1).
Видимо ранее. Когда писали правило опечатались и имелось ввиду Goto, изменим на Goto в
файле extensions_custom.conf

После правок, применим изменения командой dialplan reload и
проверим вызов.

Проблемы
с входящими вызовами

В данном разделе разберем неполадки, при входящих вызовах.
Условно ошибки можно разделить на несколько критериев:

• Вызов
  не поступает на АТС
• Не
  указан DID номер
• Ошибки
  в диалплане

Вызов
не поступает на АТС

При попытке набрать внешний номер вызов отбивается и вы в
консоли лога звонка не видите. Из этого следует, что пакет INVITE, которые приходит от оператора
связи на астериск не доходит, это может вызывать несколько причин:

1. Пакет
   вообще не приходит на АТС
2. Или
   не проходит настроенный на АТС firewall

Проверить приходят ли пакеты на АТС, можно с помощью утилиты
tcpdump. Если в
дампе звонка вы не видите входящие пакеты от оператора связи, то тут возможны
несколько вариантов:

1. Какие-то
   неполадки у оператора связи и вам придется звонить в ТП оператора
2. Если
   транк с регистрацией, то возможно потерялась регистрация и надо заново
   послать оператору пакет REGISTER.
   Проверить можно командой sip
   show register.

Избавиться от этого можно с
помощью консольной команды астериска sip reload

В случае, когда перезагрузка SIP не
помогла, необходимо разбирать дамп и смотреть посылаемые пакеты REGISTER. Посмотреть как
это исправить, можно в нашей статье(https://voxlink.ru/kb/asterisk-configuration/operativnaya-diagnostika-sip-v-konsoli-asterisk-kanaly-pjsip-i-chan_sip/)

1. Если
   транк без регистрации и в выводе команды sip show peers транк
   в статусе Unreacheble или UNKNOWN,
   возможно есть проблемы на сетевом оборудовании и по умолчанию порт UDP 5060
   не проброшен в сторону АТС.

Не
указан DID номер

В случае,
когда вы заводите транк с оператором связи, и необходимо вводить строку
регистрации, не указывается DID номер, на который будет поступать вызов. По умолчанию вызов
приходит в контекст на extension s.
Для которого у вас нет маршрута. Вследствие чего звонок сбрасывается вашей АТС.

Отладка: необходимо указать в строке регистрации DID номер, на который будет приходить вызов. Также, такой DID указать в правилах входящего маршрута.

оставил комментарий

30 Сен, 21


от
dmitryn

(120 баллов)

[2021-09-30 11:34:11] NOTICE[1151] chan_sip.c: tttttttttccccccczzzzzzzzz  callid:5b7df1181b0905263273a0842950a30f@100.100.100.20, sip_pvt_ptr:1146134016
[2021-09-30 11:34:15] NOTICE[1151] chan_sip.c: tttttttttccccccczzzzzzzzz  callid:739f87810afb87485a6836c6070e6798@100.100.100.20, sip_pvt_ptr:1146134016
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: tttttttttccccccczzzzzzzzz  callid:9411912e-c524-484b-adf9-a26e686af885, sip_pvt_ptr:0
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: zzzzccttt 1125927949,1146134724
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: zzzzccttt username:201, 1, 100.100.100.177:5060
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: zzzzccttt
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: [YEASTARMAPDNS] Get peer by ip and toexten:89108446764
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: zzzzccttt 1146110388,1146134724
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: zzzzccttt username:89108446764, 1, 100.100.100.177:5060
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: zzzzccttt
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: tttttttttccccccczzzzzzzzz  callid:9411912e-c524-484b-adf9-a26e686af885, sip_pvt_ptr:1146134016
[2021-09-30 11:34:16] NOTICE[1151] chan_sip.c: tttttttttccccccczzzzzzzzz  callid:9411912e-c524-484b-adf9-a26e686af885, sip_pvt_ptr:1146134016
[2021-09-30 11:34:16] NOTICE[1151] rtp.c: Set RTP to address rtp:1146136768 100.100.100.177:10790
[2021-09-30 11:34:16] NOTICE[26236] chan_dahdi.c: Channel 08 Set zone "ru" 
[2021-09-30 11:34:20] WARNING[26236] chan_dahdi.c: Enabled echo cancellation on channel 8
[2021-09-30 11:34:22] WARNING[26236] chan_dahdi.c: Disabled echo cancellation on channel 8
[2021-09-30 11:34:22] NOTICE[26236] rtp.c: Stop RTP address rtp:1146136768 100.100.100.177:10790
[2021-09-30 11:34:22] NOTICE[1151] chan_sip.c: tttttttttccccccczzzzzzzzz  callid:9411912e-c524-484b-adf9-a26e686af885, sip_pvt_ptr:1146134016

В поддержке ipmatika предложили задать одинаковое имя аккаунту на шлюзе и сотруднику. Не помогло.