Поиск  Правила  Войти
Форум » Alcatel-Lucent OmniPCX Enterprise » Транковые группы

Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

   RSS
Сброс вызова при звонке сотовому абоненту
 
#1
01.03.2019 15:29:03
Добрый день! Может кто, что подскажет...
Есть проблема с дозвоном удаленного абонента ОХЕ (R8.0.1) через центральную OXE(R10.1.1) по потоку Е1 на сотового оператора. Вызов на сотовом звякнув сразу отбивается, номер звонящего высвечивается.
Удаленная АТС ОХЕ (R8.0.1) и центральная OXE(R10.1.1) работают по IP каналу.
Оператор говорит, что инициирует отбой наша сторона:

Feb 25 2019 19:52:15.350.18+00:00 UserName-AR1220EV VOICE/7/VSP:DEBUG: [LOGID=0xa
2c][dss1_com.c 5083][ISDN PRA Q931]:    RX <-- DISCONNECT
Feb 25 2019 19:52:19.370.22+00:00 UserName -AR1220EV VOICE/7/VSP:DEBUG: [LOGID=0xa
2c][dss1_dsm.c 12081]                    Cause Value : Recovery on timer expiry

На центральной OXE(R10.1.1) есть еще поток Е1 в сторону городского оператора, в город от того же абонента вызов идет без проблем.

Вот трассировка вызова на сотового абонента с удаленной АТС:
mtracer started ...
(502397:000001) MTRACER host (10.59.101.66, yarosl-13), version: R8.0.1-g1.503-11-ru-c80s1
(502397:000001) MTRACER num: 012, time: 2019/01/20 09:14:41, loss: 0%
____________________________________________________________­__________________
| (502426:000002) 1040: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 124  desti: 0  source: 15  cryst: 2  cpl: 0  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  01 64
|____________________________________________________________­__________________
|
| [9f] Non-locking shift. codeset : 7
| [a2] EI_IP_TYPE_TERM
| [9f] Non-locking shift. codeset : 7
| IE:[05] EI_IP_INFOS (l=9) -> G729  Ece 1 Vad 0 Profil 2, IPv4 :172.10.10.67.
| [9f] Non-locking shift. codeset : 7
| IE:[06] EI_IP_PAYLOADS (l=1) -> G723 Ece 1 Vad 0
| [9f] Non-locking shift. codeset : 7
| IE:[07] EI_IP_QOS (l=3) b8 a0 00
| [9f] Non-locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=30)
|    -> stop_packet=0 stop_rtp=0 h323=0 wc=0 rf=0 udp=1 rqm=0
|    -> Transm_Bande=1 detection_Q23=1 dtmf_payload=96
|    -> Port RTP     = 32584, IPv4 :    10.   10.  101.   68.
|    -> Port RTCP SR = 32585, IPv4 :    10.   10.  101.   68.
|    -> Port RTCP RR = 32585, IPv4 :    10.   10.  101.   68.
|    -> Port Fax     = 32587, IPv4 :    10.   10.  101.   68.
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a8 83 81 -> T2 : No B channel
| IE:[28] DISPLAY (l=9)  `4169 Test`
| IE:[6c] CALLING_NUMBER (l=10)  ->  01  81  Num : 4169
| IE:[70] CALLED_NUMBER (l=9)  ->  81  Num : 0124
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|____________________________________________________________­__________________
____________________________________________________________­__________________
| (502427:000005) Physical-Event :
| long: 21  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  81 64
|____________________________________________________________­__________________
|
| IE:[18] CHANNEL (l=1)  a8 -> T2 : No B channel
|____________________________________________________________­__________________
____________________________________________________________­__________________
| (502460:000006) Physical-Event :
| long: 27  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : PROGRESS (03)  Call ref :  81 64
|____________________________________________________________­__________________
|
| IE:[1e] PROGRESS_ID (l=2) 80 88
| [97] Locking shift. codeset : 7
| IE:[0a] EI_RTP_INFO (l=2)
|    -> stop_packet=0 stop_rtp=0 h323=1 wc=0 rf=0 udp=0 rqm=0
|    -> Transm_Bande=0 detection_Q23=1
|____________________________________________________________­__________________
____________________________________________________________­__________________
| (502469:000007) Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 2  cpl: 0  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  81 64
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 a9 -> [a9] TEMPORARY FAILURE
|____________________________________________________________­__________________
____________________________________________________________­__________________
| (502469:000008) 1040: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 2  cpl: 0  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  01 64
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­__________________

