Доброго времени суток всем!
Есть LDK-300 версии 3.8. Городская нумерация 2хххххх и 3хххххх.
Звонки на 3 проходят. звонки на 2 не проходят, хотя запрограммированы одинаково.
Необходимо снять трассировку звонков с потока для предьявы выше стоящей станции.
На LDK-300 еще не снимал.
Мои действия:
1. DIP-3 на плате MPBN перевел в положение OFF.
2. В ПГМ175/7 указал Telnet 1.
3. через telnet ввожу пароль jennie
4. на mon> отвечаю t nct
5. выхожу из режима mon введя х.
6. делаю тестовый звонок.

Возникли вопросы:
1.Получаю не всю информацию в текстовых сообщениях
2.Как скинуть трассировку в лог-файл?

п.4 - неверная команда.
нужно:
mon> t b XX <Enter> (где ХХ - номер слота, в котором стоит PRIB).
Если в станцию установлен модуль доп. памяти - SDMU32 (SDMU-A), то только тогда можно получить доп. текстовую расшифровку. Тогда можно ввести команду:
mon> t b XX n <Enter>

По поводу записи в файл - ИМХО гораздо удобнее пользоваться не собственно Telnet'ом, входящем в состав Windows, а какой-либо другой терминальной программой, поддерживающий протокол Telnet: ProComm, NetTerm, HyperTerminal и т.п.

Снял трассировку c LDK-300. звонок с номера 1536 на 2101010 (+2 впереди), звонил дважды:

LDK-300 System
Version GS30P-3.8Bf JUL/08
DATE: 10/13/08
TIME: 13:27:44
SITE NAME :
ENTER PASSWORD: ******
mon> t b 08 n
Trace On: Slot(08) - Board Trace
mon> x

DATE: 10/13/08 TIME: 13:29:03
Exiting monitor utility...

--------------------============================================>>>>>>>>>>

(CO 29) SETUP
IE_SEND_COMPLETE
IE_BEARER_CAPABILITY
IE_CHANNEL_INFO
IE_CALLING_NO
1536
IE_CALLED_NO
22101010

2571044 D>08 29, C1 00 00
2571046 COL 029:08 29 St:wt sz rsp (00) EVT :D1 0A 02 18 03 A9 83 9E 1E 02 82 8
(U1)
<<<<<<<<<<============================================--------------------

(CO 29) CALL PROCEEDING
IE_CHANNEL_INFO
IE_PROG_INDICATION

2571046 COL 029:08 29 St:wt sz rsp (00) Ev-I:pp sz ack P1: 0 P2: 0 EVT: 16
<- 29,61
2571046 D>08 29, C0 00 64
2571047 COL 029:08 29 St:dialing (00) Ev-T:inter dgt P1: 0 P2: 0 TMR: 41
<- 29,61
2571047 D>08 29, C0 00 64
2571047 CO=29 T_041
2571047 COL 029:08 29 St:dialing (00) Ev-I:dummy acd P1:26D6 P2: 0 EVT: 0
<- 29,61
2571047 COL 029:08 29 St:dialing (00) EVT :DE 05 45 08 02 83 9F (U3)
<<<<<<<<<<============================================--------------------

(CO 29) DISCONNECT
IE_CAUSE
CCITT standardized coding
transit network
n

2571047 C>08 29, DF 05 4D 08 02 83 9F
--------------------============================================>>>>>>>>>>

(CO 29) RELEASE
IE_CAUSE
CCITT standardized coding
transit network
normal event

2571047 D>08 29, C1 00 00
2571047 D>08 29, C5 00 00
2571048 COL 029:08 29 St:dialing (00) EVT :E0 01 5A (U19)
<<<<<<<<<<============================================--------------------

(CO 29) RELEASE COMPLETE

2571051 COL 029:08 29 St:dialing (00) Ev-T:isd rls gd P1
<- 29,61
2571051 D>08 29, C5 00 00
2571128 COL 029:08 29 St:co idle (00) Ev-I:enb sz req P1: 0 P2: 0 EVT: 25
<- 38,05
2571128 D>08 29, C1 00 00
2571195 COL 029:08 29 St:enblk p_sz(00) Ev-I:mem dial P1: 0 P2:1015D491 EVT:
110 <- 38,05
2571195 COL 029:08 29 St:enblk p_sz(00) Ev-I:enb sz snd P1: 0 P2: 0 EVT: 26
<- 29,61
2571195 C>08 29, D5 1F 05 A1 04 03 80 90 A3 18 03 A9 83 9D 6C 06 40 80 31 35 33
36 70 09 80 32 32 31 30 31 30 31 30
--------------------============================================>>

