Продолжая реализовывать связку LDK-300 + Asterisk столкнулся со следующей проблемой:
При внутреннем вызове Asterisk -> LDK к CallerID атсерисковского номера почему-то добавляется 9-ка
Звоню с номера 445 (*) на 222 (ldk) получаю на экране 9445.

Параметры LDK-300
LDK-300 System
Version GS30P-3.6Df JUL/06
PGM 140/1(Type) = ISDN DID

PGM 141/5(CO Tyoe) = PBX

PGM 143/1,2 (CLIP|COLP tbl indx) = 50
PGM 143/3 (Type of Calling Number) = Unknown
PGM 143/4 (DID Conversion Type) = 1
PGM 143/5 (DID Remove No.) = 0
PGM 143/6 (ISDN enblock send) = OFF
PGM 143/7 (CLI Transit) = ORI
PGM 143/8 (Numbering Plan ID) = Unknown
ISDN SS CD = OFF
ISDN CP INBAND = OFF
CLI Type = NORMAL

PGM 146/1 (Incoming Prefix Code Insertion) = OFF
PGM 146/2 (Outgoing Prefix Code Insertion) = OFF
PGM 146/3 (ISDN Line Type) = A-Law
PGM 146/4 (Calling Sub-address) = ON
PGM 146/5 (DID Digit Receive No) = 3
PGM 146/6 (DID Digit Mask) = #***


PGM 321/1 (Networking Transfer Mode) = REROUTE

PGM 322/1 (Net CO group) = 1
PGM 322/4 (Net CO type) = NET (QSIG ключ активирован)

PGM 324/1 (System usage) = NET
Для номеров астера
PGM 324/2 (Numbering plan code) = 4**
PGM 324/3 (NET CO group) = 1
Для внутренних
PGM 324/2 (Numbering plan code) = 2#**
PGM 324/3 (NET CO group) = 0

В настройках Asterisk, параметры касающиеся потока:
pridialplan=unknown
prilocaldialplan=unknown
switchtype=euroisdn
signalling=pri_net


Трасса LDK

030579 COL 017:02 01 St:co idle (00) EVT 5 21 05 04 03 80 90 A3 18 03 A9 83
81 28 07 50 68 6F 65 6E 69 78 6C 05 00 80 34 34 35 70 04 80 32 32 32 (U0)
030579 C>02 01, D6 06 0D 18 03 A9 83 81
030579 COL 017:02 01 St:co idle (00) Ev-I:ring start P1: 0 P2: 0 EVT: 11 <
- 17,61
030579 D>02 01, C0 00 40
030579 COL 017:02 01 St:di-dialing(00) Ev-I:disa dgt P1: 2 P2: 0 EVT: 80 <
- 17,61
030580 COL 017:02 01 St:di-dialing(00) Ev-I:disa dgt P1: 2 P2: 0 EVT: 80 <
- 17,61
030580 COL 017:02 01 St:di-dialing(00) Ev-I:disa dgt P1: 2 P2: 0 EVT: 80 <
- 17,61
030580 C>02 01, D1 06 02 18 03 A9 83 81
030580 C>02 01, D0 06 01 18 03 A9 83 81
030580 COL 017:02 01 St:dd-rng req(00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <
- 17,61
11/27/12 TIME: 12:07:00
030580 COL 017:02 01 St:dd-rng req(00) Ev-I:dummy acd P1:26AF P2: 1 EVT: 0 <
- 17,61
030580 COL 017:02 01 St:dd-rng req(00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <
- 17,61
030593 COL 017:02 01 St:dd-rng req(00) Ev-I:dd rng ack P1: 0 P2: 0 EVT: 82 <
- 123,04
030593 D>02 01, C0 00 40
030593 D>02 01, C5 11 01
030731 COL 017:02 01 St:dd-wt ans (00) EVT E 05 45 08 02 81 90 (U7)
030731 C>02 01, DF 05 4D 08 02 81 90
030731 D>02 01, C1 00 00
030731 D>02 01, C5 00 00
030731 D>02 01, C5 00 00
030733 COL 017:02 01 St:dd-wt ans (00) EVT :E0 05 5A 08 02 81 90 (U19)
030733 D>02 01, C5 00 00
030736 COL 017:02 01 St:dd-wt ans (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <
- 17,61
030736 D>02 01, C5 00 00


Трасса Asterisk

PRI Span: 2
PRI Span: 2 > DL-DATA request
PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=37
PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 2 > Message Type: SETUP (5)
PRI Span: 2 TEI=0 Transmitting N(S)=3, window is open V(A)=3 K=7
PRI Span: 2
PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=37
PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 2 > Message Type: SETUP (5)
PRI Span: 2 > [04 03 80 90 a3]
PRI Span: 2 > Bearer Capability (len= 5) [ Ext: 1 Coding-Std: 0 Info transfer capability: Speech (0)
PRI Span: 2 > Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
PRI Span: 2 > User information layer 1: A-Law (35)
PRI Span: 2 > [18 03 a9 83 81]
PRI Span: 2 > Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0
PRI Span: 2 > ChanSel: As indicated in following octets
PRI Span: 2 > Ext: 1 Coding: 0 Number Specified Channel Type: 3
PRI Span: 2 > Ext: 1 Channel: 1 Type: NET]
PRI Span: 2 > [28 07 50 68 6f 65 6e 69 78]
PRI Span: 2 > Display (len= 7) [ Phoenix ]
PRI Span: 2 > [6c 05 00 80 34 34 35]
PRI Span: 2 > Calling Party Number (len= 7) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
PRI Span: 2 > Presentation: Presentation allowed, User-provided, not screened (0) '445' ]
PRI Span: 2 > [70 04 80 32 32 32]
PRI Span: 2 > Called Party Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '222' ]
PRI Span: 2 q931.c:6291 q931_setup: Call 32770 enters state 1 (Call Initiated). Hold state: Idle

PRI Span: 2
PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=10
PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 2 < Message Type: SETUP ACKNOWLEDGE (13)
PRI Span: 2 < [18 03 a9 83 81]
PRI Span: 2 < Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0
PRI Span: 2 < ChanSel: As indicated in following octets
PRI Span: 2 < Ext: 1 Coding: 0 Number Specified Channel Type: 3
PRI Span: 2 < Ext: 1 Channel: 1 Type: NET]
PRI Span: 2 Received message for call 0x16f60c60 on link 0x16b5b700 TEI/SAPI 0/0
PRI Span: 2 -- Processing IE 24 (cs0, Channel ID)
PRI Span: 2 q931.c:9141 post_handle_q931_message: Call 32770 enters state 2 (Overlap Sending). Hold state: Idle
Span 2: Processing event PRI_EVENT_SETUP_ACK

