Отбиваются входящие вызовы, Диагностика ISDN-PRI на LIK-1200 Опции

[Greahem]

Добрый день, уважаемые коллеги!
Снова обращаюсь за помощью к самым опытным из вас.
С некоторых пор имеем такую проблему: отбиваются входящие из города вызовы по потокам - сразу после набора номера короткие гудки. Входящие на разные номера.
Трассировка прибором на стороне провайдера:

Код

Sequence Number: -36
Time Stamp:   0:00:55.795

ISDN:  Layer2/3    
N/T SA TEI/LIC  C/L/R Frame Msg/Pkt     Ai
N<T  0       0   007B I---- SETUP    

ISDN:  Zoom        
Dir   Frame Information                    
N<T   SAPI:0      C/R:R    (CALL-CTRL)
      TEI :0      EA1:1    (NON-AUTO)
      FRAME:I---- N(R):85  N(S):18  P/F:0
      CFLAG:0     CREF:007B  
      Protocol Discriminator.. 08          
        SETUP                              
          SEND.COMPLETE                    
          BEARER CAPABIL. LI =      3      
             Hex. value   : 90 90 A3      
             Coding stand.: CCITT coding  
             Info tr.capab: 3.1kHz audio  
             Transfer mode: Reserved      
             User info L.1: Rec.G.711 Alaw
          CHANNEL IDENT.  LI =      3      
             Hex. value   : A1 83 8E      
             Indica.Fol.Oc. Preferred      
             Not D-channel  Int.implicitly
             Other t.Bas.I.                
             Coding stand.: CCITT          
             Number/map   : Num.next Octet
             B-channel unit                
             Channel Number   142          
          PROGRESS INDIC. LI =      2      
             Hex. value   : 84 83          
             Coding stand.: CCITT standard
             Location :     publ.net.remot
             Progress desc:                
             Origin.address is non-ISDN    
          CALLING PART NB LI =     12      
             Hex. value   : 21 83 38 34 38
             32 32 30 30 30 36 35          
             Type of numb.: Reserved      
             Number. plan : ISDN/Rec.E164  
             Presentation :  Allowed      
             Screening In.:  Network Provi
            ded                            
             Number digits: 8482200065    
          CALLED PARTY NB LI =      7      
             Hex. value   : C1 35 34 34 34
             34 34                        
             Type of numb.: subscriber    
             Number. plan : ISDN/Rec.E164  
             Number digit : 544444        

ISDN:  Hex          
                                          