Какой-то таймер не дожидаясь даёт отбой?? С сотовыми абонентами обмениваемся короткими номерами, с центральной АТС звонки на сотовые идут без проблем, проблема только с абонентами удаленной АТС.
 
 
Страницы: Пред. 1 2 3 След.
Ответы
 
#16
05.03.2019 11:20:35
Цитата
vad написал:

Есть еще удаленные станции, чтоб посмотреть - с чем связано? И еще - если при звонках пользоваться NPD с NPI/TONE - ISDN National - что-то меняется?
Удаленные станции есть ещё, но везде так с обрывом звонка. Трассировки сниму, надо сравнить, а вдруг есть ваианты, АТС разных релизов стоят. Маршрут с ARS, NPD пробовал во всех вариантах.
НО, у коллег (далеко, не в нашем районе) аналогичная схема с тем же железом, каналами и провайдером работает на ура, и настройки (основные, созванивались, сравнивали) совпадают.
 
 
 
#17
05.03.2019 11:47:38
С настройками - там нечего сравнивать. А вот трассировки - они будут разные. У вас зачем-то два одинаковых Progress Id приходят от провайдера. У кого-то сразу Alert с Progress Id приходит.
 
 
 
#18
05.03.2019 13:12:36
Цитата
Михаил написал:
НО, у коллег (далеко, не в нашем районе) аналогичная схема с тем же железом, каналами и провайдером работает на ура
может у коллег везде сеть из isdn а не h323

трассировки звонка разные

на транзитной атс (где е1) уходит два Progress в h323, а на конечной атс в трассировке видно что пришел только один Progress

включите Specific EI status for GSM на конечной атс, где располагается указано в посте 4
Пути IP-пакета неисповедимы
 
 
 
#19
05.03.2019 15:28:55
Цитата
error написал:

на транзитной атс (где е1) уходит два Progress в h323, а на конечной атс в трассировке видно что пришел только один Progress

включите Specific EI status for GSM на конечной атс, где располагается указано в посте 4
На конечной АТС в System/Other System Param/System Param... нет пункта Specific EI status for GSM (версия АТС R8.0.1).
 
 
 
#20
05.03.2019 16:07:28
Тогда попробовать отписать в мегафон спецам, у меня когда то данная проблема проявилась в 11 году примерно с МТС. https://www.intersyst.ru/support/forum/messages/forum13/topic787/message6239/#message6239  Я отписал ребятам в областной МТС и они полечили данную проблему. Сейчас спасибо хоть ALU добавили этот крыжик для GSM в новых релизах.
 
 
 
#21
05.03.2019 20:05:30
Цитата
Михаил написал:
На конечной АТС в System/Other System Param/System Param... нет пункта Specific EI status for GSM (версия АТС R8.0.1).
так...приплылы

у удаленной OXE R8.0.1-g1.503-11 что ни есть староват чтобы решать какие-то проблемы

поднимайте до актуального R8.0.1: G1.301.35.h
а там глядишь и "как бабка наговорила" всё нормализуется
Пути IP-пакета неисповедимы
 
 
 
#22
06.03.2019 10:34:37
Не увеличивайте энтропию.
Крыжик "Specific EI status for GSM"  не имеет отношения к PROGRESS:
Код
In case of GSM call, this parameter at « true » allows to accept a message «connect» which includes a
«bearer capabitity» to move in conversation.
When this parameter is at « false »,the oxe send a message « status » and the message « connect ack » is
not sent, thus, the conversation status is not established and enquiry call / transfer is not possible.  
Изменено: Username - 06.03.2019 10:34:54
 
 
 
#23
06.03.2019 11:16:53
Цитата
Username написал:
Не увеличивайте энтропию.
полнота вопроса прямо пропорциональная ответу
дело уже не в "Specific EI status for GSM" в том какой софт стоит на АТС , по факту у автора поста именно тот который является стартовый для эксплуатации

по крайне мере раньше было "если патч менее чем 15 для промышленной эксплуатации никуда не годится"
Пути IP-пакета неисповедимы
 
 
 
#24
06.03.2019 11:32:57
Имеем:
  • вызов с периферийного узла на абонента центрального узла работает
  • вызов с центрального узла на мобильного абонента работает