PRI Span: 2
PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=10
PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 2 < Message Type: CALL PROCEEDING (2)
PRI Span: 2 < [18 03 a9 83 81]
PRI Span: 2 < Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0
PRI Span: 2 < ChanSel: As indicated in following octets
PRI Span: 2 < Ext: 1 Coding: 0 Number Specified Channel Type: 3
PRI Span: 2 < Ext: 1 Channel: 1 Type: NET]
PRI Span: 2 Received message for call 0x16f60c60 on link 0x16b5b700 TEI/SAPI 0/0
PRI Span: 2 -- Processing IE 24 (cs0, Channel ID)
PRI Span: 2 q931.c:8776 post_handle_q931_message: Call 32770 enters state 3 (Outgoing Call Proceeding). Hold state: Idle
Span 2: Processing event PRI_EVENT_PROCEEDING
-
PRI Span: 2
PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=10
PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 2 < Message Type: ALERTING (1)
PRI Span: 2 < [18 03 a9 83 81]
PRI Span: 2 < Channel ID (len= 5) [ Ext: 1 IntID: Implicit Other(PRI) Spare: 0 Exclusive Dchan: 0
PRI Span: 2 < ChanSel: As indicated in following octets
PRI Span: 2 < Ext: 1 Coding: 0 Number Specified Channel Type: 3
PRI Span: 2 < Ext: 1 Channel: 1 Type: NET]
PRI Span: 2 Received message for call 0x16f60c60 on link 0x16b5b700 TEI/SAPI 0/0
PRI Span: 2 -- Processing IE 24 (cs0, Channel ID)
PRI Span: 2 q931.c:8641 post_handle_q931_message: Call 32770 enters state 4 (Call Delivered). Hold state: Idle
Span 2: Processing event PRI_EVENT_RINGING

PRI Span: 2 q931.c:7092 q931_hangup: Hangup other cref:32770
PRI Span: 2 q931.c:6849 __q931_hangup: ourstate Call Delivered, peerstate Call Received, hold-state Idle
PRI Span: 2 q931.c:6038 q931_disconnect: Call 32770 enters state 11 (Disconnect Request). Hold state: Idle
PRI Span: 2
PRI Span: 2 > DL-DATA request
PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9
PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 2 > Message Type: DISCONNECT (69)
PRI Span: 2 TEI=0 Transmitting N(S)=4, window is open V(A)=4 K=7
PRI Span: 2
PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9
PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 2 > Message Type: DISCONNECT (69)
PRI Span: 2 > [08 02 81 90]
PRI Span: 2 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
PRI Span: 2 > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]