(CO 29) SETUP
IE_SEND_COMPLETE
IE_BEARER_CAPABILITY
IE_CHANNEL_INFO
IE_CALLING_NO
1536
IE_CALLED_NO
22101010

2571195 D>08 29, C1 00 00
2571196 COL 029:08 29 St:wt sz rsp (00) EVT :D1 0A 02 18 03 A9 83 9E 1E 02 82 88
(U1)
<<<<<<<<<<============================================--------------------

(CO 29) CALL PROCEEDING
IE_CHANNEL_INFO
IE_PROG_INDICATION

2571196 COL 029:08 29 St:wt sz rsp (00) Ev-I:pp sz ack P1: 0 P2: 0 EVT: 16
<- 29,61
2571196 D>08 29, C0 00 64
2571197 COL 029:08 29 St:dialing (00) Ev-T:inter dgt P1: 0 P2: 0 TMR: 41
<- 29,61
2571197 D>08 29, C0 00 64
2571197 CO=29 T_041
2571197 COL 029:08 29 St:dialing (00) Ev-I:dummy acd P1:26D6 P2: 0 EVT: 0
<- 29,61
2571198 COL 029:08 29 St:dialing (00) EVT :DE 05 45 08 02 83 9F (U3)
<<<<<<<<<<============================================--------------------

(CO 29) DISCONNECT
IE_CAUSE
CCITT standardized coding
transit network
normal event

2571198 C>08 29, DF 05 4D 08 02 83 9F
--------------------============================================>>>>>>>>>>

(CO 29) RELEASE
IE_CAUSE
CCITT standardized coding
transit network
normal event

2571198 D>08 29, C1 00 00
2571198 D>08 29, C5 00 00
2571199 COL 029:08 29 St:dialing (00) EVT :E0 01 5A (U19)
<<<<<<<<<<============================================--------------------

(CO 29) RELEASE COMPLETE