N<T
>02 01 24 AA 08 02 00 7B     ЫЫ$ЫЫЫЫ{
05 A1 04 03 90 90 A3 18     ЫЫЫЫЫЫЫЫ
03 A1 83 8E 1E 02 84 83     ЫЫЫЫЫЫЫЫ
6C 0C 21 83 38 34 38 32     lЫ!Ы8482
32 30 30 30 36 35 70 07     200065pЫ
C1 35 34 34 34 34 34 39     Ы5444449
84                          Ы      

__________________________________________
Sequence Number: -35
Time Stamp:   0:00:55.807

ISDN:  Layer2/3    
N/T SA TEI/LIC  C/L/R Frame Msg/Pkt     Ai
N>T  0       0        ---RR

ISDN:  Zoom        
Dir   Frame Information                    
N>T   SAPI:0      C/R:C    (CALL-CTRL)
      TEI :0      EA1:1    (NON-AUTO)
      FRAME:---RR N(R):19  P/F:0

ISDN:  Hex          
                                          
N>T
>02 01 01 26 98 C2           ЫЫЫ&ЫЫ  

__________________________________________
Sequence Number: -34
Time Stamp:   0:00:55.828

ISDN:  Layer2/3    
N/T SA TEI/LIC  C/L/R Frame Msg/Pkt     Ai
N>T  0       0   007B ----I REL.COMP.

ISDN:  Zoom        
Dir   Frame Information                    
N>T   SAPI:0      C/R:R    (CALL-CTRL)
      TEI :0      EA1:1    (NON-AUTO)
      FRAME:----I N(R):19  N(S):85  P/F:0
      CFLAG:1     CREF:007B  
      Protocol Discriminator.. 08          
        REL.COMP.                          
          CAUSE           LI =      2      
             Hex. value   : 80 91          
             Coding stand : CCITT stand.  
             Location     : user          
             Cause Class  : normal        
             User busy                    

ISDN:  Hex          
                                          
N>T
>00 01 AA 26 08 02 80 7B     ЫЫЫ&ЫЫЫ{
5A 08 02 80 91 3A 13        ZЫЫЫЫ:Ы

Трассировка на плате PRIM(указал >>>, это уже другой вызов, но отбитый так же):

Код

[50860711]L3:5, [U00]>>{0802006705A104039090A31803A183851E0284836C0C2183383438323337363638327007C13
53434303635}
[50860717]L3:5, [U06]<<{08028067021803A98385}
[50860737]L3:5, [U09]<<{08028067011803A98385}
[50860825]L3:3, [U10]>>{080200664508028290}
[50860831]L3:3, [U12]<<{080280664D08028290}
[50860836]L3:3, [U19]>>{080200665A}
[50860942]L3:0, [U00]<<{080280685A08028091}
[50860942]L_3]RELCOMP(PRESEIZE)TX (3,0,104)
[50860942]L3:255, [U00]>>{0802006805A104038090A31803A183836C0C2181383438323534333438337007C1353434363
135}
[50860974]L3:0, [U00]<<{080280695A08028091}
[50860974]L_3]RELCOMP(PRESEIZE)TX (3,0,105)
[50860974]L3:255, [U00]>>{0802006905A104038090A31803A183831E028A816C0C2181393237383931343030367007C13
534333132367D029181}
[50861060]L3:4, [U07]<<{08028062074C06418031303030}
[50861064]L3:4, [U08]>>{080200620F}
[50861113]L3:3, [U00]<<{08027F030504038090A31803A983836C084180353433313134700780363135323135}
[50861119]L3:3, [U01]>>{0802FF03021803A98383}
[50861216]L3:3, [U03]>>{0802FF0345080284911E028288}
[50861266]L3:0, [U00]<<{0802806A5A08028091}
[50861266]L_3]RELCOMP(PRESEIZE)TX (6,0,106)
>>>[50861266]L3:255, [U00]>>{0802006A05A104039090A31803A183861E0284836C0C2183383438323531373036327007C13
53434343434}
[50861430]L3:0, [U00]<<{0802806B5A08028091}
[50861430]L_3]RELCOMP(PRESEIZE)TX (6,0,107)
[50861430]L3:255, [U00]>>{0802006B05A104038090A31803A183866C0C2181383438323534333030397007C1353433393
038}
[50861461]L3:6, [U00]<<{08027F060504038090A31803A983866C084180353434343834700780353434373833}
[50861467]L3:6, [U01]>>{0802FF06021803A98386}
[50861494]L3:6, [U03]>>{0802FF06011E028488}
[50861590]L3:3, [U12]<<{08027F034D08028491}
[50861595]L3:3, [U19]>>{0802FF035A}
[50861782]L3:3, [U00]<<{08027F030504038090A31803A983836C084180353433383834700780333038383539}
[50861788]L3:3, [U01]>>{0802FF03021803A98383}
[50861856]L3:3, [U03]>>{0802FF03011E0284881E028482}
[50861893]L3:12, [U10]>>{080200614508028090}
[50861896]L3:12, [U12]<<{080280614D08028090}
[50861900]L3:12, [U19]>>{080200615A}

Вот меня интересуют сообщения
[50860942]L_3]RELCOMP(PRESEIZE)TX (3,0,104)
[50860974]L_3]RELCOMP(PRESEIZE)TX (3,0,105)
[50861266]L_3]RELCOMP(PRESEIZE)TX (6,0,106)
[50861430]L_3]RELCOMP(PRESEIZE)TX (6,0,107)

Полагаю, что в этот момент как раз были отбиты несколько вызовов, в том числе мой, но что это за сообщения и почему они появляются?
Периодичность сложно обозначить, примерно через каждые 5-8 вызовов от меня, но звоню, естессно, не я один. Проявляется чаще под нагрузкой, в обед или после работы очень сложно воспроизвести эту проблему. Вроде бы ничего существенного не менял на станциях в последнее время, ПО не обновлял. Станций 2 шт., обе LIK-1200, проблема на обеих.
Что еще сообщить?

P.S. Где-то встречал тут на форуме сообщение harris'а про доку по диагностике. Существует таковая? Поделитесь, пожалуйста.

[Dron]

Cause Value = 17 User busy

[Greahem]

Cause Value = 17 User busy

Юзер НЕ "бизи" точно. Мой вызов был сделан на DISA, свободные каналы и на VMIM, и на PRIM есть. Может быть есть еще какие-то ограничения?
Кроме того, когда пользователь действительно занят станция проигрывает сообщение "Вызываемый абонент занят" и только после него короткие гудки.
Также проверил вызовы на обычный аппарат - стоит у меня на столе, трубка не снята - такая же история.

[Dron]

Юзер НЕ "бизи" точно. Мой вызов был сделан на DISA, свободные каналы и на VMIM, и на PRIM есть. Может быть есть еще какие-то ограничения?
Кроме того, когда пользователь действительно занят станция проигрывает сообщение "Вызываемый абонент занят" и только после него короткие гудки.
Также проверил вызовы на обычный аппарат - стоит у меня на столе, трубка не снята - такая же история.

Такова причина в ваших трассировках.

[Greahem]

Такова причина в ваших трассировках.

Да это я понял, не понял почему...

[Dron]

Да это я понял, не понял почему...

Вызывались номера 544444, 544065, 544615. Ваши?

[Greahem]

Вызывались номера 544444, 544065, 544615. Ваши?

Да, наши.
Т.е. ситуация примерно такая: набираю 544444 (это диса как раз) подряд несколько раз. Первый раз, второй, третий ... пятый (восьмой) - успешно, тут же следующий вызов отбивается, тут же набираю еще раз - проходит. С номерами смаршрутизированными на LIP то же самое.
Вот еще для сравнения. Нормальный вызов:

Код

[51466307]L3:16, [U00]>>{0802001905A104039090A31803A183911E0284836C0C2183383438323531373036327007C13
53434343434}
[51466311]L3:16, [U06]<<{08028019021803A98391}
[51466326]L3:16, [U09]<<{08028019011803A98391}
[51466356]L3:16, [U07]<<{0802801907}
[51466361]L3:16, [U08]>>{080200190F}
[51466407]L3:3, [U07]<<{08028018074C06418033393132}
[51466412]L3:3, [U08]>>{080200180F}
[51466466]L3:22, [U00]>>{0802001A05A104038090A31803A183976C0C2181383438323534343130347007C1353433303
439}
[51466470]L3:22, [U06]<<{0802801A021803A98397}
[51466491]L3:22, [U09]<<{0802801A011803A98397}
[51466564]L3:16, [U10]>>{080200194508028290}
[51466569]L3:16, [U12]<<{080280194D08028290}
[51466574]L3:16, [U19]>>{080200195A}

Я так понимаю "16" после ":" - это номер линии, а первые цифры "08020019" - это некий идентификатор вызова?

А вот отбитый:

Код

[51561352]L_3]RELCOMP(PRESEIZE)TX (9,0,25)
[51561352]L3:255, [U00]>>{0802001905A104039090A31803A183891E0284836C0C2183383438323238383134397007C13
53434343434}

Что в данном случае есть 255? И почему есть только SETUP и никаких других сообщений с этим идентификатором нету?

[harris]

Да, наши.
Т.е. ситуация примерно такая: набираю 544444 (это диса как раз) подряд несколько раз. Первый раз, второй, третий ... пятый (восьмой) - успешно, тут же следующий вызов отбивается, тут же набираю еще раз - проходит. С номерами смаршрутизированными на LIP то же самое.
Вот еще для сравнения. Нормальный вызов:

Код

