У нас междугородная связь идет как с АТС Meridian1, так и с АТС Квант, включенной в Meridian
с помощью DTI2. Далее через спутник и в Москву к оператору. Когда поставили консоль оператора 2250 начались "чудеса", многие абоненты Кванта при наборе межгорода кто мгновенно, кто через 20 секунд попадают на нашего оператора. Вроде бы как при неответе.Может это и было раньше, но сейчас наглядно. Я просмотрел почти весь форум, подобного вопроса не увидел.
Какие и где изменить настройки?

Вообще-то разбираться лучше конкретно: смотреть что было набрано (пришло из транков), почему этот набор не ушел дальше и т.д. Ато угадывать что происходит можно долго, и успех совсем не гарантирован. Один из вариантов:
В Customer Data Block есть раздел Intercept Treatments, в котором определяется что делать со всякими "неправильными" звонками. Во многих ситуациях по умолчанию звонок перенаправляется на консоли, но можно прописать и выдачу busy, например.
Удачи
<P ID="edit"><FONT SIZE=1><EM>Отредактировано PhoneMan 06.02.2001 10:40 (время сервера).</EM></FONT></P>

Намек понял. Спасибо. У нас сейчас ночь.
Утром посмотрю. Хотя глядя в английскую инструкцию и русский перевод не представляю что надо делать.

Если это всё-таки Intercept , то в LD15, для соответствующей ситуации, вместо ATN поставить BSY или OVF.
Удачи

Попробовать не могу по причине отсутствия фнкции ATN в INT.
Уточняем, что переадресовка на оператора происходит после развала транзитного соединения (входящий ROUT DID, а исходящий ROUT TIE) по неответу вызываемого абонента межгорода.



3-11120-FORUM.txt

Опубликуй распечатку CDB из обоих маршрутов ( LD21). Посмотрим вместе. И уточни с каким релизом станция.
Удачи

Кроме уже упоминавшихся Intercept Treatments могу посоветовать поспотреть Gate opener NET в CDB.
Промпт DITI (DID to TIE transit) должен стоять YES
далее.. в идеале для точной диагностики необходима распечатка трассировки вызова из LD 80
Так же попробуй установить патч MPLR07549
Иногда помогает.

With best regards, NAG.

Коллеги, не подскажете, кто какой программой пользуется для тарификации, кроме SamWin.
Буду признателен

SamWin не знаю...
Обычно Phonex фирмы Megatel
А так... пробовали Барсум, Tabs...
Вроде по соотношению цена - колв-во геморроя- кол-во эффективности более менее не плохой.

Хотя все это - порядочное г... А что вы хотели от тарификатора (sic!) за такие деньги ??

With best regards, NAG.

"CDR Plus": контрольная тарификация и статистика.
Написан под конкретную сетку, не сертифицирован.
Удачи

Я не понял какие два направления LD21.
Может еще что есть.
Одну распечатку я посылаю.
у нас релиз 21.19




3-11221-LD21LD15.txt

Привет.
Используем RingMaster. Если интересно напишу подробнее.

Я использую SamWin, такое барахло, очень неудобен. Хотелось бы сменить, да негде

Хотелось посмотреть на распечатки ваших DID и TIE, полученные в LD21.
( imho ROUT происходит от англ. слова route, что и есть маршрут.)
В CDB я не вижу ничего подозрительного...
Следующее предположение - проверить как повлияет на задержку перед переходом вызова на консоль увеличение таймера EOD раз в несколько. Имеется в виду таймер в исходящем TIE маршруте.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи

Судя по результату (40сек -&gt; 55сек), это именно DID to TIE connection
feature. Оказывается есть такая :).
Суть в следующем: транзитный вызов DID -&gt; TIE, после истечения
таймера EOD исходящего маршрута, подпадает по CFNA таймер,
прописанный в CDB. Если вызов так и не отвечен на дальнем конце
TIE, и если есть консоль, то вызов перенаправляется на консоль.
Фича эта как бы системная и неотключаемая. Что можно сделать?
Вижу два варианта:
1) - полумеры - попробовать загнать оба таймера на максимум, imho
каким образом можно создать задержку около 2 минут, хотя это и не
решает проблему полностью. К тому же надо внимательно посмотреть
не всплывут ли какие-нибудь отрицательные последствия.
2) - радикальный - на мой взгляд переписать маршрут DID как TIE
(для начала не убивая старого DID прописать новый маршрут, с
такими же параметрами, но как TIE, и переписать в него несколько
транков, посмотреть как работает). По моему все должно работать.
Удачи