10/13/08 TIME: 13:31:00
2571202 COL 029:08 29 St:dialing (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9
<- 29,61
2571202 D>08 29, C5 00 00
2571250 COL 029:08 29 St:co idle (00) Ev-I:enb sz req P1: 0 P2: 0 EVT: 25
<- 38,05
2571250 D>08 29, C1 00 00

для сравнения трассировка с Definity в другом офисе. звонок с номера 1350:

11:57:26.775
-> Outgoing
Call Reference: 0x6A0E
Message: SETUP
Sending Complete
Bearer Capability
Coding Standard: CCITT
Information transfer capability: 3.1 kHz audio
Transfer mode: Circuit mode
Information transfer rate: 64 kbit/s
User information layer 1 protocol: CCITT G.711 A-Law
Channel Identification
Coding standard: CCITT standardized coding
Interface: Primary
Selection: Indicated channel is preferred
D-channel indicator: The channel identified is not the D-channel
Channel number: 1
Progress Indicator
Coding Standard: CCITT standardized coding
Location: Private network serving the local user
Progress Description: Origination address is non ISDN
Calling Party Number
Type of number: National number
Numbering plan: ISDN/telephony numbering plan
Digits: 1350
Called Party Number
Type of number: Unknown
Numbering plan: ISDN/telephony numbering plan
Digits: 22101010

11:57:26.825
<- Incoming
Call Reference: 0x6A0E
Message: CALL PROCEEDING
Channel Identification
Coding standard: CCITT standardized coding
Interface: Primary
Selection: Indicated channel is preferred
D-channel indicator: The channel identified is not the D-channel
Channel number: 1
Progress Indicator
Coding Standard: CCITT standardized coding
Location: Public network serving the local user
Progress Description: In-band information is now available

11:57:27.225
<- Incoming
Call Reference: 0x6A0E
Message: ALERTING
Progress Indicator
Coding Standard: CCITT standardized coding
Location: Public network serving the local user
Progress Description: In-band information is now available

11:57:27.950
<- Incoming
Call Reference: 0x6A0E
Message: CONNECT

11:57:27.950
-> Outgoing
Call Reference: 0x6A0E
Message: CONNECT ACKNOWLEDGE

11:57:36.775
-> Outgoing
Call Reference: 0x6A0E
Message: DISCONNECT
Location: Private network serving the local user
Cause: Normal call clearing (0x90)

11:57:36.825
<- Incoming
Call Reference: 0x6A0E
Message: RELEASE

11:57:36.825
-> Outgoing
Call Reference: 0x6A0E
Message: RELEASE COMPLETE

на выше стоящей станции говорят, что причина в типе отправляемого номера. Но в трассировке с LDK-300 типа номера не вижу.

1. Непонятно, причем здесь Definity??? Вызов с Definity на №22101010 нормально принят...
Куда включена LDK??? В эту Definity????

2. Так Вы трассировку снимали не для себя, а для форума???:D
Тогда лучше не пользоваться опцией "n" (якобы расшифровкой).
Тем паче, что Вы отрезали собственно значение Setup...

Нужно снять след. трассировки:
mon> t d <Enter> (отмена предыдущих установок для трассировки)

mon> t b 08 <Enter> (без опции "n")

для 2-х входящих вызовов: по номеру 2хххххх и 3хххххх

3. Как принимаете вход. вызовы:
- что прописано в ПГМ202 (MSN) ??
- что прописано в ПГМ143/4 ??
- что прописано в ПГМ143/5 ??
- что прописано в ПГМ201 ??

4. 2101010?? Неужто "Мир Телеф. Станций" решился подключится по потоку???? :D

1. c Definity вызов проходит в город, с LDK-300 вызов в город не проходит. Обе станции стоят в разных офисах и по потоку Е1 каждая соеденена с М-200 (конвертор сигнализации). далее через коммутатор в ТФОП, т.е. схема исходящей связи у них одинаковая.

3.
- что прописано в ПГМ202 (MSN) ?? - пусто здесь
- что прописано в ПГМ143/4 ?? - без преобразования (1)
т.е. принимаю 4 цифры сразу на внутренний номер

формирую АОН:
ПГМ143/1,2 - поставил 01
ПГМ201 в ячейке 01 поставил первую цифру номера - 1
ПГМ114/12 (ISDN CLI STA) - для каждого номера три последние цифры номера. Для 1536 стоит 536.

4. У них стоит приветствие на входе, да и номер легкий:)

star-mark пишет
1. c Definity вызов проходит в город, с LDK-300 вызов в город не проходит. Обе станции стоят в разных офисах и по потоку Е1 каждая соеденена с М-200 (конвертор сигнализации). далее через коммутатор в ТФОП, т.е. схема исходящей связи у них одинаковая.
:confused:
Так все-таки о каких вызовах идет речь???
О входящих на LDK??? Или об исходящих с LDK ???

На трассировке представлены входящие вызовы на LDK, а Вы сейчас говорите о невозможности исходящей связи с LDK... Уточните.

Связь исходящая изначально

IE_CALLING_NO
1536 - кто звонит

IE_CALLED_NO
22101010 - куда звонит

Так если проблема с исходящей связью, зачем же Вы тогда снимаете на LDK трассировку входящего вызова???:confused: :mad:

Уважаемый harris!
Делаю вызов с номера 1536 на номер 2101010.
Снимаю трассировку. Что попадает в отчет- выкладываю здесь.
По каким параметрам Вы определили, что трассировка по входящему вызову?

Ё-мое....:( Категорически прошу пардону... Я наврал.:o
Виноват, позор на мою седую голову... Нельзя одновременно разбираться с несколькими вопросами.
На трассировку взглянул бегло, плюс эта т.н. "расшифровка" меня с толку сбивает... Без нее гораздо понятнее... Насчет городской нумерации 2ххххххх и 3ххххххх сразу не въехал - подумал, что это ваши входящие номера.

Все верно. Это исходящий вызов.
А что не устраивает провайдера???
Формат какого номера его не удовлетворяет: Calling (вызывающий) или Called (вызываемый)???
Есть небольшие различия:
Calling Party:
на Definity: тип номера =National, нум. план= ISDN/Telephony
на LDK : тип номера = Subscriber, нум. план= Uknown
(правда непонятно, зачем для №1350 от Definity идет тип National ??)

Called Party:
на Definity: тип номера =Uknown, нум. план= ISDN/Telephony
на LDK : тип номера =Uknown, нум. план= Uknown

Если провайдера не устраивает тип нумерационного плана, то пропишите его равным = ISDN/Telephony в ПГМ143/8 (F1 и F2).

А не может ли быть дело просто в том, что у провайдера не прописан маршрут для 2хххххх ???

бывает..
Провайдер-чел. который рулит M-200 и коммутатором говорит,что оба номера надо подкрутить.
Версия 3.8 - вот только поставил новую плату проца MPBN
с версией 3.8Ah и залил на нее 3.8Bf. Все настройки забил по-новой. Значит - с нуля.
Enbloc Prefix Table не использовал, т.к. ПГМ205 даже найти не могу.
Трассировки содержат комбинации : и ) - что расценивается как смайлик. Сюда не вставить - Ругается,что много смайлов.

