Здравствуйте, уважаемые.
Имеется CS1000, включенный в узловую станцию EWSD по PRI2. К CS1000 по Н323 подключены филиалы.
При звонке из филиала в филиал по длинному номеру все работает (вызов идет ч/з EWSD, т.е.: филиал - CS1000 – EWSD - CS1000 – филиал ),
А при звонке по короткому номеру (филиал - CS1000 – филиал) на том конце телефон звенит, а при поднятии трубки тишина. У звонящего в трубке тоже тишина.
Судя по трассировкам (см. файлы), при звонке ч/з EWSD она посылает сообщение открыть b-канал, а во-втором случае b-канал не открывается.
При звонках (CS1000 – филиалы) соединение проходит корректно.
Нумерация CS1000 – 1XX, филиалы - 2ХХ.
Вопрос: как открыть b-канал ?
А что вам не нравится в трассировке ?
По ней все законнектилось и зарелизилось.
Трассировка отличная (самому нравится :) ), за одним небольшим исключением: в трубке полная тишина (при звонке по короткому № ).
Проверяйте как ходят RTP потоки.
А почему у вас эндпойнты работают через основную станцию, а не напрямую?
Филиалы в одной IP сети, они пингуются? Есть ли между ними nat, firewall ?
VOIP-шная то часть работает вроде корректно, потому как вызовы:
(H323филиал - CS1000 – EWSD - CS1000 – H323филиал) - проходят корректно (в смысле абоненты слышат друг друга);
(H323филиал - CS1000) и (CS1000 – H323филиал) - тоже корректно;
а вот:
(H323филиал - CS1000 – H323филиал) - некорректно.
Проверяйте как ходят RTP потоки.
имеется в виду трэйс с SS? Кстати, они отличаются для длинного и короткого набора (см. файлы).
трэйс для длинного набора:
трэйс для короткого набора (когда тишина).
Кстати, что значит последняя строчка?
PhoneMan
28.01.2008, 14:19
jeka5 пишет
VOIP-шная то часть работает вроде корректно, потому как вызовы:
(H323филиал - CS1000 – EWSD - CS1000 – H323филиал) - проходят корректно (в смысле абоненты слышат друг друга);
(H323филиал - CS1000) и (CS1000 – H323филиал) - тоже корректно;
а вот:
(H323филиал - CS1000 – H323филиал) - некорректно.
Разный путь медийного (RTP) трафика в первых двух и в третьем случае.
В первых двух эндпоинты (каждый из них) "общаются" с медиакартой.
В третьем должны общаться между собой напрямую. Очевидно, что сеть для такого общения не прозрачна.
jeka5 пишет
VOIP-шная то часть работает вроде корректно, потому как вызовы:
(H323филиал - CS1000 – EWSD - CS1000 – H323филиал) - проходят корректно (в смысле абоненты слышат друг друга);
(H323филиал - CS1000) и (CS1000 – H323филиал) - тоже корректно;
а вот:
(H323филиал - CS1000 – H323филиал) - некорректно.
Вы походу не совсем понимаете как работает VoIP, советую почитать что нить на эту тему.
Сигнализация у вас проходит через CS1000, а вот голос (RTP) ходит напрямую между ендпоинами, т.е. если между ендпоинами нет маршрутизации или они за Firewall (порты через которые ходит RTP закрыт) то голоса и не будет!
Вам нужно убедиться что все ендпоинты находяться в одной сети или между ними настроена маршрутизация и ни чего не закрыто Firewall.
А почему у вас эндпойнты работают через основную станцию, а не напрямую?
так настроены филиалы (надеюсь, правильно - см.файл).
ЗЫ.
1. в филиалах адпаки (без регистрации на ноде)
2. 192.168.2.1 - адрес ноды.
Филиалы в одной IP сети, они пингуются? Есть ли между ними nat, firewall ?
в разных, друг с другом не пингуются, только с SS.
намек понял, буду добивать адпаки.
jeka5 пишет
в разных, друг с другом не пингуются, только с SS.
Нужно, что бы все VoIP устройства в сети были между собой доступны! Т.е. вам нужно пересмотреть топологию сети.
1. Пока у вас с филиала в филиал пинги ходить не будут - не видать вам счастья
2. Надо либо гейткипер поднимать:) , либо на каждом филиале соответствующие диалпиры прописывать на каждый смежный филиал:( Через основную станцию работать не лучший вариант.
Urri пишет
2. Надо либо гейткипер поднимать:) , либо на каждом филиале соответствующие диалпиры прописывать на каждый смежный филиал:( Через основную станцию работать не лучший вариант.
Тут вроде разговор идет про CS1000, значит есть SS, ну а SS и есть GK, на нем я так понимаю таблицы маршрутизации и подняты или не так реализовано?
Urri пишет
1. Пока у вас с филиала в филиал пинги ходить не будут - не видать вам счастья
2. Надо либо гейткипер поднимать:) , либо на каждом филиале соответствующие диалпиры прописывать на каждый смежный филиал:( Через основную станцию работать не лучший вариант.
Глупость скажу, но телефону на ICMP дискавери с одного админского компа на другой - пофиг.
Ему бы дорогу с 5200 и 5201 порта на порты, указанные дальней стороной.
А пинг с одного тилана другого тиланом не значит, что аппараты, к этим тиланам прицепившиеся друг друга видят.
Пинг не транзитивен.
lexad пишет
Глупость скажу, но телефону на ICMP дискавери с одного админского компа на другой - пофиг.
Ему бы дорогу с 5200 и 5201 порта на порты, указанные дальней стороной.
А пинг с одного тилана другого тиланом не значит, что аппараты, к этим тиланам прицепившиеся друг друга видят.
Пинг не транзитивен.
Понятно, что пинг это только первый шаг в локализации проблемы. В данном случае, у человека даже пинги не ходят, нет маршрутизации между сетками с ендпоинтами... Вот устранит данную проблему, не заработает, будет дальше копать :)
Опять возвращаюсь к данной теме (извиняюсь за долгое молчание):
1. Вставил ендпойнты и SS в одну сеть 192.168.2.0 - то же самое (вызов проходит, в трубке тишина).
2. Попробовал посмотреть вайршарком: вроде на первый взгляд все корректно - ендпойнты договорились с ГК и далее обмениваются уже между собой сообщениями G723. Попробую выложить файл с трассировкой.
192.168.2.1 - нода
192.168.2.2 - ГК
192.168.2.61 - 1-й ендпойнт (298)
192.168.2.62 - 2-й ендпойнт (296)
По трейсам никакого RTP c
ip.src == 192.168.2.61
(он в обратную сторону)
Его общение с GK - 4 пакета
No. Time Source Port Destination Port Len Protocol
85 8.039764 192.168.2.2 1719 192.168.2.61 22002 60 H.225.0
Frame 85 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:0c:b7:f4:89 (00:0e:0c:b7:f4:89), Dst: 00:02:a4:02:89:2e (00:02:a4:02:89:2e)
Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 192.168.2.61 (192.168.2.61)
User Datagram Protocol, Src Port: 1719 (1719), Dst Port: 22002 (22002)
H.225.0 RAS
RasMessage: gatekeeperReject (2)
gatekeeperReject
requestSeqNum: 1228
protocolIdentifier: 0.0.8.2250.0.4 (itu-t(0) recommendation(0) h(8) h225-0(2250) version(0) 4)
rejectReason: terminalExcluded (1)
terminalExcluded: NULL
[This is a response to a request in frame 84]
[RAS Service Response Time: 0.003821000 seconds]
No. Time Source Port Destination Port Len Protocol
467 18.108913 192.168.2.2 1719 192.168.2.61 22000 142 H.225.0
Frame 467 (142 bytes on wire, 142 bytes captured)
Ethernet II, Src: 00:0e:0c:b7:f4:89 (00:0e:0c:b7:f4:89), Dst: 00:02:a4:02:89:2e (00:02:a4:02:89:2e)
Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 192.168.2.61 (192.168.2.61)
User Datagram Protocol, Src Port: 1719 (1719), Dst Port: 22000 (22000)
H.225.0 RAS
RasMessage: registrationConfirm (4)
registrationConfirm
requestSeqNum: 38943
protocolIdentifier: 0.0.8.2250.0.4 (itu-t(0) recommendation(0) h(8) h225-0(2250) version(0) 4)
callSignalAddress: 1 item
Item 0
Item: ipAddress (0)
ipAddress
ip: 192.168.2.2 (192.168.2.2)
port: 1720
endpointIdentifier: 0011235220080207102218000e0cb7f489
timeToLive: 30
0... .... willRespondToIRR: False
preGrantedARQ
.0.. .... makeCall: False
..0. .... useGKCallSignalAddressToMakeCall: False
...1 .... answerCall: True
.... 0... useGKCallSignalAddressToAnswer: False
0... .... maintainConnection: False
[This is a response to a request in frame 465]
[RAS Service Response Time: 0.014812000 seconds]
No. Time Source Port Destination Port Len Protocol
535 19.955184 192.168.2.2 1719 192.168.2.61 22000 60 H.225.0
Frame 535 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:0c:b7:f4:89 (00:0e:0c:b7:f4:89), Dst: 00:02:a4:02:89:2e (00:02:a4:02:89:2e)
Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 192.168.2.61 (192.168.2.61)
User Datagram Protocol, Src Port: 1719 (1719), Dst Port: 22000 (22000)
H.225.0 RAS
RasMessage: disengageConfirm (16)
disengageConfirm
requestSeqNum: 38944
[This is a response to a request in frame 533]
[RAS Service Response Time: 0.008165000 seconds]
No. Time Source Port Destination Port Len Protocol
582 23.044202 192.168.2.2 1719 192.168.2.61 22002 60 H.225.0
Frame 582 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0e:0c:b7:f4:89 (00:0e:0c:b7:f4:89), Dst: 00:02:a4:02:89:2e (00:02:a4:02:89:2e)
Internet Protocol, Src: 192.168.2.2 (192.168.2.2), Dst: 192.168.2.61 (192.168.2.61)
User Datagram Protocol, Src Port: 1719 (1719), Dst Port: 22002 (22002)
H.225.0 RAS
RasMessage: gatekeeperReject (2)
gatekeeperReject
requestSeqNum: 1229
protocolIdentifier: 0.0.8.2250.0.4 (itu-t(0) recommendation(0) h(8) h225-0(2250) version(0) 4)
rejectReason: terminalExcluded (1)
terminalExcluded: NULL
[This is a response to a request in frame 581]
[RAS Service Response Time: 0.003101000 seconds]
Что-то попрежнему не то
(кстати, по портам это далеко не нортелевское оборудование - поэтому как оно будет регировать - X3)
lexad пишет
По трейсам никакого RTP c
ip.src == 192.168.2.61
Что-то попрежнему не то
(кстати, по портам это далеко не нортелевское оборудование - поэтому как оно будет регировать - X3)
Меня тут многое настораживает (если б еще все до конца понимать :confused: ):
1. 192.168.2.61 в ответ на GRQ получил reject (frame 84,85), но тем не менее на RRQ получил confirmed (frame 465,467) - ситуация непонятная, но вроде все работает.
2. 192.168.2.61 обменивается с ГК об открытии логич. канала и т.д. через Н225.0 (frame 111 - 119) в отличие от от 192.168.2.62, хотя настройки обоих ендпойнтов вроде одинаковые.
Ендпойнты - оборудование Addpac: корейская железка с цисковскими внутренностями и интерфейсом (я выше писал).
Ох, пойду дальше мучиться...
Потестив CS1000 4.5 с Cisco GW в качестве H323 GW на NRS пришел к выводу о необходимости установки патчей на SS, причем одного Deplist-а недостаточно, например для Сisco GW существует отдельный. (как я понимаю горячо любимые народом Fast start, Slow start разными производителями понимаются по разному)
Сейчас выяснил, что у меня не работает конференция с абонентами за Cisco GW. :(
osv_m1 пишет
Потестив CS1000 4.5 с Cisco GW в качестве H323 GW на NRS пришел к выводу о необходимости установки патчей на SS, причем одного Deplist-а недостаточно, например для Сisco GW существует отдельный. (как я понимаю горячо любимые народом Fast start, Slow start разными производителями понимаются по разному)
Сейчас выяснил, что у меня не работает конференция с абонентами за Cisco GW. :(
Тут обсуждался патч, который детали реализации h245
(control channel protocol used with[in] H.323 communication sessions) тюнит для того, чтобы понимать тарабарщину от Циски. Но включается он по Vendor ID в протоколе.
Интероп - штука мудренная.
Деплисты вообще штука очень полезная.