PRI Span: 2
PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=9
PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent to originator)
PRI Span: 2 < Message Type: RELEASE (77)
PRI Span: 2 < [08 02 81 90]
PRI Span: 2 < Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
PRI Span: 2 < Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
PRI Span: 2 Received message for call 0x16f60c60 on link 0x16b5b700 TEI/SAPI 0/0
PRI Span: 2 -- Processing IE 8 (cs0, Cause)
PRI Span: 2 q931.c:8942 post_handle_q931_message: Call 32770 enters state 0 (Null). Hold state: Idle
Span 2: Processing event PRI_EVENT_HANGUP
PRI Span: 2 q931.c:7092 q931_hangup: Hangup other cref:32770
PRI Span: 2 q931.c:6849 __q931_hangup: ourstate Null, peerstate Release Request, hold-state Idle
PRI Span: 2
PRI Span: 2 > DL-DATA request
PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9
PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 2 > Message Type: RELEASE COMPLETE (90)
PRI Span: 2 TEI=0 Transmitting N(S)=5, window is open V(A)=5 K=7
PRI Span: 2
PRI Span: 2 > Protocol Discriminator: Q.931 (8) len=9
PRI Span: 2 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 2 > Message Type: RELEASE COMPLETE (90)
PRI Span: 2 > [08 02 81 90]
PRI Span: 2 > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
PRI Span: 2 > Ext: 1 Cause: Normal Clearing (16), class = Normal Event (1) ]
PRI Span: 2 q931.c:7092 q931_hangup: Hangup other cref:32770
PRI Span: 2 q931.c:6849 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
PRI Span: 2 Destroying call 0x16f60c60, ourstate Null, peerstate Null, hold-state Idle


Не пойму, откуда берется дополнительная 9-ка, вроде везде должен проходить 3-х значный номер.
Причем трехзначный номер появлялся на дисплее трубки. Но не могу сопоставить, что при этом менялось.

Заранее благодаренза помощь , т.к. уже сломал себе голову.

1) Имеется в виду, что именно на дисплее DECT-трубки высвечивается 9445 ??
На дисплее системного телефона номер отображается нормально как 445 ??
Если да, то ничего с этим не поделаешь.... Это небольшой баг, который проявляется как раз на DECT-трубках !!
2) У Вас связка между Астером и LDK (а не между двумя LDK).
Поэтому:
- лицензия на QSIG - это была лишняя трата средств. Это не нужно в случае связки LDK с другим АТС других производителей. Т.к. LDK не поддерживает доп. сервис (QSIG, Supplementary Features) c другими производителями, а только между станцими LG.
Поэтому, во избежание лишних проблем:
- в ПГМ320/1 нужно выключить опцию NET Enable !!
- в ПГМ321/1 прописать опцию NET Transfer Mode = JOIN (вместо Reroute)!!

1) Попробуйте посмотреть настройки самой трубки.
Если там есть параметр CO CODE (Edit CO Code), то проверьте его.
Если там прописана 9-ка, то удалите ее (удалите прописанные в трубки коды доступа к СО).

Именно так и есть. Грустно. Жалко, что на трубке я пару раз таки видел 445 без девятки.



Ок, поправим, хотя тестовом режиме проблем не возникало.
Спасибо за оперативный ответ!

Я дописал ответ (см. выше) - проверьте настройки самой трубки !! (Edit CO Code !!)

К сожалению там было пусто. Попробовал туда записать наугад различные цифры, 1,0,8. Все равно вижу 9445.
9445 и на не LG трубке (Panasonic).
Заодно с помощью установки отличного от стандартного рингтона, удалось понять, что звонок определяется как EXT(внешний).

Так 9-ка там, как раз, потому, что вызов внешний.
Только, выходит, дело не в трубке(я ранее думал, что это на фирменных трубках так), коль и на трубках Panasonic 9-ка впереди.

Непонятно почему он считается внешним. Хотя как минимум должен считаться сетевым. Есть подозрение, проблема где-то на рубеже DialPlan и Type Of Number. Но сейчас на выходе с астера и на в ходе в LG идет Unknown.

Так же не уверен, но помоему, эта девятка выпрыгнула после внесения внутренних номеров в LCR
(в моей предыдущей теме)
Только из PGM 221 (LDT Table) я уже давно убрал записи о внутренних телефонах.