ОК. Я поправил свой предыдущий ответ. Посмотрите выше по поводу Типа Нумерационного Плана.-- ПГМ143/8.

В версии 3.8 добавлена таблица префиксов - ПГМ205. Там можно выставить нужные поля для Номера Вызываемого Абонента (Called) по-разному, в зависимости от набранного номера. При этом можно запретить станции занимать канал, если пользователь не набрал номер полностью (указывается необходимый min и max набранных цифр..).
Вы наверное используете PC-Admin старой версии (3.7). Тогда можно войти с системника...
А в новую версию PC-Admin'а (3.8)программа ПГМ205 уже добавлена.
Выбор таблицы префиксов - ПГМ143/16.

по типу нумерационного плана посмотрел, спасибо.

версия PC-Admin действительно была 3.7. заменил на 3.8 -программа ПГМ205 появилась.

Вот еще трассировка с MD-110 в другом офисе. Организация исходящей связи та же. на выше стоящей станции просят сравнивать настройки с ней. Звонок с 1132 прошел на 2101010.

Outgoing Message: SETUP
Call Reference: 29 33 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

SENDING COMPLETE IE:

BEARER CAPABILITY IE:
Coding Standard: CCITT standardized
Information Transfer Capability: Speech
Transfer Mode: Circuit-mode / Call independent signalling connection
Information Transfer Rate/Circuit Mode: 64 kbit/s
Layer 1 Protocol Identification: User information layer 1 protocol
Recommendation G.711 A-law

CHANNEL ID IE:
Interface Identifier Present: Interface implicitly identified; the interface which includes the D-channel carrying this information element is indicated.
Interface Type: Primary rate interface
Preferred/Exclusive: Exclusive; only the indicated channel is acceptable
D-channel Indicator: The channel identified is not the D-channel
Information Channel Selection/Primary Interface: As in following octets
Coding Standard: CCITT standard
Number: Channel is indicated by the number in the following octet
Channel Type: B-channel units
Channel number: 23

PROGRESS INDICATOR IE:
Coding Standard: CCITT standard
Location: Local private network e.g., PBX
Progress Description: Originating address is non-ISDN

CALLING PARTY IE:
Type of Number: Local Directory Number
Numbering Plan Identification: ISDN numbering plan
Presentation Indicator: Presentation Allowed
Spare, reserved
Screening Indicator: User provided, verified and passed
Calling Party Number: 1132

CALLED PARTY IE:
Type of Number: Unknown
Numbering Plan Identification: ISDN numbering plan
Called Number: 22101010

Incoming Message: CALL PROCeeding
Call Reference: 29 33 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

CHANNEL ID IE:
Interface Identifier Present: Interface implicitly identified; the interface which includes the D-channel carrying this information element is indicated.
Interface Type: Primary rate interface
Preferred/Exclusive: Exclusive; only the indicated channel is acceptable
D-channel Indicator: The channel identified is not the D-channel
Information Channel Selection/Primary Interface: As in following octets
Coding Standard: CCITT standard
Number: Channel is indicated by the number in the following octet
Channel Type: B-channel units
Channel number: 23

PROGRESS INDICATOR IE:
Coding Standard: CCITT standard
Location: Local network
Progress Description: In-band information or an appropriate pattern is now available

Incoming Message: ALERTing
Call Reference: 29 33 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

PROGRESS INDICATOR IE:
Coding Standard: CCITT standard
Location: Local network
Progress Description: In-band information or an appropriate pattern is now available

Incoming Message: CONNect
Call Reference: 29 33 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol

Outgoing Message: CONNect ACKnowledge
Call Reference: 29 33 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

Outgoing Message: DISConnect
Call Reference: 29 33 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

