The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Странные подвисания ИКМ"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (VoIP)
Изначальное сообщение [ Отслеживать ]

"Странные подвисания ИКМ"  +1 +/
Сообщение от vigogne (ok) on 16-Окт-12, 09:21 
Добрый день!

Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1. Запустили их в работу по уже отлаженному сценарию, но у всех у них наблюдался такой баг: иногда связь становилась либо односторонней, либо не было вообще, хотя сигнализация проходила всегда. На большинстве из них проблема решилась сменой IOS на 12.4(24)T. Но одной это не помогло и она все также морочит нам голову.
Симптомы: не периодически, по неустановленным причинам слышимость становится либо односторонней либо пропадает совсем. Потом может либо также сама собой восстановиться, либо нет, бывает, что помогает только перезагрузка циски, либо станции (но станция очень ненадежная штука, поэтому безопаснее циску).

По дебагам в эти моменты видим такое:
Oct 16 04:16:39.565: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8  callref = 0x0014
        Sending Complete
        Bearer Capability i = 0x9090A3
                Standard = CCITT
                Transfer Capability = 3.1kHz Audio
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98393
                Exclusive, Channel 19
        Progress Ind i = 0x8283 - Origination address is non-ISDN  
        Calling Party Number i = 0x0183, '34504'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0xC1, '7459487461'
                Plan:ISDN, Type:Subscriber(local)
Oct 16 04:16:39.569: ISDN Se0/1/0:15 Q931: Received SETUP  callref = 0x8014 callID = 0x008B switch = primary-net5 interface = User
Oct 16 04:16:39.585: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x8014
        Channel ID i = 0xA98393
                Exclusive, Channel 19

И на этом стоит секунд 5-7, затем отбивается вот так:

Oct 16 04:16:54.589: ISDN Se0/1/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x8014
        Cause i = 0x8092 - No user responding
        Progress Ind i = 0x8188 - In-band info or appropriate now available
Oct 16 04:16:54.597: ISDN Se0/1/0:15 Q931: RX <- RELEASE pd = 8  callref = 0x0014
Oct 16 04:16:54.601: ISDN Se0/1/0:15 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x8014

В нормальном состоянии после CALL_PROC с указанием канала должен идти PROGRESS:

Oct 16 04:20:00.602: ISDN Se0/1/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0x801C
        Progress Ind i = 0x8282 - Destination address is non-ISDN


Вот часть конфига:
interface Serial0/1/0:15
no ip address
ip virtual-reassembly max-reassemblies 1024
encapsulation hdlc
ip route-cache policy
isdn switch-type primary-net5
isdn overlap-receiving
isdn incoming-voice voice
isdn guard-timer 4000
isdn send-alerting
isdn negotiate-bchan resend-setup
isdn bchan-number-order ascending round-robin
isdn sending-complete
isdn outgoing-voice info-transfer-capability 3.1kHz-audio
isdn outgoing display-ie
no cdp enable
!
voice-port 0/1/0:15
cptone RU
!
dial-peer voice 804534 pots
voice cut-through alert
description IK-4
destination-pattern 34T
progress_ind setup enable 3
progress_ind progress enable 8
progress_ind connect enable 8
progress_ind disconnect enable 8
incoming called-number 34
direct-inward-dial
port 0/1/0:15
forward-digits 3
!
dial-peer voice 8045 voip
voice cut-through alert
description UFSIN
destination-pattern 745..T
progress_ind setup enable 3
progress_ind progress enable 8
progress_ind connect enable 8
progress_ind disconnect enable 8
translate-outgoing called 745
modem passthrough nse codec g711alaw
session target ipv4:10.45.15.205
session transport udp
dtmf-relay h245-alphanumeric
codec g729br8 bytes 40
fax rate 9600
fax protocol cisco
ip qos dscp cs5 media
ip qos dscp cs5 signaling
ip udp checksum

Пробовали менять блок Е1 в станции, не помогло, запасного 2MFT-T1/E1 к сожалению пока нет, все потуги решить проблему с помощью конфигурации Вы видите в листинге. Мысли что делать - кончились, поэтому обращаюсь к Вам!
P.S. А firmware MFT-шки нельзя ли сменить? Поиск по этому вопросу ничего не дал...

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Странные подвисания ИКМ"  +/
Сообщение от eek email on 16-Окт-12, 10:45 
По симптомам похоже, что DSP у вас погибает (PVDM2). Бывает такое не часто, но случается.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Странные подвисания ИКМ"  +/
Сообщение от vigogne (ok) on 16-Окт-12, 10:47 
> По симптомам похоже, что DSP у вас погибает (PVDM2). Бывает такое не
> часто, но случается.

