[leveler]

Такая ситуация у меня. Есть схема:

Софтсвич --- Джунипер SSG --- АТС Panasonic KX-TDE100

Джунипер выступает в качестве NAT и секурити. При чём, этот NAT является VoIP-aware.

Панасоник у нас умеет только FS+NO TUNNELING без вариантов.

Софтсвич не умеет не инициировать открытие H.245 (инициирует всегда).

 

Так вот. В чём проблема собственно говоря. В Alerting от СС к АТС передаётся h245address - хотим открыть H.245 соединение. В ответ от АТС приходит Facility с h245address в котором указывается внутренний серый IP-адрес. SSG на это ругается в дебаг и выдаёт следущее:

## 2010-07-20 15:43:16 : H.245 address not matching previously seen H.245 address - Not supported!
## 2010-07-20 15:43:16 :  Q.931 H.245 IP changed 10.0.0.100:10246 to 192.168.0.200:49394

, где 10.0.0.100 - это типа внутренний IP-адрес АТС, а 192.168.0.200 типа IP-адрес СС.

То есть, SSG заменяет значение h245address не на global inside, а на адрес СС. Получается, что софтсвич ловит Facility с h245address содержащий свой же собственный IP-адрес и шлёт H.245 TCS сам на себя. После этого со стороны АТС устанавливается TCP соединение и шлётся H.245 TCS, на что сотфсвич реагирует TCSReject. После обмена H.245 MSD происходит разъединение со стороны АТС с кодом 127.

 

Вопрос: кто виноват?

Должна ли АТС пытаться передать h245address, если получила уже информацию, куда ей нужно коннектиться для организации H.245?

И если кто знает наизусть весь стек H.323, может подкинет ссылочку на конкретное место, где есть однозначное разъяснение?

[ram_scan]

Считаю что SSG.

 

Особенно учитывая то что схема без SSG работает, о чем коллега leveler забыл упомянуть.

[leveler]

Ещё скажу, что только СС под моим контролем. И что из-за ната вытащить АТС не получится по орагнизационно-техническим причинам (она завязана на другие АТС по H.323 во внутренней сети).

[All is not what it seems]

делайте тунель.

[nag-f]

Такая ситуация у меня. Есть схема:

Софтсвич --- Джунипер SSG --- АТС Panasonic KX-TDE100

Джунипер выступает в качестве NAT и секурити. При чём, этот NAT является VoIP-aware.

Панасоник у нас умеет только FS+NO TUNNELING без вариантов.

Софтсвич не умеет не инициировать открытие H.245 (инициирует всегда).

 

Так вот. В чём проблема собственно говоря. В Alerting от СС к АТС передаётся h245address - хотим открыть H.245 соединение. В ответ от АТС приходит Facility с h245address в котором указывается внутренний серый IP-адрес. SSG на это ругается в дебаг и выдаёт следущее:

## 2010-07-20 15:43:16 : H.245 address not matching previously seen H.245 address - Not supported!
## 2010-07-20 15:43:16 :  Q.931 H.245 IP changed 10.0.0.100:10246 to 192.168.0.200:49394

, где 10.0.0.100 - это типа внутренний IP-адрес АТС, а 192.168.0.200 типа IP-адрес СС.

То есть, SSG заменяет значение h245address не на global inside, а на адрес СС. Получается, что софтсвич ловит Facility с h245address содержащий свой же собственный IP-адрес и шлёт H.245 TCS сам на себя. После этого со стороны АТС устанавливается TCP соединение и шлётся H.245 TCS, на что сотфсвич реагирует TCSReject. После обмена H.245 MSD происходит разъединение со стороны АТС с кодом 127.

 

Вопрос: кто виноват?

Должна ли АТС пытаться передать h245address, если получила уже информацию, куда ей нужно коннектиться для организации H.245?

И если кто знает наизусть весь стек H.323, может подкинет ссылочку на конкретное место, где есть однозначное разъяснение?

