Voice debug что это
Команды Cisco IOS для отладки VoIP
Полезные команды Cisco IOS, которые могут пригодится в процессе настройки и устранении неполадок Cisco Call Manager Express (CME).
debug callmonitor all
Показывает всю информацию по звонкам и соединениям, выполняющимся в настоящий момент
sh voip rtp connection
Показывает текущие RTP соединения
sh voice call status
Показывает состояние текущих голосовых соединений (звонков, совершаемых в настоящий момент)
debug voip application vxml error
Показывает ошибки в скрипте VXML IVR
debug voip dialpeer
Показывает все входящие и исходящие dial-peer, задействованные во время звонка.
debug voip ccapi inout
Команда покажет какие dial-peer совпадают на IOS шлюзе и состояние шлюза во время обработки звонка. Также полезна для отслеживания, какой кодек используется при звонке.
show voice register statistics
Команда показывает общую статистику регистрации телефонов
show ephone registered
Отображаются все зарегистрированные телефоны
debug voice translation
Команда покажет совпадение правил трансляции, которые вызываются внутри dial-peer или voice-port во время обработки вызова.
debug sccp events
Команда покажет какие ресурсы зарегистрированы на CME и используются во время обработки звонков.
debug ccsip messages
Команда показывает все SIP сообщения между CME и телефонами или провайдерами.
Основы устранения неполадок и отладки вызовов по протоколу VoIP
Параметры загрузки
Содержание
Введение
В этом документе демонстрируются основные приемы и команды для устранения неполадок и отладки сетей VoIP. Представлен общий обзор потока голосового вызова и архитектуры телефонии в маршрутизаторе Cisco, а также пошаговый подход к устранению неполадок Cisco, описанный в нескольких пунктах:
Примечание: в этом документе не объясняются все аспекты архитектуры Cisco IOS®, используемые в шлюзах и привратниках Cisco VoIP. Он предназначен для объяснения того, какие команды могут использоваться и какие поля из выходных данных команд могут иметь наибольшее значение.
Внимание: отладка Cisco IOS может вызвать сильную нагрузку на процессор. Будьте внимательны при использовании процедур отладки, приведенных в этом документе. Для получения дополнительных сведений обратитесь к разделу Важные сведения о командах отладки.
Процедуры отладки необходимо запускать со включенными в журнале метками времени. Включите установку меток времени, добавив следующие команды: service timestamps debug datetime msec, service timestamps log datetime msec в режиме enable. Метки времени помогают определить интервал времени между изменениями состояния.
Предварительные условия
Требования
Этот документ предназначен для сетевых специалистов, участвующих в проектировании и внедрении сетей VoIP. Читатели этого документа должны знать следующее:
Используемые компоненты
Данный документ не ограничен отдельными версиями программного и аппаратного обеспечения. Приводимые выходные данные получены на программном обеспечении Cisco IOS®, релиз 12.3(8).
Сведения, представленные в данном документе, были получены на тестовом оборудовании в специально созданных лабораторных условиях. При написании данного документа использовались только данные, полученные от устройств с конфигурацией по умолчанию. При работе с реально функционирующей сетью необходимо полностью осознавать возможные последствия выполнения команд до их применения.
Условные обозначения
Дополнительные сведения об условных обозначениях в документах см. в разделе Технические советы Cisco. Условные обозначения.
Поток вызовов в сети
Важным фактором, который надо учитывать до начала любого устранения неполадок VoIP или отладки, является то, что соединения VoIP состоят из трех участков. Этими тремя участками соединения являются исходная обычная телефонная сеть (POTS), VoIP и POTS назначения. Это показано на следующем рисунке. Устранение неполадок и отладка должны быть нацелены сначала отдельно на каждый участок, а затем на все соединение VoIP в целом.
Поток вызова маршрутизатора
В данных определениях объясняются функции главных компонентов, показанных на диаграмме потока вызова маршрутизатора:
API-интерфейс контроля вызовов — API-интерфейс контроля вызовов используется тремя клиентами. Это интерфейс командной строки, агент SNMP и приложение сеанса. Главными функциями API-интерфейса контроля вызовов (CCAPI) являются:
Идентификация участков вызова (например, какая это точка вызова, откуда это соединение).
Принятие решения о том, какое приложение сеанса примет вызов (например, кто его будет обрабатывать).
Вызов обработчика пакетов.
Общая обработка всех ветвей вызова.
Начало записи статистики вызовов.
Приложение сеанса и программа сопоставления плана соединений — Приложение сеанса использует программу сопоставления плана соединений для сопоставления номера точке вызова (местной POTS или удаленной VoIP). Программа сопоставления плана соединений использует таблицу одноранговых узлов для поиска активных адресуемых точек вызова.
Архитектура интерфейса IP-телефонии
На этой схеме показана архитектура компоновочных блоков телефонии маршрутизатора Cisco и их взаимодействие друг с другом.
Далее описываются функции и даются определения главных компонентов схемы:
API-интерфейс контроля вызовов (CCAPI) — Элемент программного обеспечения, который устанавливает, завершает и связывает ветви вызова.
Поставщик услуг голосовой телефонии (VTSP) — Процесс IOS, который обслуживает запросы из API-интерфейса контроля вызовов и формулирует соответствующий запросы к процессору цифровых сигналов (DSP) или к VPM.
Модуль голосового процессора (VPM) — VPM ответственен за объединение и координирование процессов передачи сигнала между SSM портов телефонии, менеджером ресурсов DSP и VTSP.
DSP Resource Manager — DSPRM предоставляет интерфейсы, с помощью которых VTSP может обмениваться сообщениями с DSP.
Обработчик пакетов — Обработчик пакетов пересылает пакеты между DSP и ветвями одноранговых соединений.
Проверьте цифровую и аналоговую сигнализацию (ветвь вызова POTS)
Целью проверки цифровой и аналоговой сигнализации является:
Определить, что принимаются правильные аналоговые или цифровые сигналы подключения и отключения.
Убедиться, что на маршрутизаторе и коммутаторе (центральная или офисная АТС) правильно настроена сигнализация E&M, FXO и FXS.
Убедиться, что DSP находятся в режиме сбора цифровых данных.
Подчеркнутые команды из этого раздела могут использоваться для проверки сигнализации.
show controllers T1 / E1 (digital)
show controllers t1 [slot/port] — используйте эту команду первой. Она показывает, установлено или нет цифровое соединение T1 между маршрутизатором и коммутатором (центральная или офисная АТС), и правильно ли оно работает. Выходные данные этой команды выглядят следующим образом:
При использовании E1 употребляйте команду show controllers e1. Подробнее см.
show voice port
show voice port slot-number/port — используйте эту команду для отображения состояния порта и параметров, настроенных на голосовом порте карты речевого интерфейса (VIC) Cisco. Как и во всех командах IOS, параметры по умолчанию не отображаются в выходных данных show running-config, но отображаются с помощью этой команды.
Это пример выходных данных для голосового порта E&M:
debug vpm (voice processor module)
Эти команды используются для отладки интерфейса телефонии VPM:
debug vpm signal — эта команда используется для сбора информации отладки для событий сигнализации и может быть полезна при разрешении проблем с сигнализацией в PBX.
debug vpm spi — эта команда отслеживает, как SPI модуля голосового порта взаимодействует с API-интерфейсом контроля вызовов. Команда отладки debug выводит на экран сведения об обработке запросов индикации и приложений сети.
debug vpm dsp — эта команда показывает сообщения из DSP на VPM к маршрутизатору и может быть полезна, если есть подозрение, что VPM не работает. Это простой способ проверить, реагирует ли VPM на индикаторы отключения и оценить промежутки между поступлением сообщений сигнализации из интерфейса.
debug vpm all — эта команда EXEC включает все команды debug vpm: debug vpm spi, debug vpm signal и debug vpm dsp.
debug vpm port — используйте эту команду для вывода данных отладки только для определенного порта. Например, в данном примере показан вывод сообщений debug vpm dsp только для порта 1/0/0:
Пример выходных данных для команды debug vpm signal
Если в состоянии подключения и отключения сигнализация происходит неправильно, проверьте следующее:
Проверьте подключение кабеля.
Проверьте заземление маршрутизатора и коммутатора (центральная или офисная АТС).
Убедитесь в том, что конечные точки соединения имеют соответствующие настройки сигнализации. Несоответствующие конфигурации могут вызывать неполную или одностороннюю сигнализацию.
Пример выходных данных для команды debug vpm spi
Проверка полученных и отправленных цифр (по ветвям вызовов POTS)
После того как сигнализация подключения и отключения проверена и работает правильно, убедитесь в том, что на голосовой порт (цифровой или аналоговый) принимаются и отправляются правильные цифры. Если принимаются или отправляются неправильные цифры, точка вызова может не согласовываться, а коммутатор (центральная или офисная АТС) может не соединяться с нужной станцией. Некоторые команды, которые можно использовать для проверки полученных/отправленных цифр:
show dialplan number — эта команда используется для отображения того, какая точка вызова была достигнута при наборе конкретного телефонного номера.
debug vtsp session — эта команда показывает данные об обработке запросов индикации и приложений сети, об индикации сигнализации и контрольных сообщениях DSP.
debug vtsp dsp — в программном обеспечении Cisco IOS ранее релиза 12.3 эта команда показывает цифры в том виде, в котором они приняты голосовым портом. Однако в программном обеспечении Cisco IOS, релиз 12.3 и более поздние выходные данные команды debug больше не показывают цифры. Для просмотра входящих цифр можно использовать комбинацию команд debug hpi detail и debug hpi notification.
debug vtsp all — эта команда включает следующие команды VTSP: debug vtsp session, debug vtsp error и debug vtsp dsp.
show dialplan number
show dialplan number — эта команда показывает точку вызова, которая сопоставлена строкой цифр. Если могут быть сопоставлены несколько точек вызова, они показываются все, в том порядке, в котором были сопоставлены.
Примечание: чтобы провести сопоставление по шаблонам назначения, оканчивающимся на Т, необходимо использовать знак # в конце телефонных номеров для точек вызова с переменной длиной.
Выходные данные этой команды выглядят следующим образом:
debug vtsp session
Команда debug vtsp session показывает сведения о том, как маршрутизатор взаимодействует с DSP, на основании индикаторов сигнализации из стека сигнализации и запросов из приложения. Эта команда debug показывает данные о том, как обрабатываются каждый индикатор сети и запрос приложения, об индикаторах сигнализации и контрольных сообщения DSP.
Если определено, что цифры были отправлены или приняты неправильно, возможно, будет необходимо использовать сборщик цифр (средство проверки) или тестер T1, которые проверят, отправляются ли цифры с правильной частотой и интервалами времени. Если они «неправильно» отправляются для коммутатора (центральная или офисная АТС), некоторые значения маршрутизатора или коммутатора (центральная или офисная АТС), возможно, потребуется скорректировать, чтобы они согласовывались и были совместимы. Обычно это значения длительности цифры и интервала между цифрами. Необходимо также проверить, не являются ли цифры, которые отправляются как будто правильно, какими-либо таблицами трансляции номеров в коммутаторе (центральная или офисная АТС), которые могут добавлять или удалять цифры.
Проверка сквозной передачи сигналов VoIP (участок вызова VoIP)
После того, как вы убедитесь, что сигнализация голосового порта работает правильно и принимаются правильные цифры, переходите к устранению неполадок и отладке управления вызовами VoIP. Следующие факторы объясняют, почему отладка управления вызовами может оказаться сложной работой.
Шлюзы Cisco VoIP используют для выполнения вызовов сигнализацию H.323. H.323 состоит из трех уровней согласования вызовов и установления вызовов: H.225, H.245 и H.323. Эти протоколы используют сочетание TCP и UDP для установления и организации вызова.
Отладка сквозного VoIP показывает число конечных автоматов IOS. Проблемы с любым из конечных автоматов могут вызвать обрыв соединения.
Отладка сквозного VoIP может оказаться очень многословной и произвести большой объем выходных данных отладки.
debug voip ccapi inout
Основной командой для отладки сквозных вызовов VoIP является debug voip ccapi inout. В данном примере показаны выходные данные отладки вызова.
Если вызов разрывается, и причина, скорее всего, в VoIP-части установки сигнала, вам, возможно, понадобится взглянуть на части установки сигнала H.225 или H.245 TCP, а не просто на UDP-часть установки H.323. Команды, которые можно использовать для отладки настройки вызова H.225 или H.245, приведены ниже:
debug ip tcp transactions и debug ip tcp packet — эти команды проверяют TCP-часть согласования H.225 и H.245. Они возвращают IP-адреса, TCP-порты и состояния соединений TCP.
debug cch323 h225 — эта команда проверяет H.225-часть согласования вызова и отслеживает передачу статуса конечного автомата H.225 на основании обработанного события. Это можно представить как часть «уровень 1» из трех частей установки звонка Н.323.
debug cch323 h225 — эта команда проверяет H.245-часть согласования вызова и отслеживает передачу статуса конечного автомата H.245 на основании обработанного события. Это можно представить как часть «уровень 2» из трех частей установки звонка Н.323.
Сведения об ошибках качества обслуживания (QoS) VoIP
После того как все проблемы с вызовами VoIP должным образом решены, необходимо убедиться в качестве передаваемого голосового сигнала. Хотя в данном документе не описывается устранение неполадок, связанных с качеством обслуживания, данные инструкции следует учитывать при работе над хорошим качеством передачи голоса.
Следует выяснить ширину полосы пропускания, которую вызов VoIP задействует с каждым из кодеков. Это включает заголовки уровня 2 и IP/UDP/RTP. Подробнее см. IP-телефония: использование полосы пропускания для каждого вызова.
Следует выяснить характеристики IP-сети, через которую передается вызов. Например, полоса пропускания в сети frame-relay при согласованной скорости передачи данных (CIR) сильно отличается от полосы при скорости выше CIR (или при всплеске), когда пакеты могут отбрасываться или скапливаться в облаке Frame-Relay. Убедитесь, что задержка и помехи контролируются и устраняются, насколько это возможно. Задержка передачи по одному направлению не должна превышать 150 мс (по рекомендациям G.114).
Используйте метод очереди, который позволяет идентифицировать трафик VoIP и устанавливать в нем приоритеты.
При передаче VoIP по низкоскоростным каналам помните о возможности использования методов фрагментации пакетов уровня 2, таких как MLPPP с фрагментацией чередования каналов (LFI), в каналах точка-точка или FRF.12 в каналах Frame-Relay. Фрагментация пакетов данных большого размера позволяет снизить объем помех и задержки при передаче трафика VoIP, так как выполняется чередование пакетов в канале.
Попытайтесь использовать разные кодеки и произвести вызов со включенным и выключенным VAD, чтобы по возможности уменьшить вывод в DSP, в отличие от IP-сети.
При наличии VoIP, устраняя неполадки QoS, следует прежде всего искать отброшенные пакеты и критические места сети, которые могут вызвать задержки и помехи.
Необходимо проверить каждый интерфейс по пути соединения VoIP. Необходимо также устранить сбросы и перегрузки. Двухсторонняя задержка должна быть уменьшена настолько, насколько это возможно. Двухстороннюю задержку канала можно определить при помощи команд ping, посылающих пакеты между конечными точками VoIP. Когда это возможно, двухсторонняя задержка не должна превышать 300 мс. Если задержка вынужденным образом превышает это значение, следует предпринять усилия и убедиться в том, что она постоянна и не вносит помехи или переменную задержку.
Следует также выполнить проверку, чтобы убедиться, что механизм IOS формирования очереди размещает пакеты VoIP в правильной очереди. В проверке формирования очереди могут помочь такие команды IOS, как show queue interface или show priority.
Данные кодов причины и значений отладки для VoIP
Используйте данные таблицы при чтении процедур отладки и соответствующих значений в процессе отладки.
Q.931 Причины отключения вызова (cause_codes из debug voip ccapi inout)
Подробнее о кодах и значениях причин Q.931 см. «Типы коммутаторов ISDN, коды и значения»
Значение причины отключения вызова (в шестнадцатеричной системе)
Значение и номер (в десятичных числах)
неназначенный номер. (1)
нет маршрута к адресу назначения. (3)
обычный сброс вызова. (16)
пользователь занят. (17)
пользователь не отвечает. (18)
нет ответа от пользователя. (19)
недопустимый номер. (28)
нормальный, не уточненный. (31)
канал отсутствует. (34)
канал отсутствует. (44)
служба или параметр недоступны или не определены. (63)
Digital Voice Ports, или работа с ISDN E1 PRI
Вообще голосовые сети можно разделить на три категории:
— Analog Voice Circuit Switched Network
— Digital Voice Circuit Switched Network
— Voice over IP Packet Network
Исторически эти технологии появлялись в том же порядке. В этой статье мы обсудим Digital Voice Ports и работу с ними.
Основной уклон мы сделаем в сторону ISDN E1 PRI, как наиболее распространенный стандарт в России.
Как уже упоминалось голосовые сети можно разделить на три категории. Для их взаимодействия друг с другом используются устройства Voice Gateways.
Voice Gateways имеют порты совместимые с каждым из типов голосовых сетей.
Как уже стало понятно, Digital voice ports обеспечивают подключение к Digital Voice Circuit Switched Network.
Существует три типа digital voice circuits:
Физически подключение к digital voice circuits происходит через интерфейсные карты как на рисунке. Сам же тип digital voice circuits определяется настройками шлюза.
Главная идея digital voice circuits заключается в том, чтобы грубо говоря, по одной телефонной паре проходило не один а несколько звонков. Технология разрабатывалась в экономических соображениях, а также для обхода явления затухания в аналоговых линиях.
Все эти типы технологий различаются типом сигнализациии, количеством потоков. Одни распространены в одних странах, другие в других.
Возможность «засунуть» несколько звонков в один провод появилась благодаря технологиям оцифровки, которые заключались в дроблении аудио синусоиды, получения маленькиз кусочнов (samples), которым сопоставлялось определенное цифровое значение. Единственное что надо было понять: насколько сильно необходимо дробить синусоиду.
Было выполнено масса исследований, в результате которых исследователи вывели замечательную теорему:
Аудио поток можно уверенно оцифровать и затем восстановить, если одну секунду голоса дробить на количество сэмплов в два раза большее максимальной частоты.
Поток под частоту человеческого голоса требует пропускной способности 64,000 bits per second и называется DS0.
Кстати этот же поток без сжатия, и без потерь качества, но в кодировке VoIP называется G.711.
Самые первые попытки разместить в одном проводе несколько звонков использовали разные частоты для каждого потока. Большинство сегодняшних технологий используют Time-Division Multiplexing (TDM), когда используется одна частота, но фреймы каждого потока идут в определенном порядке.
В любом голосовом потоке можно выделить собственно сам поток (Bearer), где идет разговор и сигнализацию (Data).
Существует два типа сигнализации:
— CAS: Сигнализация передаётся в голосовом канале. Применяются всяческие замысловатые комбинации распределения сигнальный, контрольных битов и их чередование с битами голоса.
— CCS: Сигнализация передается в выделенном канале, т.е. выделяется отдельный Time Slot под сигнализацию.
В настоящее время операторы предпочитают использовать CCS. ISDN также использует CCS.
ISDN разрабатывался для возможности передачи цифровых данных через обычную телефонную пару.
ISDN позволяет одновременно передавать цифровую телефонию и данные.
ISDN использует B-каналы и D-каналы. «D» (data) используется для сигнализации, а «B» (bearer) для передачи голоса.
Например ISDN E1 PRI на голос использует 30 потоков, 1 на сигнализацию, 1 на Framing
Параметры типов интерфейсов ISDN:
Здесь следует отметить что:
Network Clock Timing
ISDN Signaling
ISDN использует для сигнализации протоколы:
Настройка ISDN
При подключении к городу в своем большинстве настройки диктуются провайдером, предоставляющим поток E1.
Например вот фрагмент переписки с Beeline:
Первые три параметра Line coding, Framing, Clock относятся к настройкам Controller Settings
Настройка ISDN: Card Type
Сначала необходимо задать Card Type, т.е. на этом этапе мы задаём тип карты E1 или T1.
Определим в каком слоте находится карта:
conf t
card type e1 0 1
Далее мы можем узнать индекы доступных контроллеров:
Настройка ISDN: Timing
При работе с большинством провайдеров мы должны забирать Timing от провайдера.
Настройка ISDN: Controller Settings
К Controller Settings относятся несколько параметров, которые обычно задает провайдер, к которому мы планируем подключиться по E1.
В источниках параметры описываются не внятно, либо нужно залезать в дебри.
ИМХО нужно просто понимать что есть ряд параметров, о которых нужно договориться с провайдером E1.
Пример настройки под MGCP
Пример с использованием digital voice port
Значения по умолчанию:
Если выставить эти значения, то в конфиге они отображаться не будут
framing CRC4
clock source line
linecode hdb3
Посмотреть текущие настройки Controller Settings:
show controllers e1
Digital Voice Port Configuration
После того как мы определили ds0-group, система автоматически создает логический Voice Port. На этот Voice Port уже может ссылаться Dial-peer для осуществления маршрутизации. Но перед этим нам необходимо ввести конфигурацию порта в соответствии с требованиями провайдера.
Существуют настройки как для B Channels, так и для D Channel.
Digital Voice Port D Channel: Configuration
Здесь номер 0/0/0:15 означает номер time-slot для D Channel. Поскольку time-slot нумеруются начиная с 0, то реально это будет 16-ый по счету timeslot.
Чтобы четко понимать номер интерфейса, наберите команду:
show voice port summary
Digital Voice Port D Channel: Проверка
Digital Voice Port B Channel: Configuration
Некоторые параметры относятся к голосовым потокам:
Digital Voice Port B Channel: Проверка
Резюме
Итак все настройки ISDN можно разделить на три уровня:
Посмотреть текущие настройки можно через команду: show controllers e1
Настройка dial-peer
После создания DS0 группы, мы уже можем её использовать в настройках Dial-peer
Например для работы с городом часто используется следующая конфигурация:
На самом CUCM нам надо будет настроить H.323 Gateway, настроить Route Pattern, Route Group, Route List, по аналогии как это описано в статье Настройка Call Manager CUCM с нуля: Связь с внешним миром (Часть 3)
Для MGCP использование диалпиров необязательно, более подробный материал по на настройке MGCP см. Теория и практика настройки MGCP Gateway
Итоговая конфигурация для H.323
Отметим, что лучшей практикой считается использовать MGCP, если нет специальных требований под использование H.323.
В случае подключения провайдера по ISDN E1 PRI Cisco рекомендует использовать MGCP.
Настройка ISDN + MGCP подробно описана в статье: Теория и практика настройки MGCP Gateway
Проверка настроек Digital Voice Ports
Всегда, после настройки следует проверить на ошибки. Даже если уже проходят звонки, все равно возможны к примеру слипы, которые не дадут нормально проходить факсам.
Также для поиска проблема незаменима замечательная пошаговая инструкция от Cisco: E1 Troubleshooting
Физическое подключение
Данный вопрос иногда ставит в тупик, поскольку физически подключаешь не каждый день.
Подключение к T1/E1 производится через Multiflex Trunk Interface Cards.
Примерами таких плат могут быть:
VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-2MFT-G703, VWIC-2MFT-E1-DI
Приведём описание «лампочек». Переводить не буду чтобы не исказить:
LED | Description | Color |
AL | ALARM. A local or remote alarm state exists. This LED is off during normal operation. | Yellow |
LP | LOOPBACK. A loopback or line state is detected or is manually set by the user. This LED is off during normal operation. | Yellow |
CD | CARRIER DETECTED. A carrier has been detected, and the internal DSU/CSU in the interface card is communicating with another DSU/CSU. This LED is on during normal operation. | Green |
Таким образом, в нормальном состоянии, горит только зелёный огонек CD.
Как видно из картинки, в разъем E1 подключаются привычный 8P8C modular plug, который часто называют Rj-45.
На практике это означает, что мы на обоих концах обжимаем провод как прямой сетевой Rj-45.
В некоторых случаях рабочим будет следующая распиновка (T1 E1 Crossover):
Для получения рабочего кабеля необходимо с одной стороны обжать как обычно (1[б/ор], 2[ор], 3[б/зел], 4[син], 5[б/син], 6[зел], 7[б/кор], 8[кор]) а с другой поменять местами оранжевую и синюю пары (1[син], 2[б/син], 3[б/зел], 4[б/ор], 5[ор], 6[зел], 7[б/кор], 8[кор]).
Ещё вариант подключения (МТС)
— 1[б/зел], 2[зел], пропуск, 4[б/ор], 5[ор]
— 1[ор], 2[б/ор], пропуск, 4[б/зел], 5[зел]
Заворот
Для этого нужно соединить:
1 RX+ 4 TX+
2 RX- 5 TX-
Т.е. обжать с одной стороны кабель как:
1[б/ор], 2[ор], 3[б/зел], 4[син], 5[б/син], 6[зел], 7[б/кор], 8[кор]
Далее
скрутить [б/ор]+[син]
скрутить [ор]+[б/син]