Часто возникает проблема, когда невозможно прозвониться на разные номера. Причем номера точно свободны. В мониторинге D-канала в этот момент вижу:

DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000570 CH 1 28 TOD 14:28:50
CALLING #:00010012 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5551122 NUM PLAN: E164 TON: UNKNOWN

DCH 10 UIPE_IMSG CC_PROCEED_IND REF 00000570 CH 1 28 TOD 14:28:50

DCH 10 UIPE_IMSG CC_PROGRESS_IND REF 00000570 CH 1 28 TOD 14:28:50
PROGRESS: CALL IS NOT END TO END ISDN

DCH 10 UIPE_OMSG CC_SETUP_RESP REF 000094EC CH 1 4 TOD 14:28:52
PROGRESS: INTERWORKING WITH PRIVATE WORK

DCH 10 UIPE_IMSG CC_SETUPCOMP_IND REF 000014EC CH 1 4 TOD 14:28:52

DCH 10 UIPE_IMSG CC_DISC_IND REF 00000570 CH 1 28 TOD 14:28:54
CAUSE: #17 - USER BUSY

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 00000570 CH 1 28 TOD 14:28:54

DCH 10 UIPE_IMSG CC_RELEASE_CONF REF 00000570 CH 1 28 TOD 14:28:54

DCH 10 UIPE_OMSG CC_DISC_REQ REF 0000056F CH 1 30 TOD 14:28:56
CAUSE: #17 - USER BUSY


я так понимаю, что проблема у моего ТФоП-ного uplink'а может быть?

p.s. транки в момент проблемы смотрю - свободны.

DCH 10 UIPE_IMSG CC_DISC_IND REF 00000570 CH 1 28 TOD 14:28:54
CAUSE: #17 - USER BUSY

Если ты думаешь, что это не так, то стоит пообщатся с провайдером на тему почему он на свободного абонента выдаёт USER BUSY.

т.е. если я вижу такое сообщение в мониторинге D-канал, что у меня на провайдера поднят - значит звонок точно к нему уходит, а он мне по какой-то причине возвращает Busy ?

и проблема точно не у меня?

У тебя
CALLING #:00010012 NUM PLAN: UNKNOWN TON: UNKNOWN
а правильней
CALLING #:00010012 NUM PLAN: E164 TON: NATL
И номер твой какой-то странный. Есть основания полагать, что проблемы у тебя. И то, что ты называешь "частый КПВ" есть сигнал overflow

NUM PLAN: UNKNOWN TON: UNKNOWN
- это потому что у меня звонок приходит с одной PRI на другую PRI-карту (типа транзит и на этой станции нет СЛек).

Так настраивать транзит надо. Оператор может по этой причине отбивать вызовы.

Что Вы понимаете под "настройкой транзита"?

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

ИМХО не по понятиям настроен стык. Если вызовы проходят - это еще не значит, что все правильно. Надо отавать правильный номер и правильные информационные элементы в сторону оператора.

pas-quantum пишет
Часто возникает проблема, когда невозможно прозвониться на разные номера. Причем номера точно свободны. Есть такая уверенность? Как влючены абоненты на удаленной стороне известно? Там УПАТС? как она включена в город?

p.s. транки в момент проблемы смотрю - свободны. Да непричем тут транки с вашей стороны, setup благополучно проходит, а вам возврвщается User Busy т.е. занят именно вызываемый абонент.

Кто оператор у вас и на удаленной стороне?

А вообще надо понимать, ни ТФОП ни коммерческие операторы не гарантируют того, что в любой момент времени вы сможете дозвониться на любую свободную АЛ. Сеть с коммутацией каналов, однако.. и каналов в ней существенно меньше чем абонентов..

Urri пишет
ИМХО не по понятиям настроен стык. Если вызовы проходят - это еще не значит, что все правильно. Надо отавать правильный номер и правильные информационные элементы в сторону оператора. Может быть конечно... но в таком случае IMHO отшивало бы постоянно и скорее с каким-нибудь другим CAUSE.

ИМХО слишком много ненужных вопросов.

Да, уверенность в свободности линии есть. Как включены - известно, это и ТФоП и ВоИП. Какая разница кто операторы?