Проблема только в транзитном вызове.
Так ТС-у уже писали Метод перебора всех параметров когда-нибудь даст, конечно, результат., при наличии достаточного количества свободного времени и усидчивости. Но анализ конкретно проблемы, почему периферийный узел присылает DISCONNECT при транзитном вызове даст результат гораздо быстрее.
 
 
 
#25
06.03.2019 13:53:19
g1.503.35.h или k надо ставить, т.к., как минимум в 14-м патче исправлено:
double progress id not supported on ISDN linked invalid info e4
 
 
 
#26
07.03.2019 10:42:28
Цитата
etc написал:
g1.503.35.h или k надо ставить, т.к., как минимум в 14-м патче исправлено:
double progress id not supported on ISDN linked invalid info e4
Так, значит надо обновляться. А Алкатель официально где-то выкладывает патчи? или практика получения обновлений сложилась только через поставщика?
 
 
 
#27
07.03.2019 11:02:43
Выкладывает, только доступ открыт для партнеров.
 
 
 
#28
28.03.2019 15:38:44
Цитата
Михаил написал:
Цитата
Михаил, удалось ли победить проблему исходящих на мобильные через другую ноду?

Вопрос ко всем:
Сейчас наблюдаю аналогичную проблему. При звонках с удаленной АТС (Москва R11.0.1-k1.520-36-a-ru-c80s1) через локальную (Пермь R11.0.1-k1.520-36-a-ru-c80s1) на мобильные номера через поток E1 (ISDN all countries) вызовы сбрасываются, сбрасываются и отображаются как пропущенные или проходят нормально.
При звонках с локальной АТС на мобильный эта проблема так же появляется, но значительно реже. Если "развернуть" все звонки и пустить через поток, подключенный в Москве, то все вызовы проходят нормально. Проблем с городскими номерами не наблюдали вообще.

Лог проблемного звонка на мобильный МТС с Пермской АТС
28.03.19 13:51:35
1
192.168.0.11
~t3label: 4399
____________________________________________________________­__________________
| (244314:000831) 1210: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 56  desti: 0  source: 15  cryst: 1  cpl: 6  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : SETUP [05]    Call ref :  24 f5
|____________________________________________________________­__________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[6c] CALLING_NUMBER (l=12)  ->  21  81  Num : 34223XXXXX
| IE:[70] CALLED_NUMBER (l=12)  ->  a1  Num : 895233XXXXX
| IE:[7d] HLC (l=2) 91 81
| [a1] Sending complete
|____________________________________________________________­__________________

13:51:35
~t3label: 4400
____________________________________________________________­__________________
| (244315:000833) Concatenated-Physical-Event :
| long: 23  desti: 0  source: 0  cryst: 1  cpl: 6  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : CALL PROC (02)  Call ref :  a4 f5
|____________________________________________________________­__________________
|
| IE:[18] CHANNEL (l=3)  a9 83 81 -> T2 : B channel 1 exclusive
|____________________________________________________________­__________________

13:51:39
~t3label: 4401
____________________________________________________________­__________________
| (244358:000834) Concatenated-Physical-Event :
| long: 22  desti: 0  source: 0  cryst: 1  cpl: 6  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : DISCONNECT [45]  Call ref :  a4 f5
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 80 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­__________________

13:51:39
~t3label: 4402
____________________________________________________________­__________________
| (244359:000835) 1210: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 1  cpl: 6  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : RELEASE [4d]   Call ref :  24 f5
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­__________________

13:51:39
~t3label: 4403
____________________________________________________________­__________________
| (244360:000836) Concatenated-Physical-Event :
| long: 18  desti: 0  source: 0  cryst: 1  cpl: 6  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : REL COMP [5a]  Call ref :  a4 f5
|____________________________________________________________­__________________
Изменено: zarnicin - 28.03.2019 15:44:19
 
 
 
#29
29.03.2019 06:25:06
Не задавали вопрос провайдеру?  У вас после Call Proc - ни Progress Id, ни Alert не пришли, город просто прислал дисконнект.
А при звонках через Москву - идет другое взаимодействие и других провайдеров.
 
 
 
#30
11.04.2019 13:59:54
Провайдер говорит. что дисконнект от нас идет.
 
 
 
Страницы: Пред. 1 2 3 След.
Читают тему