CAUSE IE:
Coding Standard: CCITT standard
Location: Local private network eg PBX
Cause Value: Normal event
Cause Values, CCITT Standard: Normal clearing

Incoming Message: RELease
Call Reference: 29 33 (CR Flag Set)
Protocol Discriminator: Q.931 user-network call control protocol
Outgoing Message: RELease COMplete
Call Reference: 29 33 (CR Flag Not Set)
Protocol Discriminator: Q.931 user-network call control protocol

Попутно вопрос:
расшифровка трассировки на Ldk-300 даже при наличии планки памяти оставляет желать лучшего.
нет ли дополнительной программы для расшифровки, как в случае с Definity и MD-110?
По каким элементам трассировки видно, например, тип номера и номерной план номера А и номера Б в сообщении SETUP?

По поводу трассировки - я уже предупреждал, что даже наличие памяти не даст желаемой полноты расшифровки.
Никаких дополнительных программ нет.
Но можно вполне обходится и так.
На трассировке представлены сообщения в 16-тиричном коде. Они полностью соотвествуют тому, что передается в D-канале. Способ формирования сообщений и все информ. поля расписаны в рекомендациях Q.931 (или ETSI 300102).
Подробная же трассировка (побитная) требуется далеко не всегда..., при этом отслеживать трассу при таком обилие текста (зачастую лишнего) гораздо труднее, ИМХО.

Тип Номера и Тип Нумерационного Плана - это битовые поля, которые входят в информ. элементы Сalling Party и Сalled Party.
Например, 70 09 80 32 32 31 30 31 30 31 30 - номер вызываемого абонента.
80'h = 1 000 0000' b
000-Тип Номера=Unknown,
0000 - Тип Плана Нумерации=Unknown

А с какой стати еще разбираться с трассировкой MD-110???
Вообще-то это обязанность провайдера выяснить и сказать, что именно его не удовлетворяет в Setup'е от LDK. ИМХО, это он должен озвучить свои требования...
MD-110 также, как и Definity, отдает номера с типом Плана Нумерации = ISDN/Telephony - я Вам про это уже писал.

Но MD-110 дает в Calling Party:
указатель просмотра (Screening Indicator) = verified and passed (номер проверен и подтвержден)
а LDK выдает указатель = not screened (номер не проверялся).
Может это вызывает отторжение у провайдера. Это ж зависит от его настроек.
Вы можете изменить Screening Indicator на LDK --> ПГМ143/14 (прописать там = 1 - User provided, verified and passed)

Уважаемый harris!
При изменении Screening Indicator ПГМ143/14 = 1 связь заработала!
Возникает вопрос: на версии 3.6 этот параметр по умолчанию в каком значении?
Потому как при поднятии версии с 3.6 на 3.8 программировал все параметры одинаково.
А провайдер хоть и свой, но удельная масса у него тяжелая-чугуний одним словом..
ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО!

Да, на старых версиях прошивок, до 3.7С, значение Screen_Indicator'а было зачем-то жестко привязано к способу набора:
при Overlap индикатор = 0,
а при Enbloc индикатор =1.
У Вас использовался Enbloc (с индикатором =1).
Начиная с версии 3.7С, по нашему запросу, софт изменили: теперь значение индикатора никак не связано со способом посылки номера и устанавливается в зависимости от требований провайдера.
Но при замене версии значение индикатора стало =0 (по умолчанию).

star-mark пишет
А провайдер хоть и свой, но удельная масса у него тяжелая-чугуний одним словом..

:D
Ну бывает и такое. Наша опорная, например, тоже требует verified and passed, ничего не поделаешь. Главное, чтобы провайдер говорил человеческим языком, что не так. А не стандартную фразу "у нас всё работает, настраивайте свою АТС."

ЗЫ- на MD110 тоже человеческой расшифровки трассировки нет, приходится пользоваться всем известным "Перелыгинским" расшифровщиком. Может на MX-ONE что то изменилось в лучшую сторону....

И что удивительно... Большинство провайдеров не обращает внимания на Screening Indicator. Насколько я знаю, больше половины от общего числа установленных станций LDK работают Overlap'ом, т.е. с индикатором =0 (user provided, not screened). И никаких претензий от провайдеров не было. Все равно ведь провайдер должен сам контролировать, проверять и при необходимости подставлять нужный номер.
Первый раз вопрос возник только в прошлом году, ... в Минске...:)