Есть опыт, крупные операторы в Питере честно дают User Busy когда занят их абонент, или когда User Busy приходит с транзитного узла.
Что в какой ситуации придет от гейта IP-шной телефонии - предсказать невозможно.
Если такая конспирация, то imho угадывать где узкое место тебе проще самому... дело хозяйское..

Ну, я так понимаю, что если у меня все ок и этот бизи приходит все же от моего оператора, то и разбираться (отвечать за это) ему. Так что буду ждать ответа от него.

спасибо.

Old Chap пишет
Может быть конечно... но в таком случае IMHO отшивало бы постоянно и скорее с каким-нибудь другим CAUSE.
Не факт. Это как оператору удобнее. А насчет постоянно-не постоянно уважаемый pas-quantum не признается когда это возникает
pas-quantum пишет
Ну, я так понимаю, что если у меня все ок...
Я бы настоятельно рекомендовал навести порядок с исходящими вызовами в плане отдачи в сторну оператора правильного АОН и информационных элементов

хм... мой "upstream" говорит: видет, что Busy этот идет от меня (см. выше диагностика D-канала на провайдера #10).
DCH 10 UIPE_IMSG CC_DISC_IND REF 00000570 CH 1 28 TOD 14:28:54
CAUSE: #17 - USER BUSY

т.е. я сам кидаю ему бизи на свой же звонок.

сори, в данном примере получаю Бизи от провайдера, а вот зачастую бывает и наоборот, типа:
DCH 10 UIPE_OMSG CC_DISC_REQ REF 00000A72 CH 1 29 TOD 12:02:38
CAUSE: #17 - USER BUSY

pas-quantum пишет
сори, в данном примере получаю Бизи от провайдера, а вот зачастую бывает и наоборот, типа:
DCH 10 UIPE_OMSG CC_DISC_REQ REF 00000A72 CH 1 29 TOD 12:02:38
CAUSE: #17 - USER BUSY

А тут что странного вы говорите на входящий вызов от провайдера, что ваш абонент занят (или при этом ваш абонент свободен?).

это не мой абонент! и он свободен

А кто тогда слышит "частый кпв на городксие номера" ? Короче говоря, полную трассировку вызова в студию, и рассказ о схеме транзита, если это транзитный вызов. Иначе это пустой разговор.
Удачи

pas-quantum пишет
это не мой абонент! и он свободен т.е. Вы городу рассказываете, что его абонент занят???
супер:)
можно лог такого обмена?
желательно НЕ чищеный и НЕ правленый... просто весь кусок "от и до"
пусть с мусором, зато может выясним где "собака порылась"

DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000A72 CH 1 29 TOD 12:02:30
CALLING #:00010011 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5551127 NUM PLAN: E164 TON: UNKNOWN

DCH 10 UIPE_IMSG CC_PROCEED_IND REF 00000A72 CH 1 29 TOD 12:02:30

DCH 10 UIPE_IMSG CC_PROGRESS_IND REF 00000A72 CH 1 29 TOD 12:02:30
PROGRESS: CALL IS NOT END TO END ISDN

DCH 10 UIPE_OMSG CC_DISC_REQ REF 00000A72 CH 1 29 TOD 12:02:38
CAUSE: #17 - USER BUSY

DCH 10 UIPE_IMSG CC_RELEASE_IND REF 00000A72 CH 1 29 TOD 12:02:38

DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 00000A72 CH 1 29 TOD 12:02:38


DCH10 - на провайдера, номер 5551127 (изменен) в городе и свободен.

Вызов транзитный? Звонок с транка?

да, транзитный, с транка в транк
Две разных PRI-платы (разные E1)

К сожалению не имею 312 пакета:

The response TAT is not allowed if Trunk Antitromboning (TAT) package 312 is not equipped. RCAP is reprompted.
Action: Equip Package 312 and reload to enter TAT feature.

Оба Д-канала на трассировку, чтобы было видно сразу и входящий и исходящий вызов.

