По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, дорогой читатель! На этапе траблшутинга системные администраторы прибегают к просмотру и анализу лог – файлов Asterisk. В статье поговорим про причины отбоя вызова (hangupcause) в Asterisk, как их найти в лог – файле и что они означают.
Поиск Hangupcause
Подключаемся к нашему серверу IP – АТС по SSH. Открываем консоль и вводим следующую команду:
[root@asterisk ~]# grep -e '[CALLID].*HANGUPCAUSE' /var/log/asterisk/full
Здесь CALLID - это идентификатор вызова. Найти его очень просто. В лог – файле введите номер звонящего/вызываемого абонента и найдете примерно вот такую запись (в примере поиск осуществляется по номеру 89123456789):
[2017-02-08 18:58:03] VERBOSE[18823][C-00000009] pbx.c: Executing [recordcheck@sub-record-check:11] Goto("Local/89123456789@from-internal-00000007;2", "startrec") in new stack
Находим запись выше. Здесь, [C-00000009] - является идентификатором вызова.
После того, как Вы нашли hangupcause, его необходимо понять. Переходим к следующему шагу – интерпретация.
Все причины отбоя вызова в Asterisk
Ниже, в таблице, мы составили причины отбоя вызова и соответствующие для них коды SIP ответов с небольшим описанием:
Код отбоя (hangupcause)
Полученный SIP - ответ
Описание
1
410
Unallocated (unassigned) - неназначенный номер. Данная ошибка указывает, что вызываемый номер назначения не может быть вызван, по причине отсутствия маршрута до него. Как правило, данную ошибку возвращает провайдер телефонных услуг. Например, при звонка зарубеж, данная ошибка может возвращаться из-за отсутствия маршрута к номеру назначения.
2
500
No route to specified transit network - ошибка индицирует о том, что оборудование, сгенерировавшее данную ошибку получило запрос запрос на маршрутизацию вызова через неизвестную ей транзитную сеть. Вполне возможно, что данная сеть в целом не существует.
3
404
No route to destination - чисто "сетевая" ошибка. Обозначает отсутствие коннективити (маршрутизации) между сетями инициатора вызова и вызываемого абонента.
4
500
Send special information tone - вызываемый абонент не может быть вызван по причинам "долгосрочного характера", и звонящий должен получить специальный звуковой тон.
5
500
Misdialled trunk prefix - сигнализирует о том, что к вызываемому номеру был подставлен ошибочный телефонный префикс.
6
500
Channel unacceptable - проблемы на канале связи. Как правило это сетевая проблема.
7
500
Call awarded and being delivered in an established channel - индикация того, что пользователь получил входящий вызов и что пользователь уже имеет аналогичный вызов
8
500
Prefix 0 dialed but not allowed - префикс в начале номер "0" не разрешен
9
500
Prefix 1 dialed but not allowed - префикс в начале номер "1" не разрешен
10
—
Prefix 1 not dialed but required - префикс "1" подставлен в начало номера, но не является требованием
11
—
More digits received than allowed, call is proceeding - в вызываемом номере передано больше цифр, чем позволено на оборудовании передающим данный код отбоя
16
BYE
Normal call clearing - вызов был закончен естественным образом (кто - то из абонентов положил трубку)
17
486
User busy - индицирует, что вызываемый абонент не может принять вызов, так как находится в состоянии "Занят" (есть активный разговор)
18
480
No user responding - вызываемый абонент не ответил на сообщение о вызове (инициации) в течение определенного времени
19
480
T.301 expired: – User Alerted, No answer from user - аппарат вызываемого абонента звонил, но он не ответил на звонок
21
603
Call rejected - вызов отклонен
22
480
Number changed to number in diagnostic field - индицирует о том, что вызываемый номер более не существует. В сообщение так же может быть включен новый номер вызываемого абонента
23
—
Reverse charging rejected - вариант, когда за звонок платит принимающая вызов сторона. Данное сообщение обозначает отклонение такого вызова.
24
—
Call suspended - оборудование получило запрос на приостановку вызова
25
—
Call resumed - вызов возобновлен (продолжение 24 отбоя)
26
500
Non-selected user clearing - пользователю не был назначен входящий вызов
27
404
Destination out of order - данное сообщение индицирует о том, что телефонная сигнализация не может быть доставлена через выбранный NIC (сетевой интерфейс). В данном случае, проблема скорее всего кроется на L1 или на L2 уровне (физический или канальный)
28
484
Invalid number format or incomplete address - неправильный формат вызываемого номера или номер указан не полностью
29
501
EKTS facility rejected by network - проблема на уровне платы - устройство отклонено на уровне сети
30
500
Response to STATUS ENQUIRY - сообщение ответ на запрос о состоянии
31
404
Normal, unspecified - эта причина отбоя используется в случае, если другие причины (более конкретные) не были применены
33
—
Circuit out of order - построенный канал связи вышел из строя
34
503
No circuit/channel available - нет доступного для установления соединения канала связи
35
500
Destination unattainable - нет возможности доставить сообщение до получателя
36
500
Out of order - объект функционирует не корректно
37
500
Degraded service - уведомление о том, что сервис находится в некорректном состоянии
38
503
Network out of order - сетевое соединение функционирует не корректно (вероятная проблема на уровне L3)
39
500
Transit delay range cannot be achieved - требуемый диапазон задержки (время обработки, передачи) не может быть достигнут
40
500
Throughput range cannot be achieved - требуемый диапазон пропускной способности (передача сообщения) не может быть достигнута
41
503
Temporary failure - временная неработоспособность сервиса. "Временная" означает то, что пользователь может попробовать еще раз через некоторое время
42
503
Switching equipment congestion - в настоящее время, оборудование коммутации испытывает пиковые значения нагрузки и не может обработать запрос
43
500
Access information discarded - данная причина индицирует о том, что по запросу сеть (L3) не может доставить информацию о доступе к удаленному пользователю
44
503
Requested circuit channel not available - запрошенный канал связи недоступен
45
500
Preempted - данная причина указывает на то, что вызов был прерван
46
500
Precedence call blocked - означает, что вызываемый пользователь занят вызовов с более высоким приоритетом
47
503
Resource unavailable, unspecified - причина, отправляемая в том случае, если ни одна другая не была отправлена
49
500
Quality of service unavailable - использование QoS требование не доступно
50
500
Requested facility not subscribed - пользователь запросил услугу, которую он не может получить по причине отсутствия доступа к ней
51
—
Reverse charging not allowed - вариант, когда за звонок платит принимающая вызов сторона не разрешен для данного пользователя
52
—
Outgoing calls barred - исходящий вызов запрещен для абонента
53
500
Outgoing calls barred within CUG - данная причина означает, что несмотря то, что пользователь является членом закрытой группы юзеров (CUG - Closed User Groups) для совершения исходящего вызова, ему данная итерация запрещена
54
—
Incoming calls barred - входящий вызов запрещен для абонента
55
603
Incoming calls barred within CUG - данная причина означает, что несмотря то, что пользователь является членом закрытой группы юзеров (CUG - Closed User Groups) для приема входящего вызова, ему данная итерация запрещена
56
—
Call waiting not subscribed - пользователь не имеет права (не подписан) на услугу "Ожидание вызова"
57
501
Bearer capability not authorized - пользователь запросил расширение пропускной способности канала до оборудования, но не имеет права на подобные итерации
58
501
Bearer capability not presently available - пользователь запросил расширение пропускной способности канала до оборудования, но в данный момент данная функция не доступна
63
503
Service or option not available, unspecified - сообщение сообщает о недоступности услуги в том случае, если другие причины (более конкретные) не были отправлены пользователю
65
501
Bearer service not implemented - служба передачи (переноса) информации не реализована
66
500
Channel type not implemented - устройство, посылающее данную причину не поддерживает указанный типа канала связи
67
—
Transit network selection not implemented - не удалось совершить выбор транзитной сети
68
—
Message not implemented - данное сообщение не реализовано
69
500
Requested facility not implemented - эта причина указывает на то, что устройство, отсылающее эту причину не поддерживает запрашиваемые дополнительные услуги
70
500
Only restricted digital information bearer capability is available - данное сообщение указывает на то, что пользователь запросил неограниченный доступ к пропускной способности канала связи, но устройство поддерживает только с ограничениями
79
501
Service or option not implemented, unspecified - услуга или опция не реализована (когда другие причины не были отправлены)
81
500
Invalid call reference value - эта причина указывает на то, что устройство, отсылающее эту причину, получило сообщение с идентификатором вызова, который в настоящее время не используется на интерфейсе сети пользователя
82
500
Identified channel does not exist - эта причина указывает на то, что устройство, отсылающее эту причину, получило запрос на использование канала, который не активизирован на сетевом интерфейсе. Например, если пользователь использует в потоке Е1 (PRI) тайм – слоты с 1 по 12, а запросил использовать с 3 по 24 – будет сгенерирована данная причина
83
500
A suspended call exists, but this call identity does not - вызов существует, но отсутствуют идентификаторы для него
84
500
Call identity in use - оборудование получило запрос на приостановление вызова, содержащий идентификатор вызова, под которым вызов уже значится приостановленным
85
500
No call suspended - получен запрос на возобновление вызова с идентификатором звонка, который не числится в списке приостановленных
86
500
Call having the requested call identity has been cleared - получен запрос на возобновление вызова с идентификатором звонка, который был прерван в результате тайм - аута
87
603
Called user not member of CUG - вызываемый абонент не является членом закрытой группы юзеров (CUG - Closed User Groups)
88
404
Incompatible destination - система получила запрос на установление соединения с параметрами, которые не могут быть обслужены
89
—
Non-existent abbreviated address entry - не существующий адрес
90
500
Destination address missing, and direct call not subscribed - адрес назначения не указан, а опция директивного вызова недоступна для пользователя
91
500
Invalid transit network selection (national use) - получен индикатор транзитной сети, который имеет неверный формат (в рамках рекомендации Q.931)
92
—
Invalid facility parameter 93 Mandatory information element is missing - обязательный элемент информационного сообщения отсутствует
93
500
Message type non-existent or not implemented - получено устройством сообщение не может быть интерпретировано на оборудовании
95
404
Invalid message, unspecified - неправильное сообщение. Используется только тогда, когда другие (более конкретные сообщения) не были отправлены
96
500
Mandatory information element is missing - в полученном оборудованием сообщение отсутствует важное для его обработки поле
97
500
Message type non-existent or not implemented - тоже самое что и 93 код
98
500
Message not compatible with call state or message type non-existent or not implemented - сообщение не совместимо с текущим состоянием звонка или не может быть интерпретировано оборудованием
99
500
Information element nonexistent or not implemented - информационный элемент не существует или не может быть интерпретирован оборудованием
100
500
Invalid information element contents - элемент не может быть интерпретирован. Помимо этого, одно или более полей сообщения были закодировано алгоритмом, который не поддерживает оборудованием.
101
500
Message not compatible with call state - полученное сообщение не соответствует состоянию вызова
102
408
Recovery on timer expiry - процедура восстановления по причине тайм - аута параллельно с алгоритмами обработки ошибок
103
500
Parameter non-existent or not implemented – passed on - параметр не существует или не реализован на оборудовании
111
404
Protocol error, unspecified - ошибка, которая отправляется в случае, если более детальное сообщение не было отправлено
127
500
Internetworking, unspecified - на этапе установления соединения произошел сбой
Большинство организаций заинтересованы в улучшении своей бизнес инфраструктуры. Телефония на базе IP – это комплексное масштабируемое решение, которое позволяет компании снизить расходы, повысить лояльность клиентов и улучшить KPI (Key Performance Indicators).
Что же такое «IP - телефония»?
IP - телефония - это набор протоколов, алгоритмов и соглашений об обслуживании (QoS).
Среди протоколов можно выделить протокол сигнализации и протоколы, которые переносят сами медиа данные (голос). Сигнализации в терминологии телефонии, это набор событий и логика их обработки. К таким событиям можно отнести установление телефонного соединения, удержание, трансфер, завершение вызова и т.д. Хочется отметить, что сигнализацией между двумя телефонами всегда управляет телефонная станция. Перенос самих медиа данных осуществляется напрямую между двумя телефонами.
Обратим внимание на рисунок ниже:
В данном примере телефонная станция обозначена как сервер, программное обеспечение которого занимается обработкой телефонной сигнализации. Давайте разберемся с участками сигнализации, обозначенными пунктиром.
На сегодняшний день, широко используется протокол SIP (Session Initiation Protocol), описанный в рекомендации RFC 3261. Это открытый стандарт, поддерживаемый всеми известными АТС. SIP удобен в использовании и обнаружении проблем, т.к имеет структуру, коды и синтаксис во многом схожий с протоколом HTTP. Так же в корпоративном сегменте часто встречается проприетарный SCCP (Skinny Client Control Protocol), разработанный компанией Cisco Systems, и стандарт H.323. Именно эти протоколы полностью контролируют процесс телефонного разговора.
Теперь, когда мы понимаем, что такое телефонная сигнализация, давайте посмотрим на процесс передачи медиа – потока. Эти функции выполняет протокол RTP (Real-time Transport Protocol), описанный в RFC 3550. Специально разработанный для аудио и видео данных, RTP назначает каждому пакету номер и временной тэг. Когда поток данных приходит в узел получатель, пакеты обрабатываются и декодируются в правильной последовательности. Представьте, если бы IP-пакеты приходили к получателю в не правильном порядке? Разговор вряд ли бы состоялся, т.к разобрать речь не представлялось бы возможным.
Картина начинает складываться. Под управлением протоколов сигнализации RTP поток передается от отправителя к получателю. Теперь имеет смысл подумать над тем, как обеспечить интеграцию интернет и телефонного трафика, без взаимного влияния друг на друга. В телефонии, зачастую под цели голосового трафика выделяют отдельные VLAN. Это позволяет разграничить телефонный и интернет трафик на логическом уровне. Но самым важным и надежным механизмом является QoS (Quality of Service). Это алгоритм приоритизации трафика, обработки очередей, выделений необходимой полосы пропускания, задержки, джиттера и др. В треке CCNP Voice (Cisco Certified Network Professional Voice), под QoS выделен целый экзамен. В следующих статьях мы постараемся описать данный механизм более подробно.
Хочется подвести небольшой итог: IP - телефония – это неотъемлемая часть успешного бизнеса. Мы, как команда опытных профессионалов готовы оказать вам помощь в установке, настройке офисной телефонии. Провести консультации, помочь с выбором провайдера и спроектировать оптимальное решение для уже существующего сетевого ландшафта.
В предыдущем материале мы рассмотрели, как работает Интернет на базовом уровне, включая взаимодействие между клиентом (вашим компьютером) и сервером (другим компьютером, который отвечает на запросы клиента о веб-сайтах).
В этой же части рассмотрим, как устроены клиент, сервер и веб-приложение, что мы можем удобно серфить в Интернете.
Модель клиент-сервер
Эта идея взаимодействия клиента и сервера по сети называется моделью «клиент-сервер». Это делает возможным просмотр веб-сайтов (например, сайт wiki.merionet.ru) и взаимодействие с веб-приложением (как Gmail).
На самом деле, модель клиент-сервер - это ни что иное, как способ описать отношения между клиентом и сервером в веб-приложении. Это детали того, как информация переходит от одного конца к другому, где картина усложняется.
Базовая конфигурация веб-приложения
Существует сотни способов настройки веб-приложения. При этом большинство из них следуют одной и той же базовой структуре: клиент, сервер, база данных.
Клиент
Клиент - это то, с чем взаимодействует пользователь. Так что «клиентский» код отвечает за большую часть того, что на самом деле видит пользователь. Это включает в себя:
Определение структуры веб-страницы
Настройка внешнего вида веб-страницы
Реализация механизма пользовательского взаимодействия (нажатие кнопок, ввод текста и т.д.)
Структура: Макет и содержимое веб-страницы определяются с помощью HTML (обычно HTML 5, если речь идет о современных веб-приложениях, но это другая история.)
HTML означает язык гипертекстовой разметки (Hypertext Markup Language). Он позволяет описать основную физическую структуру документа с помощью HTML-тэгов. Каждый HTML-тэг описывает определенный элемент документа.
Например:
Содержимое тега «<h1>» описывает заголовок.
Содержимое тега «<p>» описывает абзац.
Содержимое тега «<button>» описывает кнопку.
И так далее...
Веб-браузер использует эти HTML-тэги для определения способа отображения документа.
Look and Feel: Чтобы определить внешний вид веб-страницы, веб-разработчики используют CSS, который расшифровывается как каскадные таблицы стилей (Cascading Style Sheets). CSS - это язык, который позволяет описать стиль элементов, определенных в HTML, позволяя изменять шрифт, цвет, макет, простые анимации и другие поверхностные элементы.
Стили для указанной выше HTML-страницы можно задать следующим образом:
Взаимодействие с пользователем: Наконец, для реализации механизма взаимодействия с пользователем, на сцену выходит JavaScript.
Например, если вы хотите что-то сделать, когда пользователь нажимает кнопку, вы можете сделать что-то подобное:
Иногда взаимодействие с пользователем, может быть реализовано без необходимости обращения к вашему серверу - отсюда и термин "JavaScript на стороне клиента". Другие типы взаимодействия требуют отправки запросов на сервер для обработки.
Например, если пользователь публикует комментарий в потоке, может потребоваться сохранить этот комментарий в базе данных, чтобы весь материал был структурирован и собран в одном месте. Таким образом, вы отправляете запрос на сервер с новым комментарием и идентификатором пользователя, а сервер прослушивает эти запросы и обрабатывает их соответствующим образом.
Сервер
Сервер в веб-приложении прослушивает запросы, поступающие от клиента. При настройке HTTP-сервера он должен прослушивать конкретный номер порта. Номер порта всегда связан с IP-адресом компьютера.
Вы можете рассматривать порты как отдельные каналы на каждом компьютере, которые можно использовать для выполнения различных задач: один порт может быть использован для серфинга на wiki.merionet.ru, в то время как через другой получаете электронную почту. Это возможно, поскольку каждое из приложений (веб-браузер и клиент электронной почты) использует разные номера портов.
После настройки HTTP-сервера для прослушивания определенного порта сервер ожидает клиентские запросов, поступающие на этот порт, выполняет все действия, указанные в запросе, и отправляет все запрошенные данные через HTTP-ответ.
База данных
Базы данных – это подвалы веб-архитектуры - большинство из нас боятся туда спускаться, но они критически важны для прочного фундамента. База данных - это место для хранения информации, чтобы к ней можно было легко обращаться, управлять и обновлять.
Например, при создании сайта в социальных сетях можно использовать базу данных для хранения сведений о пользователях, публикациях и комментариях. Когда посетитель запрашивает страницу, данные, вставленные на страницу, поступают из базы данных сайта, что позволяет нам воспринимать взаимодействие пользователей в реальном времени как должное на таких сайтах, как Facebook или в таких приложениях, как Gmail.
Как масштабировать простое веб-приложение
Вышеописанная конфигурация отлично подходит для простых приложений. Но по мере роста приложения один сервер не сможет обрабатывать тысячи - если не миллионы - одновременных запросов от посетителей.
Чтобы выполнить масштабирование в соответствии с этими большими объемами, можно распределить входящий трафик между группой внутренних серверов.
Здесь все становится интересно. Имеется несколько серверов, каждый из которых имеет собственный IP-адрес. Итак, как сервер доменных имен (DNS) определяет, на какой экземпляр вашего приложения отправить трафик?
Ответ очевиден - никак. Управление всеми этими отдельными экземплярами приложения происходит через средство балансировки нагрузки.
Подсистема балансировки нагрузки действует как гаишник, который маршрутизирует клиентские запросы по серверам как можно быстрее и эффективнее, насколько это возможно.
Поскольку вы не можете транслировать IP-адреса всех экземпляров сервера, вы создаете виртуальный IP-адрес, который транслируется клиентам. Этот виртуальный IP-адрес указывает на подсистему балансировки нагрузки. Таким образом, когда DNS ищет ваш сайт, он указывает на балансировщик нагрузки. Затем подсистема балансировки нагрузки перескакивает для распределения трафика на различные внутренние серверы в реальном времени.
Возможно, вам интересно, как подсистема балансировки нагрузки узнаёт, на какой сервер следует отправлять трафик. Ответ: алгоритмы.
Один популярный алгоритм, Round Robin, включает равномерное распределение входящих запросов по ферме серверов (все доступные серверы). Вы обычно выбираете такой подход, если все ваши серверы имеют одинаковую скорость обработки и память.
С помощью другого алгоритма, Least Connections, следующий запрос отправляется на сервер с наименьшим количеством активных соединений.
Существует гораздо больше алгоритмов, которые вы можете реализовать, в зависимости от ваших потребностей.
Теперь поток трафика выглядит следующим образом:
Службы
Итак, мы решили проблему трафика, создав пулы серверов и балансировщик нагрузки для управления ими.
Но одной репликация серверов может быть недостаточно для обслуживания приложения по мере его роста. По мере добавления дополнительных функциональных возможностей в приложение необходимо поддерживать тот же монолитный сервер, пока он продолжает расти. Для решения этой проблемы нам нужен способ разобщить функциональные возможности сервера.
Здесь и появляется идея служб. Служба является просто другим сервером, за исключением того, что она взаимодействует только с другими серверами, в отличие от традиционного веб-сервера, который взаимодействует с клиентами.
Каждая служба имеет автономную единицу функциональности, такую как авторизация пользователей или предоставление функции поиска. Службы позволяют разбить один веб-сервер на несколько служб, каждая из которых выполняет отдельные функции.
Основное преимущество разделения одного сервера на множество сервисов заключается в том, что он позволяет масштабировать сервисы полностью независимо.
Другое преимущество здесь заключается в том, что он позволяет командам внутри компании работать независимо над конкретной услугой, а не иметь 10, 100 или даже 1000 инженеров, работающих на одном монолитном сервере, который быстро становится кошмаром для менеджера проекта.
Краткое примечание: эта концепция балансировщиков нагрузки и пулов внутренних серверов и служб становится очень сложной, поскольку вы масштабируете все больше и больше серверов в вашем приложении. Это особенно сложно с такими вещами, как, например, сохранение сеанса, обработка отправки нескольких запросов от клиента на один и тот же сервер в течение сеанса, развертывания решения для балансировки нагрузки. Такие продвинутые темы не будет затрагивать в данном материале.
Сети доставки контента (Conten Delivery Network – CDN)
Все вышеперечисленное отлично подходит для масштабирования трафика, но приложение все еще централизовано в одном месте. Когда ваши пользователи начинают посещать ваш сайт из других концов страны или с другого конца мира, они могут столкнуться с длительной задержкой из-за увеличенного расстояния между клиентом и сервером. Ведь речь идет о "всемирной паутине" - не о "местной соседней паутине".
Популярная тактика решения этой проблемы - использование сети доставки контента (CDN). CDN - это большая распределенная система «прокси» серверов, развернутая во многих центрах обработки данных. Прокси-сервер - это просто сервер, который действует как посредник между клиентом и сервером.
Компании с большим объемом распределенного трафика могут платить CDN-компаниям за доставку контента конечным пользователям с помощью серверов CDN. CDN имеет тысячи серверов, расположенных в стратегических географических точках по всему миру.
Давайте сравним, как веб-сайт работает с CDN и без него.
Как мы уже говорили в разделе 1, для типичного веб-сайта доменное имя URL преобразуется в IP-адрес сервера хоста.
Однако если клиент использует CDN, доменное имя URL преобразуется в IP-адрес пограничного сервера, принадлежащего CDN. Затем CDN доставляет веб-контент пользователям клиента, не затрагивая серверы клиента.
CDN может сделать это, сохраняя копии часто используемых элементов, таких как HTML, CSS, загрузки программного обеспечения и медиаобъектов с серверов клиентов.
Главная цель - расположить контент сайта как можно ближе к конечному пользователю. В итоге пользователь получает более быструю загрузку сайта.