Приведите tcpdump сигнальных сообщений с двух сторон НАТ.

[leveler]

Тунель не вариант.

Дампа не будет из соображений параноидальной секурности. Спрашивайте, если есть конкретные вопросы.

[facility]

Вопрос: кто виноват?

Виноват мировой капитализм. Недаром его кризис в разгаре.

 

Должна ли АТС пытаться передать h245address, если получила уже информацию, куда ей нужно коннектиться для организации H.245?

Не должна, но имеет право. h245Address передается в случае "желания" одного из устройств переключиться на использование отдельного канала H.245. Почему устройство может "пожелать" это сделать - известно одному лишь устройству (и иногда разработчику, если он не китаец и не индус) :)

 

И если кто знает наизусть весь стек H.323, может подкинет ссылочку на конкретное место, где есть однозначное разъяснение?

Я конечно наизусть не знаю, но могу посоветовать прочитать H.323 v.2 (используемая вашими устройствами версия мне неизвестна) - http://www.itu.int/rec/dologin_pub.asp?lan...&type=items раздел "8.2.3 Switching to a Separate H.245 Connection".

 

Если после прочтения ситуация не прояснится, то Пол Джонс Вам в помощь. Найти его можно здесь - http://forums.packetizer.com/viewforum.php?f=2 . Очень охотно отвечает.

[leveler]

Не должна, но имеет право. h245Address передается в случае "желания" одного из устройств переключиться на использование отдельного канала H.245. Почему устройство может "пожелать" это сделать - известно одному лишь устройству (и иногда разработчику, если он не китаец и не индус) :)

"Желание" есть у СС, о котором он извещает в Alerting. Зачем же ещё и АТС передаёт Facility с h245address в ответ?

Ладно, полезу полистаю доку. Спасибо за наводку.

[leveler]

If, at the time an endpoint deems it necessary to initiate the separate H.245
connection, it finds that it has not yet received the h245Address of the other endpoint, the endpoint
shall transmit a Facility message with a FacilityReason of startH245 and provide its H.245 address in
the h245Address element. An endpoint receiving a Facility message with a facilityReason of
startH245 which has not already independently initiated the separate H.245 channel shall open the
H.245 channel using the h245Address specified.

То есть, может инициировать только в том случае, если ещё не предложила другая сторона. SSG, видимо, считает это за грубое нарушение рекомендации.

[facility]

То есть, может инициировать только в том случае, если ещё не предложила другая сторона. SSG, видимо, считает это за грубое нарушение рекомендации.

Там в следующих двух абзацах много всяких разных "если". На эту тему можно долго теоретизировать. Надо понять корректность содержания сообщений H.225.0 и в каком из сообщений впервые появился параметр h245Address. Также надо понять завершился ли цикл открытия канала H.245 (получено ли со стороны АТС подтверждение открытия TCP-соединения) на момент отправки Facility со стороны АТС, и не являлись ли попытки открытия канала H.245 "одновременными" с обеих сторон. Была ли предпринята процедура разрешения конфликта при одновременной попытке открытия канала H.245 с обеих сторон.

Изменено 21 июля, 2010 пользователем facility

[leveler]

Так. Легенда меняется. Через абзац пишут:

In the event that both endpoints simultaneously initiate the separate H.245 connection, the endpoint
with the numerically smaller h245Address shall close the TCP connection it opened and use the
connection opened by the other endpoint. For purposes of comparing the numeric values of
h245Address, each octet of the address shall be individually compared beginning with the first octet
of the OCTET STRING and continuing through the OCTET STRING left to right until unequal
numeric octet values are found. Comparison shall first be performed on the network-layer address
element of h245Address, and, if found to be equal, then on the transport (port) address element.

То есть, ситуация вполне нормальная, когда обе стороны инициируют открытие H.245. И в этом случае действительно виновата SSG.

Всем спасибо за участие!

 

UPD: а facility меня опередил. )