Попробую "прокоментировать" ваш трейс:
DCH 10 UIPE_OMSG CC_SETUP_REQ - исходящий запрос на установление соединения (пока опустим детали по поводу TON=UNKNOWN и NUM_PLAN=UNKNOWN что не есть хорошо ниже обьясню почему).
DCH 10 UIPE_IMSG CC_PROCEED_IND - вышестоящая станция (ГТС) ответила вам что принятых от вас цифр хватает для маршрутизации вызова и она начала обработку вызова.
DCH 10 UIPE_IMSG CC_PROGRESS_IND - ГТС подает вам в "акустике" сигнал (может быть КПВ, а может быть даже занято).
Вот тут пошло что-то занятное:
DCH 10 UIPE_OMSG CC_DISC_REQ - CAUSE: #17 - USER BUSY
это сообщение исходящее от вас что требуется рассоединение по причине того что абоенент ЗАНЯТ???
DCH 10 UIPE_IMSG CC_RELEASE_IND - ГТС "соглашается" с вами по поводу отбоя.
DCH 10 UIPE_OMSG CC_RELEASE_RESP - этой командой вы завершили соединение.

Такой "сценарий" будет возможен лишь в следующем случае, если к вам транзитом соединена компьютерная платформа которая контролирует акустический тракт в предответном состоянии и анализируя сигнал занято посылает сообщение о рассоединении с причиной пользователь занят (зачем это надо можно только догадываться????).
Если хотите получить полный ответ дайте полную информацию, укажите схему соединения и укажите тип оборудования со стороны пользователя (что там УАТС, шлюз подключенный к вам напрямую, шлюз подключенный через УАТС или что-то другое и дайте трассировку для этого вызова с обоих D-каналов.
По поводу типов номеров и нумерационного плана, если строго говоря, вы обязаны правильно формировать все флаги, например некоторые станции ваш вызов просто не пропустят (например к этому очень "ревностно" относятся AXE-10 и SI-2000), самая "пофигисткая" станция из "больших" EWSD, правда если ее настроить соответственно и она будет очень "строга":D. Поэтому включившись в вашу узловую АТС которая будет пропускать ваш вызов без изменения флагов дальше на сеть вы в один прекрасный момент получите отказ со стороны транзитных АТС которым ваша "вольность" может не понравиться.
И еще один маленький совет (я вам одно слово скажу только вы не обижайтесь, как говорил киногерой) можно конечно сидеть возле "разбитого" корыта с "кукишем в кармане", а можно попытаться решить проблемму, как поступить вам решать.

Схема:
Meridian ("провадера") - мой Meridian (транзит, карты PRI) - cisco 53xx - VoIP(ciscoATA186). Телефонные стыки: E1, Euro ISDN. Звоню с ATA на городской номер, через всю схему, номер у меня на столе и свободен.

К сожалению последнее время наблюдаю другую картину в трассировке (проблема бизи остается):
DCH 11 UIPE_IMSG CC_SETUP_IND REF 00002484 CH 2 1 TOD 10:39:48
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5551127 NUM PLAN: UNKNOWN TON: UNKNOWN
DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000B1E CH 1 6 TOD 10:39:48
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5551127 NUM PLAN: E164 TON: UNKNOWN
DCH 11 UIPE_OMSG CC_PROCEED_REQ REF 0000A484 CH 2 1 TOD 10:39:48
DCH 10 UIPE_IMSG CC_PROCEED_IND REF 00000B1E CH 1 6 TOD 10:39:48
DCH 10 UIPE_IMSG CC_PROGRESS_IND REF 00000B1E CH 1 6 TOD 10:39:48
PROGRESS: CALL IS NOT END TO END ISDN
DCH 11 UIPE_OMSG CC_PROGRESS_REQ REF 0000A484 CH 2 1 TOD 10:39:48
PROGRESS: CALL IS NOT END TO END ISDN
DCH 10 UIPE_IMSG CC_DISC_IND REF 00000B1E CH 1 6 TOD 10:39:50
CAUSE: #17 - USER BUSY
DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 00000B1E CH 1 6 TOD 10:39:50
DCH 11 UIPE_OMSG CC_DISC_REQ REF 0000A484 CH 2 1 TOD 10:39:50
CAUSE: #17 - USER BUSY
DCH 11 UIPE_IMSG CC_RELEASE_IND REF 00002484 CH 2 1 TOD 10:39:50
DCH 11 UIPE_OMSG CC_RELEASE_RESP REF 0000A484 CH 2 1 TOD 10:39:50
DCH 10 UIPE_IMSG CC_RELEASE_CONF REF 00000B1E CH 1 6 TOD 10:39:50

Напомню: 10-ый D-chanel в сторону провайдера, 11-ый в сторону CiscoAS53xx. Теперь из трэйса вижу что занято приходит от провайдера.

Также заметил вот какой глюк: когда удается дозвониться и при этом не поднимая трубку положить свою, то телефон еще какое-то время звонит (продолжительное время), каналы на Меридиане не освобождаются и вот, что вижу в трассировке:
DCH 11 UIPE_IMSG CC_SETUP_IND REF 00002584 CH 2 1 TOD 10:55:36
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5551127 NUM PLAN: UNKNOWN TON: UNKNOWN
DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000B20 CH 1 4 TOD 10:55:36
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5551127 NUM PLAN: E164 TON: UNKNOWN
DCH 11 UIPE_OMSG CC_PROCEED_REQ REF 0000A584 CH 2 1 TOD 10:55:36
DCH 10 UIPE_IMSG CC_PROCEED_IND REF 00000B20 CH 1 4 TOD 10:55:36
DCH 10 UIPE_IMSG CC_PROGRESS_IND REF 00000B20 CH 1 4 TOD 10:55:36
PROGRESS: CALL IS NOT END TO END ISDN
DCH 11 UIPE_OMSG CC_PROGRESS_REQ REF 0000A584 CH 2 1 TOD 10:55:36
PROGRESS: CALL IS NOT END TO END ISDN
DCH 11 UIPE_OMSG CC_RELEASE_REQ REF 0000A584 CH 2 1 TOD 11:00:36
DCH 10 UIPE_OMSG CC_DISC_REQ REF 00000B20 CH 1 4 TOD 11:00:36
CAUSE: #17 - USER BUSY
DCH 11 UIPE_IMSG CC_RELEASE_CONF REF 00002584 CH 2 1 TOD 11:00:36
DCH 10 UIPE_IMSG CC_RELEASE_IND REF 00000B20 CH 1 4 TOD 11:00:36
DCH 10 UIPE_OMSG CC_RELEASE_RESP REF 00000B20 CH 1 4 TOD 11:00:36
, т.е. звонок держится еще ~5 минут!

Можно попросить немного рассказать или ткнуть в документацию, где речь о TON=UNKNOWN и NUM_PLAN=UNKNOWN , т.е. как правильно формировать эти флаги?

p.s. киногерою привет! ;)

ИМХО при таках раскадах флаги должна формировать Циска. И она же не отрабатывает отбой с АТАшки.

Прихожу к такому же выводу, но есть мнение что проблем как минимум две:
1) Циска не дает отбой при звонке с ВоИПа.
2) Иногда номер занят при его точной свободности.

Тут меня посетила мысля, насколько я понимаю телефон на вашем столе от "провайдерского" Меридиана какой у него тип машины если 61 или 81, тогда понятно откуда "занято". Все дело в том что у большой машины абонентская емкость подключается по "неполнодоступной" схеме и вполне возможен вариант, что нехватает каналов между абонентской полкой и коммутационным полем, но это опять же гипотеза.
По поводу формирования флагов TON и NUM_plan:
по идее их конечно же должна формировать Циска, в зависимости как вы обрабытваете вызова от Циски (через NARS, через CDP, напрямую подставляете ACOD гор.маршрута в промпт на руте к Циске INST) можно попробовать изменить TON (для CALLED абонента), для Calling абонента все более муторно надо пробовать. По поводу отбоев нужно тоже смотреть Циску, со стороны Меридиана криминала вроде не видно.

PS. Откуда взялась строка :
DCH 10 UIPE_OMSG CC_DISC_REQ - CAUSE: #17 - USER BUSY
из предидущего трейса???

Нет, еще раз: телефон на столе от другого оператора. Также на столе есть телефон через АТАшку (-cisco53xx-мойМеридиан-пров.Меридиан). При звонке с АТАшки на обычный городской номер, телефон что на столе это и проявляется.

Не пойму зачем менять TON?
voice-port 3/0:D
cptone RU
<--- об этом ton'е речь?

Использую BARS, через IDC таблицу на рутах подставляю AC1 и попадаю на BARS, который отлично отрабатывает.

Иногда почему-то видел такую строку в трассе, чему и был удивлен, сейчас такого не проявляется.