Хмм, не обрадовали :( Ну чтож, будем трясти руководство на предмет замены... Спасибо!

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Странные подвисания ИКМ"  +/
Сообщение от plohish email(ok) on 16-Окт-12, 16:59 
> Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1.

Здравствуйте. А можно не по теме?
Разве 2821 поддерживает VWIC, там же HWIC ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Странные подвисания ИКМ"  +/
Сообщение от plohish email(ok) on 16-Окт-12, 17:16 
>> Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1.
> Здравствуйте. А можно не по теме?
> Разве 2821 поддерживает VWIC, там же HWIC ?

Извините, ибо HWICs slots can also support WICs, VICs, and VWICs..

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Странные подвисания ИКМ"  +/
Сообщение от mdenisov (ok) on 16-Окт-12, 17:11 
Что-то я не пойму проблему - она в отсутствии слышимости или односторонней слышимости, или в установке соединения? Судя по предоставленному трейсу второе. Если наблюдается проблема со слышимостью, то она с этим никак не связана.

По трейсу - шлюз получает вызов из потока и пытается установить соединение. Время ожидания progress у Вас 20 секунд. Если этого мало - можно увеличить, за это отвечает таймер T310. По моему 20 секунд вполне достаточно чтобы получить какой-нибудь ответ от терминирующей точки, Вам нужно искать проблему дальше на сети, станция тут никоим образом не виновата, как скорее всего и этот шлюз.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Странные подвисания ИКМ"  +/
Сообщение от vigogne (ok) on 17-Окт-12, 07:58 
> Что-то я не пойму проблему - она в отсутствии слышимости или односторонней
> слышимости, или в установке соединения? Судя по предоставленному трейсу второе. Если
> наблюдается проблема со слышимостью, то она с этим никак не связана.
> По трейсу - шлюз получает вызов из потока и пытается установить соединение.
> Время ожидания progress у Вас 20 секунд. Если этого мало -
> можно увеличить, за это отвечает таймер T310. По моему 20 секунд
> вполне достаточно чтобы получить какой-нибудь ответ от терминирующей точки, Вам нужно
> искать проблему дальше на сети, станция тут никоим образом не виновата,
> как скорее всего и этот шлюз.

В том-то и дело, что баг такой плавающий. То односторонняя слышимость, причем они нас (мы извне) слышат, а мы их нет, то вообще никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается, сигнализация проходит, голосовой тракт проключается.
Еще были мысли в сторону организации канала, ибо там в трассе присутствует радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на ура (только во время пропадания пакетов слышится шум). Так что, как бы тоже не вариант...
А вот вариант с умирающим DSP-модулем кажется довольно правдивым...

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Странные подвисания ИКМ"  +/
Сообщение от mdenisov (ok) on 17-Окт-12, 12:19 
Предоставленный трейс к данной проблеме никакого отношения иметь не может, то о чем Вы пишите совершенно другая проблема и дебажить ее надо иначе. Для начала посмотрите sh call hist vo id $id для такого вызова с обоих сторон VoIP участка, дальше будет виднее что дебажить.

> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...

Об этом пока рано говорить, умирание DSP достаточно редкое явление и в 99% случаев сопровождается руганью в логах.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Странные подвисания ИКМ"  +/
Сообщение от vigogne (ok) on 17-Окт-12, 12:32 
> Предоставленный трейс к данной проблеме никакого отношения иметь не может, то о
> чем Вы пишите совершенно другая проблема и дебажить ее надо иначе.
> Для начала посмотрите sh call hist vo id $id для такого
> вызова с обоих сторон VoIP участка, дальше будет виднее что дебажить.
>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
> Об этом пока рано говорить, умирание DSP достаточно редкое явление и в
> 99% случаев сопровождается руганью в логах.

Хорошо, как опять начнется такое, сниму дебаг...

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Странные подвисания ИКМ"  +/
Сообщение от fantom (ok) on 17-Окт-12, 13:14 
>[оверквотинг удален]
> они нас (мы извне) слышат, а мы их нет, то вообще
> никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда
> и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается,
> сигнализация проходит, голосовой тракт проключается.
> Еще были мысли в сторону организации канала, ибо там в трассе присутствует
> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и
> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на
> ура (только во время пропадания пакетов слышится шум). Так что, как
> бы тоже не вариант...
> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...

Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!
Тем более если в этот момент на релейках "шумы"...

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Странные подвисания ИКМ"  +/
Сообщение от vigogne (ok) on 17-Окт-12, 13:17 
>[оверквотинг удален]
>> никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда
>> и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается,
>> сигнализация проходит, голосовой тракт проключается.
>> Еще были мысли в сторону организации канала, ибо там в трассе присутствует
>> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и
>> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на
>> ура (только во время пропадания пакетов слышится шум). Так что, как
>> бы тоже не вариант...
>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
> Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!

NAT там не используется, а маршрутизация хоть и ospf, но не должна перестраиваться, потому что канал один и балансировки там нет.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Странные подвисания ИКМ"  +/
Сообщение от fantom (ok) on 17-Окт-12, 15:18 
>[оверквотинг удален]
>>> сигнализация проходит, голосовой тракт проключается.
>>> Еще были мысли в сторону организации канала, ибо там в трассе присутствует
>>> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и
>>> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на
>>> ура (только во время пропадания пакетов слышится шум). Так что, как
>>> бы тоже не вариант...
>>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
>> Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!
> NAT там не используется, а маршрутизация хоть и ospf, но не должна
> перестраиваться, потому что канал один и балансировки там нет.

Смотрите логи OSPF-а, вполне может оказаться, что в одном направлении hello теряются, маршрутер сноси маршруты, а в другом направлении hello проскакивают - второй маршрутер считает, что все в норме, вот и получаете одностороннюю слышимость...
Или например коммутатор по вине релейки получает какую-нибудь хрень типа завернутого собственного bpdu и на короткое время блокирует порт...

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру