АРТКОМ Форум > Отбиваются входящие вызовы

Greahem

24.12.2015, 14:03

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

Код

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

24.12.2015, 14:13

Cause Value = 17 User busy

Greahem

24.12.2015, 14:22

Цитата(Dron @ 24.12.2015, 15:13)

Cause Value = 17 User busy

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

Dron

24.12.2015, 14:27

Цитата(Greahem @ 24.12.2015, 14:22)

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

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

Greahem

24.12.2015, 14:28

Цитата(Dron @ 24.12.2015, 15:27)

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

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

Dron

24.12.2015, 14:33

Цитата(Greahem @ 24.12.2015, 14:28)

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

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

Greahem

24.12.2015, 14:48

Цитата(Dron @ 24.12.2015, 15:33)

Вызывались номера 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

24.12.2015, 15:48

Цитата(Greahem @ 24.12.2015, 14:48)

Да, наши.
Т.е. ситуация примерно такая: набираю 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

24.12.2015, 17:31

Цитата(Greahem @ 24.12.2015, 14:22)

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

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

Greahem

28.12.2015, 15:09

Цитата(harris @ 24.12.2015, 16:48)

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

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

Код

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

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

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

harris

28.12.2015, 15:43

Цитата(Greahem @ 28.12.2015, 15:09)

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

Код

[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 поля данных не расписаны, они же стандартны.