Да. Я проверил на своей тестовой станции. Это все-таки баг: при передаче CLI на DECT-абонента станция тупо подставляет перед номером код, прописанный в ПГМ107/12 (Access CO 1-st group), т.е. loop-код (9-ка, 0 или любой другой код, назначенный в ПГМ107/12).
В-общем, все "для удобства пользователя"... , хотели, "как лучше".
Ну что, нужно ли написать запрос в Корею, чтобы исправили этот баг, или это не очень существенно (и так сойдет...) ??
Ваше мнение??

К сожалению, или к счастью, последний раз прошивку меняли году эдак в 2007. Поэтому не вспомню, требовалась ли полная ручная перенастройка, или достаточно будет залить дамп через DP Upload/Download. А так же с учетом того, что процессор на MPB у нас старенький. т.е. это в пределах версии 3.6.
Если достаточно будет слить/залить бэкап и остаться на 3.6 версии, то с радостью установил бы такой патч.

Если же придется заново перерегистрировать все DECT трубки, а у нас их в районе сотн и , то лучше пусть светится девятка для удобства пользователей, я лучше им пропишу возможность набирать 9445 и 445 на один маршрут ))

Огромное спасибо за разъяснение ситуации!

Игорь, так мы ж это уже с тобой проверяли, достаточно давно...
Мое мнение я тебе уже говорил - неудобно! Как перезвонить из журнала вызовов?
Тебе, к примеру. По 9-ке у меня, совсем другая маршрутизация.

Да, Андрей, я помню. Но вроде бы и ты тогда твердо не настаивал на необходимости устранения этой ошибки...
ОК. Я напишу в Корею. Но вряд-ли они не будут исправлять это на версии 3.6. Речь может идти только о последней версии - 3.9. ИМХО.
Но все-таки я попробую запросить как для 3.9, так и для 3.6. А вдруг...

Ты уж, заодно, и для LIK проси. Думаю, и на MG так же.

В LIK вроде нормально... (на версии 5.6). Сейчас еще раз проверим.
На MG - еще не проверяли.

На 5.6 LIK не проверял, но на 5.5Gt 9-ка есть.

Мдя... Сейчас еще раз проверили на E[5].6C - есть баг.
ОК. Сделаю запрос..

Обсудил с руководством. Готовы даже перейти на 3.9.
Так что как выпустят патч, хотелось бы как-то об этом узнать. Либо из этой ветки, либо каким-то образом по телефону. Т.к. переход 3.6->3.9 нужно будет планировать более детально. в т.ч. по совместимости всех плат.

В-общем так...: разработчики готовы сделать новую опцию - [Add Loop Code to CLI] = Yes/No (default = Yes).
Если =Yes, то 9-ка (точнее Loop Code) будет посылаться перед CLI в DECT-трубку, и соотвественно, будет отображаться как LOOP CODE+Original CLI (9XXXXXXXX). И в журнал вызовов в трубке запишется также с 9-кой (для набора номера из журнала, для чего это собственно и делалось исходно). Т.е. это так, как оно и работает сейчас.
Если = No, то трубка получит оригинальный CLI без Loop Code. На дисплее и в журнале будет без 9-ки.
Что касается набора из журнала, то это зависит от многих других настроек (Networking/LCR и пр.), поэтому набор из журнала может работать или не работать как в случае, если опция = Yes, так и в случае -No (зависит от кодов доступа).
Ну что, так устроит, если будет введена эта новая опция???
Ваши мнения???

Мое мнение -вполне устроит.

Маленькое уточнение - в данном случае идет речь о ipLDK.
По LIK пока еще не было ответа из Кореи.

Для LIK, конечно, тоже интересно. Кстати, а как оно на MG?

Как раз то, что было нужно!
будем ждать от них новой версии.

Да, уже сделали.
На версии С[3].9Gh добавлена новая системная опция- ПГМ163/13 (Add Loop Code to CLI).
Если =On, то Loop-код (9) вставляется перед АОНом (как сейчас)
Если = Off, то АОН передается без Loop-кода.
Версия пока сделана для ipLDK100/300/600.
Естественно, эта опция пока отсутствует в PC-Admin'е (доступна только с системника)!!
Будет ли для 300-ки выпущена версия уровня 3.6 с аналогичной опцией - это пока под вопросом.
Для ipLDK-60 можно запросить такую же опцию (правда, я сейчас не могу проверить, как оно работает на текущих версиях).

2 lehase:
Для Вас сделали версию уровня 3.6 с новой опцией - ПГМ163/13 (Add Loop Code to CLI).
Скачайте по ссылке: http://rusfolder.com/34448712
Пароль: ipldk
Пожалуйста, не забудьте сообщить мне о результатах проверки этой версии.

Прошивка прошла на УРА, все настройки остались в строю, а лишняя цифра улетела в небытие.
Огромное спасибо!