Jump to content
Калькуляторы

Вопрос по H.323 Открытие H.245 при FS и без TUNNELING

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

Софтсвич --- Джунипер 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, может подкинет ссылочку на конкретное место, где есть однозначное разъяснение?

Share this post


Link to post
Share on other sites

Считаю что SSG.

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Такая ситуация у меня. Есть схема:

Софтсвич --- Джунипер 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 сигнальных сообщений с двух сторон НАТ.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Вопрос: кто виноват?
Виноват мировой капитализм. Недаром его кризис в разгаре.

 

Должна ли АТС пытаться передать 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 . Очень охотно отвечает.

Share this post


Link to post
Share on other sites
Не должна, но имеет право. h245Address передается в случае "желания" одного из устройств переключиться на использование отдельного канала H.245. Почему устройство может "пожелать" это сделать - известно одному лишь устройству (и иногда разработчику, если он не китаец и не индус) :)
"Желание" есть у СС, о котором он извещает в Alerting. Зачем же ещё и АТС передаёт Facility с h245address в ответ?

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

Share this post


Link to post
Share on other sites

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, видимо, считает это за грубое нарушение рекомендации.

Share this post


Link to post
Share on other sites

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

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

Edited by facility

Share this post


Link to post
Share on other sites

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

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 меня опередил. )

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this