Абоненты АТС coral «А» вызывает абонентов АТС «Б» - соединения и вызова проходят без проблем и наоборот. В какой-то момент АТС А на вызова АТС Б дает отбой – причина CAUSE:81.AC.
На обойх станциях манипуляции и настройки не проводили. Проблема исчезла сама
Вопрос- что могло быть.
Причина CAUSE :81.AC. - это проблема сети или?
найдено в описании "Общие сведения о кодах причин отключения, выводимых командой debug isdn q931"
81 — частная сеть на стороне локального пользователя (возможно, локальная телефонная система для частного пользования)
"АС "Запрошенный канал недоступен Удаленное оборудование не может предоставить запрошенный пользователем канал по неизвестной причине.


[2017-10-18 13:08:12.3] Recv_PRI_0: 06.420 CRef=FA16 Msg type: SETUP:
[2017-10-18 13:08:12.3] -BEARER CAPABILITY :80.90.A3.
[2017-10-18 13:08:12.3] -CALLING NUMBER: 12276655 :21.81.31.32.32.37.36.36.35.35.
[2017-10-18 13:08:12.3] -CALLED NUMBER: 6000 :A1.36.30.30.30.
[2017-10-18 13:08:12.3] -HIGH LAYER COMPATIB. :91.81.
[2017-10-18 13:08:12.3] -SENDING COMPLETE

[2017-10-18 13:08:12.6] Send_PRI_0: 06.680 CRef=FA16 Msg type: DISCONNECT:
[2017-10-18 13:08:12.6] -CAUSE :81.AC.

[2017-10-18 13:08:12.7] Recv_PRI_0: 06.780 CRef=FA16 Msg type: RELEASE:
[2017-10-18 13:08:12.7] -CAUSE :81.90.

[2017-10-18 13:08:12.7] Send_PRI_0: 06.790 CRef=FA16 Msg type: RELEASE_CPLT:

Передача потока E1 работает через Модем IPmux-24 (Ethernet сеть)

Привет. Где про причину прочитал? У меня другая информация:

Причина 81 - Недействительное значение метки соединения
Причина показывает, что оборудование посылающее эту причину приняло сообщение с меткой соединения, которая в настоящее время не используется на интерфейсе пользователь-сеть.

CAUSE :81.90.
90 Обычный сброс вызова
Произошел обычный сброс вызова. Никаких действий выполнять не нужно.
Эта причина означает, что вызов был отключен, поскольку один из пользователей, участвовавших в вызове, запросил его сброс. В обычных ситуациях сеть не является источником этой причины.

AC в 81.AC ЧТО ЭТО?

Когда-то давно разбирался в сообщениях MPT, насколько помню, формат CAUSE описывается в рекомендации Q.850.
Под CAUSE отводится октет, который выглядит так:

8 7 6 5 4 3 2 1 - биты октета
---------------
1 0 1 0 1 1 0 0 - это AC в двоичном виде

В октете бит 8 всегда=1, остальные 7 битов - это сама причина. Получается 0101100, т.е. 2C h, т.е. 44. Причина 44 - запрошенный канал недоступен, как вы и написали.

Вроде бы так, если чего напутал - прошу извинить, пишу по памяти.

У меня такое возникало несколько раз на MPT120 достаточно давно, лет 7 назад, что ли, и тоже прошло самопроизвольно. Правда, насколько помню, эта причина приходила только по одному транку, а поскольку в транк-группе стояло занятие СЛ всегда с 1-й свободной, а не по кругу, абоненты по очереди тыкались в эту линию и сбрасывались с причиной 44.

Что было сделано во избежание:
1. Поставлена свежая версия платы MPT
2. Сделан обход СЛ по кругу (circular) в транк-группе
3. Причина 44 добавлена в LAR SET, который использовался в группе. Это была плата для работы с ТфОП, и их было несколько в одном направлении, поэтому решил перестраховаться и переходить на следующую плату (следующий Dial Service) при возникновении ошибки.

Передача потока E1 работает через Модем IPmux-24 (Ethernet сеть)
TDM over IP ?
Тогда причина тут. У меня это частое явление, именно в таком канале.
Пакет не дошел, потеря фрейма, потеря синхры....
Очень кратковременное явление. От 1,5 до 3 секунд. Но если в это время проходило соединение - оно отвалится с разными ошибками, а уже состоявшийся разговор даже не замечает этого.

Со стороны моей АТС Coral вызова проходили без проблем
что было сделано во избежание:
1. Поставлена свежая версия платы MPT
2. Сделан обход СЛ по кругу (circular) в транк-группе
3. Причина 44 добавлена в LAR SET, который использовался в группе. Это была плата для работы с ТфОП, и их было несколько в одном направлении, поэтому решил перестраховаться и переходить на следующую плату (следующий Dial Service) при возникновении ошибки.
Это все сделано и работает

TDM over IP ?
Тогда причина тут. У меня это частое явление, именно в таком канале.
Пакет не дошел, потеря фрейма, потеря синхры....
Очень кратковременное явление. От 1,5 до 3 секунд. Но если в это время проходило соединение - оно отвалится с разными ошибками, а уже состоявшийся разговор даже не замечает этого.
Значит это больше проблема Ethernet сети, чем на АТС.
Буду задавать вопросы сетевой службе.

Можно еще попробовать изменить настройку d-канала:
B_CHANNEL_NEGOTIATION:
(Exclusive/Preferred)- Exclusive
на preferrred

Привет слушай у меня была такая же ошибка, Причина 81 - Недействительное значение метки соединения. Да это не круто, я долго епался со своим телефоном, но в итоге сменил оператора связи и все.
Часто езжу за границу и было много проблем с телефоном никакой толком связи или - бешенные деньги, просто поменяй на норм оператора связи, если не поможет то смотри вот тут https://youmagic.pro/ :cool:

Привет слушай у меня была такая же ошибка, Причина 81 - Недействительное значение метки соединения. Да это не круто, я долго епался со своим телефоном, но в итоге сменил оператора связи и все.
Часто езжу за границу и было много проблем с телефоном никакой толком связи или - бешенные деньги, просто поменяй на норм оператора связи, если не поможет то смотри вот тут https://youmagic.pro/ :cool:

Я действительно обнаружил неправильный номер метки соединения в трейсе от Владимира и сообщил ему об этом, хотя неправильно интерпретировал запись. 81.АС, которая означала 44 причину. Вероятность появления такого отказа можно минимизировать настройкой циркулярного перебора транков на обеих сторонах и инверсной их нумерацией в в транкгруппах. То есть с одной стороны транки в ТГ записываешь с 1-го по 30-ый, а с другой-с 30-го по 1-ый.

Часто ездить за границу с Кораллом - это круто! Мне такое в голову не приходило. При этом всё возможно - и метка соединения может быть не та или размер не твой. Оператора проще сменить, благо их в загранпоездках предостаточно.