По поводу Циски сказать не могу VOIP на ней не запускал.
Если вы используете BARS тогда посмотрите цепочку для городских вызовов SPN->RLI->DMI в этих DMIях поставьте промпт CTYP (Call type) например NXX-(тип Subscriber).
По поводу вашей схемы она получается длиннее: Ваша ATA->Cisco5300->Ваш_Меридиан->провайдерский_Меридиан->ГТС_транзитная_станция->ГТС_оконечная_станция (последние могут находиться в пределах одной станции, а может быть и транзитных станций несколько). Вы можете поручиться что на всех интервалах достаточное количество каналов? Если можете тогда заявку на ГТС с проблеммой. Кстати можно сделать такой эксперимент, звоните с ATA-шки на телефон ГТС на вашем столе, допустим получаете занято, с телефона подключенного к вашему Меридиану набираете этот же номер, будет тоже занято или нет? И последнее насколько часто возникает такая ситуация.

Изменил с NCHG на NXX, NUM PLAN и TON при этом остались как и было:
DCH 11 UIPE_IMSG CC_SETUP_IND REF 00002E04 CH 2 1 TOD 13:53:30
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5553322 NUM PLAN: UNKNOWN TON: UNKNOWN
DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000B30 CH 1 18 TOD 13:53:30
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5553322 NUM PLAN: E164 TON: UNKNOWN

Да схема похожа. Нет конечно, не могу поручиться (я только за себя могу поручиться ;) )

У меня нет аб. телефонов на Меридиане (чистый транзит).

Давольно часто. Можно через раз дозвониться, можно 10-раз подряд слушать бизи.

знавал я одного "провайдера" (не Питер) у которого на десяток станций (несколько тысяч абонентов) был один (!) DTI на ТфОП...
мрак... позвонить невозможно! (и заметте на заведомо свободного абонента)
вот так и живем :)

у меня свободных каналов хватает ;)

У твоего "опереатора" потоки могут приходить совсем не в тот свич, из которого раздаётся абонентская емкость. Стоит какая-нибудь 11-ая, работающая как канальный концентратор.
Удачи

pas-quantum пишет
Изменил с NCHG на NXX, NUM PLAN и TON при этом остались как и было:
DCH 11 UIPE_IMSG CC_SETUP_IND REF 00002E04 CH 2 1 TOD 13:53:30
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5553322 NUM PLAN: UNKNOWN TON: UNKNOWN
DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000B30 CH 1 18 TOD 13:53:30
CALLING #:0000923 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5553322 NUM PLAN: E164 TON: UNKNOWN


Можно посмотреть на распечатки рутов на ГТС и на Cisco53xx и заодно на DCH10 и DCH11. А также на цепочку BARS(SPN),RLI и DMI которые используются в этом соединении.

Выслал на e-mail.

Ответил на E-mail.

Кстати на сайте www.cisco.am лежит очень много информации по конфигурации CISCO роутеров (правда все на аглицком), ее полезно почитать прежде чем задавать вопросы на Комптеке (форум) там над "чайниками" могут жестоко поиздеваться :D, наш форумист Gosha это подтвердит:cool: .

1) С англицким проблем нету
2) Cisco вроде как умеем конфигурить (более 3-х) лет, конечно E1 на них поднимать не так давно стали, но документацию поизучали (на www.cisco.com есть даже настройка Меридина и циски, правда QSIG)
3) Комптек наш отличный партнер и там я такого не спрашивал.

На письмо Вам ответил, также по e-mail - со многим не согласен, почему рассказал там. В любом случае очень благодарен за граммотное обсуждение моей проблемы. И готов "сотрудничать" дальше. ;)

Благодарю "vv11" за помощь (по e-mail'у)!

Вот что обнаружил!
При звонке с VoIP и отбое этого звонка, до поднятия трубки вижу, что по SIP'у на AS53xx приходит SIP Event = 487 Request cancelled, СС = 16. Наксолько понимаю и в Мердиан должен падать CAUSE: #16 - NORMAL CALL CLEARING. А я вижу на D-chanel'е, что приходит CAUSE: #17 - USER BUSY и следовательно такой же уходит транзитом моему оператору (ТФоП)! После чего некоторое время номер становится занят.

Может в Меридиане есть где-то таблица соответсвия этих кодов (типа как на cisco http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087ed6.html) ?

ВСЕ!!! Решил! ;))
Если кому интересно - выставил на 53xx, что отдавать при disconnect'е надо 16 case:

interface Serial3/0:15
description D-chanel
isdn disconnect-cause 16