[51466307]L3:16, [U00]>>{0802001905A104039090A31803A183911E0284836C0C2183383438323531373036327007C13
53434343434}
[51466311]L3:16, [U06]<<{08028019021803A98391}
[51466326]L3:16, [U09]<<{08028019011803A98391}
[51466356]L3:16, [U07]<<{0802801907}
[51466361]L3:16, [U08]>>{080200190F}
[51466407]L3:3, [U07]<<{08028018074C06418033393132}
[51466412]L3:3, [U08]>>{080200180F}
[51466466]L3:22, [U00]>>{0802001A05A104038090A31803A183976C0C2181383438323534343130347007C1353433303
439}
[51466470]L3:22, [U06]<<{0802801A021803A98397}
[51466491]L3:22, [U09]<<{0802801A011803A98397}
[51466564]L3:16, [U10]>>{080200194508028290}
[51466569]L3:16, [U12]<<{080280194D08028290}
[51466574]L3:16, [U19]>>{080200195A}

Я так понимаю "16" после ":" - это номер линии, а первые цифры "08020019" - это некий идентификатор вызова?

А вот отбитый:

Код

[51561352]L_3]RELCOMP(PRESEIZE)TX (9,0,25)
[51561352]L3:255, [U00]>>{0802001905A104039090A31803A183891E0284836C0C2183383438323238383134397007C13
53434343434}

Что в данном случае есть 255? И почему есть только SETUP и никаких других сообщений с этим идентификатором нету?

Имхо, возможно, что станция не может обработать запрос на Preferred Channel.
Можете попросить провайдера, чтобы он присылал Setup с запросом Exclusive Channel ???

[vitalii]

Юзер НЕ "бизи" точно. Мой вызов был сделан на DISA, свободные каналы и на VMIM, и на PRIM есть. Может быть есть еще какие-то ограничения?
Кроме того, когда пользователь действительно занят станция проигрывает сообщение "Вызываемый абонент занят" и только после него короткие гудки.
Также проверил вызовы на обычный аппарат - стоит у меня на столе, трубка не снята - такая же история.

вы уверены, что каналы на VMIM свободны в этот момент?
у меня правда на АТС MG-100 зависают каналы на AAIB8 и тогда никто не может дозвониться т.к. все входящие нарулены на голосовое сообщение, хотя каналы на город свободны. и только после ресета платы AAIB8 каналы освобождаются и идут звонки. менял прошивки процессора, платы AAIB8 и VOIB8 - результат тот же

[Greahem]

Имхо, возможно, что станция не может обработать запрос на Preferred Channel.
Можете попросить провайдера, чтобы он присылал Setup с запросом Exclusive Channel ???

Поменяли - то же самое.

Код

[75030093]L_3]RELCOMP(PRESEIZE)TX (8,0,33)
[75030093]L3:255, [U00]>>{0802002105A104039090A31803A983881E0284836C0C2183383438323531373036327007C13
53434343333}

Еще я вспомнил, что как раз не очень давно менял метод занятия внешних линий: раньше было LAST, я выставил FIRST. Решил проверить, вернул как было - действительно, отбои прекратились. Т.е. сейчас у оператора занятие линий начинается с первой, на LIK'ах - с последней. В таком варианте работает без проблем.

И что на счет доки по диагностике?

[harris]

Поменяли - то же самое.

Код

[75030093]L_3]RELCOMP(PRESEIZE)TX (8,0,33)
[75030093]L3:255, [U00]>>{0802002105A104039090A31803A983881E0284836C0C2183383438323531373036327007C13
53434343333}

Еще я вспомнил, что как раз не очень давно менял метод занятия внешних линий: раньше было LAST, я выставил FIRST. Решил проверить, вернул как было - действительно, отбои прекратились. Т.е. сейчас у оператора занятие линий начинается с первой, на LIK'ах - с последней. В таком варианте работает без проблем.

И что на счет доки по диагностике?

Да, такое могло быть, если канал пытаются занять одновременно с двух сторон.
Обычно провайдеры занимают каналы, начиная с первого, поэтому в станции нужно использовать с последнего.

Никакой отдельной доки по диагностики, насколько я помню, не было. В корейских материалах Training был небольшой раздел по программам Monitor и Maintenance, но это доступно только официальным дистрибьюторам.
Собственно, что вы там хотите найти?? Трассировку потока на станции вы же сняли правильно. А внутри трассиррвки - данные, которые описаны в стандартных рекомендациях ETSI 300 102. В материалах Training поля данных не расписаны, они же стандартны.