ARTCOM LOGO

Здравствуйте, гость ( Вход | Регистрация )

4 страниц V   1 2 3 > »   
Ответить в данную темуНачать новую тему
> ipecs-100 voip panasonic tde-200
Den
сообщение 3.6.2011, 7:17
Сообщение #1


Новичок
*

Группа: Участники
Сообщений: 5
Регистрация: 14.4.2011
Пользователь №: 15765



Добрый день нужна помощь в разборе проблемы - 2 станции ipecs-mg и tde-200.

соединены по h.323, связь со стороны ipecsа на тде есть, звонок проходит, все в порядке,
звонок со стороны тде на ипекс, такж е проходит но рвется через 6-7 секунд.

подскажите где искать проблему? трейс снимался с тде, на картинках странности:
Прикрепленные файлы
Прикрепленный файл  ipecs_tde.rar ( 2,08 килобайт ) Кол-во скачиваний: 29
Прикрепленный файл  1.jpg ( 101,52 килобайт ) Кол-во скачиваний: 95
Прикрепленный файл  2.jpg ( 111,84 килобайт ) Кол-во скачиваний: 74
 
Перейти в начало страницы
 
+Цитировать сообщение
All is not what ...
сообщение 3.6.2011, 11:58
Сообщение #2


Ветеран форума
*****

Группа: Участники
Сообщений: 912
Регистрация: 10.11.2006
Пользователь №: 114



Ну конечно ж в паносеsmile.gif
Ведь это он на callProeeding выругался "Message not compatible with call state or message type non-existent or not implemented (98)".
Или это запоздало и относилось к setupAcknowledge?
А setupAcknowledge он ведь сам и спровоцировал неполным набранным номером.
Или шестизначный номер это правильно?
Тогда почему не оформил должным образом, чтоб на него не приходилось отвечать setupAcknowledge?
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 6.6.2011, 17:31
Сообщение #3


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Den
Проверьте вот что:
1. План нумерации со стороны панаса и настройки enblock/overlap. Он шлет номер в сетапе без sending complete. Лыжа это видит и шлет setupAck, далее - CallProc, т.к. принятых цифр ей видимо достаточно для начала маршрутизации, что в свою очередь вызывает неподдельное удивление у панаса, находящегося в режиме overlap(виден status с текстом "Message not compatible with call state or message type non-existent or not implemented" и взведенным флагом Call State - Overlap Sending). При и этом следует отметить, что оба устройства так или инача нарушают стандарт: панас нарушает стандарт, не взводя в setup'e флаг canOverlapSend в TRUE, лыжа явно не ждет дефолтового значения таймера T302
2. сочетания normal/fast и tunneling:on/off со стороны панаса и лыжи. Я у себя на MG наблюдал неответ на TCS при определенном сочетании fast/normal и tunneling. гарантированно рабочи вариант со стороны MG - fast/tunneling on
3. Оставьте для верности по одному или 2 кодека с каждой стороны.
4. разговор собственно обрывается из-за истечения таймера T101 - в течении него ждем ответ на TCS


--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
Den
сообщение 7.6.2011, 4:38
Сообщение #4


Новичок
*

Группа: Участники
Сообщений: 5
Регистрация: 14.4.2011
Пользователь №: 15765



Цитата(exzerodivide @ 6.6.2011, 23:31) *
Den
Проверьте вот что:
1. План нумерации со стороны панаса и настройки enblock/overlap. Он шлет номер в сетапе без sending complete. Лыжа это видит и шлет setupAck, далее - CallProc, т.к. принятых цифр ей видимо достаточно для начала маршрутизации, что в свою очередь вызывает неподдельное удивление у панаса, находящегося в режиме overlap(виден status с текстом "Message not compatible with call state or message type non-existent or not implemented" и взведенным флагом Call State - Overlap Sending). При и этом следует отметить, что оба устройства так или инача нарушают стандарт: панас нарушает стандарт, не взводя в setup'e флаг canOverlapSend в TRUE, лыжа явно не ждет дефолтового значения таймера T302
2. сочетания normal/fast и tunneling:on/off со стороны панаса и лыжи. Я у себя на MG наблюдал неответ на TCS при определенном сочетании fast/normal и tunneling. гарантированно рабочи вариант со стороны MG - fast/tunneling on
3. Оставьте для верности по одному или 2 кодека с каждой стороны.
4. разговор собственно обрывается из-за истечения таймера T101 - в течении него ждем ответ на TCS


С планом нумерации все в порядке, он и должен быть 6-значный=3-префикс,3-внутренний номер

1. панас работал в режим enblock, по крайней мере в настраках на исходящем вызове стояло именно enblock, пробовал играться - результат примерно одинаковый, установил overlap связь устанавливается быстрее чем в enblock, но также рвется, в статусе также "Message not compatible with call state or message type non-existent or not implemented" и Overlap Sending.

2. в настройках MG, стоит fast|tunneling on, в normal'е связь вообще не устанавляивается, хотя панас может работать в fast/normal

3. кодеки стоят 729 и 711
Прикрепленные файлы
Прикрепленный файл  1.PNG ( 37,1 килобайт ) Кол-во скачиваний: 47
Прикрепленный файл  11.rar ( 1,22 килобайт ) Кол-во скачиваний: 8
 
Перейти в начало страницы
 
+Цитировать сообщение
Den
сообщение 7.6.2011, 4:39
Сообщение #5


Новичок
*

Группа: Участники
Сообщений: 5
Регистрация: 14.4.2011
Пользователь №: 15765



Цитата(All is not what it seems @ 3.6.2011, 17:58) *
Или шестизначный номер это правильно?
Тогда почему не оформил должным образом, чтоб на него не приходилось отвечать setupAcknowledge?


6значный - правильно.
Как понять не оформил правильно?
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 7.6.2011, 11:07
Сообщение #6


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Цитата(Den @ 7.6.2011, 5:38) *
С планом нумерации все в порядке, он и должен быть 6-значный=3-префикс,3-внутренний номер

1. панас работал в режим enblock, по крайней мере в настраках на исходящем вызове стояло именно enblock, пробовал играться - результат примерно одинаковый, установил overlap связь устанавливается быстрее чем в enblock, но также рвется, в статусе также "Message not compatible with call state or message type non-existent or not implemented" и Overlap Sending.

2. в настройках MG, стоит fast|tunneling on, в normal'е связь вообще не устанавляивается, хотя панас может работать в fast/normal

3. кодеки стоят 729 и 711

Почти весь цвет нации в топике собрался :-)
по пунктам:
1. я верю, что в конфиге стоит enblock. но в pcap-е иная картина, Вы не находите ? :-) В любом случае - то, что панас стоит в оверлапе говорят два факта: первое - отсутствие sending complete, второе - статус от панаса на callproceeding от MG. Разбирайтесь, почему так. Может, баг прошивки панаса, может что-то просмотрели. У вас на панасе набор номера каким образом заканчивается ? По тайм-ауту ? Или панас видит валидный номер и заканчивает сбор цифр ? Попробуйте принудительно закончить сбор цифр, добавив решетку.
2. панас туннелинг не поддерживает, это хорошо видно. как минимум - отключите его на MG и пробуйте комбинации normal/off и fast/off.
3. оставте на всякий случай ровно 1 - g711ulaw

PS Кладите заодно отладку с панаса - так будет виднее. И отладку с MG заодно.



--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 7.6.2011, 11:11
Сообщение #7


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Цитата(Den @ 7.6.2011, 5:39) *
6значный - правильно.
Как понять не оформил правильно?

Коллега намекает на отсутствие sending complete в сетапе панаса и отсутствие последующих h.225 info от панаса. Хотя, быть может, панас не успевает послать sending complete или info, получая от MG callproc.


--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
Fray
сообщение 2.10.2012, 17:03
Сообщение #8


Частый гость
***

Группа: Участники
Сообщений: 69
Регистрация: 2.11.2007
Пользователь №: 6150



Вечер добрый.
Есть ли решение для данной проблемы? На версии MG100 B0De (voip на mpb) и TDE100 5.0203 тоже самое ((( кстати c LIK связка нормальная.
Кому интересно вот ответ PANASONIC по данной проблеме:
TDE шлёт сообщение TCS (terminal capability set, набор возможностей терминала), MG данное сообщение игнорирует, и TDE по истечении таймера сессию рвёт.
Или в оригинале:
We think that the problem will be the design of LG IPECS for the specific call-connection process. We can not understand why LG IPECS can not send the response to terminalCapabilitySet message even if it can respond to masterSlaveDetermination. I recommend you to ask the update of their software. It may be the known issue in some cases.
Перейти в начало страницы
 
+Цитировать сообщение
harris
сообщение 2.10.2012, 17:29
Сообщение #9


ГУРУ
********

Группа: Участники
Сообщений: 12388
Регистрация: 23.11.2006
Из: Москва
Пользователь №: 146



Цитата(Fray @ 2.10.2012, 17:03) *
Вечер добрый.
Есть ли решение для данной проблемы? На версии MG100 B0De (voip на mpb) и TDE100 5.0203 тоже самое ((( кстати c LIK связка нормальная.
Кому интересно вот ответ PANASONIC по данной проблеме:
TDE шлёт сообщение TCS (terminal capability set, набор возможностей терминала), MG данное сообщение игнорирует, и TDE по истечении таймера сессию рвёт.
Или в оригинале:
We think that the problem will be the design of LG IPECS for the specific call-connection process. We can not understand why LG IPECS can not send the response to terminalCapabilitySet message even if it can respond to masterSlaveDetermination. I recommend you to ask the update of their software. It may be the known issue in some cases.

Увы. Решения этой ситуации до сих пор нет, хотя корейцы пытались на нескольких версиях скорректировать эту ситуацию со своей стороны, в том числе и на версии B.0De. Но проблема исходно, ИМХО, вовсе не в MG, а в Панасе!! Не стоит считать Панас "безгрешным". Посмотрите внимательнее, Панас ведь работает кривовато!!
Мне присылали трассировку аналогичного вызова. Там видно, что:
- Панас инициирует вызов как с использованием Fast Start, так и с Early H.245.
- в станции MG корейцы отказались от поддержки Early H.245, поскольку Fast Start стал более распространенным методом, ИМХО.
- Вот MG и отвечает тоже с использованием Fast Start (открывает лог. канал OLC)
- Только далее оказывется, что почему-то Панас не хочет работать по FS и начинает запрашивать TCS. Почему, зачем?? Станции уже обменялись "возможностями терминала" в информ. полях FS.
- И зачем Панас присылает Status??? Что ему "не понравилось"?? Что его запросили об окончании набора номера (SetupAck)?? Так это согласно протоколу, Панас ведь не прислал Sending Complete.

Но пока корейцы еще продолжают заниматься этой задачей (запрос по этой проблеме еще не снят).
Кстати, а у Вас есть снифер входящего вызова на MG, снятый именно на версии B.0De?? Если есть, то, пожалуйста, пришлите его срочно мне.


--------------------
Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
Перейти в начало страницы
 
+Цитировать сообщение
WAHLW
сообщение 2.10.2012, 19:03
Сообщение #10


Частый гость
***

Группа: Участники
Сообщений: 32
Регистрация: 24.5.2012
Пользователь №: 17539



"возможности терминала" в FS гораздо меньше чем в TCS.
Панас в своём праве.
Отвячать на TCS обязательно.
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 2.10.2012, 21:56
Сообщение #11


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Категорически приветствую!

Цитата(harris @ 2.10.2012, 18:29) *
Увы. Решения этой ситуации до сих пор нет, хотя корейцы пытались на нескольких версиях скорректировать эту ситуацию со своей стороны, в том числе и на версии B.0De. Но проблема исходно, ИМХО, вовсе не в MG, а в Панасе!! Не стоит считать Панас "безгрешным". Посмотрите внимательнее, Панас ведь работает кривовато!!

Ну если сравнивать "радиус кривизны" то лыжа панас явно обогнала.
Цитата
Мне присылали трассировку аналогичного вызова. Там видно, что:
- Панас инициирует вызов как с использованием Fast Start, так и с Early H.245.

И правильно делает. Early H.245 к слову - изобретение корейцев. В стандарте это называется "Initiating H.245 tunneling in parallel with fast connect"
Цитата
- в станции MG корейцы отказались от поддержки Early H.245, поскольку Fast Start стал более распространенным методом, ИМХО

За окном шел дождь и рота красноармейцев. Early H.245 и FastStart взаимодополняют друг друга. Читай h.323 v.4 параграф 8.2.4 Лучше бы стандарт соблюдали, а не самодеятельностью занимались.
Цитата
- Вот MG и отвечает тоже с использованием Fast Start (открывает лог. канал OLC)
- Только далее оказывется, что почему-то Панас не хочет работать по FS и начинает запрашивать TCS. Почему, зачем??

Патамучта панас хочет знать UserInputIndication и RTP payload types например, а так же умеет ли шерстяной друг факс по t.38.

Цитата
Станции уже обменялись "возможностями терминала" в информ. полях FS.

Вот только не надо придумывать. "возможностями терминала" в информ. полях FS. они на FS не обменивались.

Цитата
- И зачем Панас присылает Status??? Что ему "не понравилось"?? Что его запросили об окончании набора номера (SetupAck)?? Так это согласно протоколу, Панас ведь не прислал Sending Complete.

Выложи дамп, посмотрим вместе.

Цитата
Но пока корейцы еще продолжают заниматься этой задачей (запрос по этой проблеме еще не снят).
Кстати, а у Вас есть снифер входящего вызова на MG, снятый именно на версии B.0De?? Если есть, то, пожалуйста, пришлите его срочно мне.

Лучше бы стандарт реализовывали как описано, чесслово. Или взяли тот-же openh323 если сами не могут.


--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
harris
сообщение 3.10.2012, 10:23
Сообщение #12


ГУРУ
********

Группа: Участники
Сообщений: 12388
Регистрация: 23.11.2006
Из: Москва
Пользователь №: 146



Цитата(WAHLW @ 2.10.2012, 19:03) *
"возможности терминала" в FS гораздо меньше чем в TCS.
Панас в своём праве.
Отвячать на TCS обязательно.

С чего Вы это взяли?? Такие же возможности, как и в TCS.
Отвечать на TCS обязательно для открытия H.245, но при FS канал H.245 как таковой не открывается:
With the use of Fast Connect, there is no need to open an H.245 channel, as long as all needed media can be negotiated via Fast Connect.

Ответ на FS:
- To “accept” Fast Connect, an endpoint may select any fastStart element in the SETUP message, populate the necessary data fields (as specified in H.323), and return a fastStart element in any message to the caller
- An endpoint “rejects” Fast Connect by either explicitly indicating so (there is a flag for this), initiating any H.245 communications, or providing an H.245 address for the purposes of initiating H.245 communications
- Until Fast Connect is accepted or rejected, the calling endpoint may not initiate H.245 procedures (there is a exception to this rule in H.323v4 designed to avoid race conditions that would otherwise exist)

Вся проблема, видимо, в том, что MG отвечает сообщением SetupAck без FS. Но MG в этот момент не знает, сможет ли она принять вызов, т.к не было Sending_Complete, и возможно не все цифры номера получены.
И видимо, поэтому Панас более не реагирует на поля FS, которые MG включает уже в след. сообщения (в Call_Proc).

Можно ли добиться, чтобы Панас присылал Setup с Sending_Complete?? По нашему мнению, тогда все просто должно срастисть по FS.

2 exzerodivide:
Значит мы по-разному понимаем стандарты. Вы наблюдаете за дождем, а мы - за ротой красноармейцев. И неизвестно, что в данном случае важнее. Еще раз перечитал доки... Early H.245 вовсе не является дополнением к Fast Start. Это вполне самостоятельный метод. Оба практически преследуют одни и те же цели - возможность передачи RTP до установления соединения (до Connect). Но при Early H.245, лог. канал H.245 действительно открывается до Connect'а, а при FS стороны обмениваются необходимой информацией в сообщениях, аналогичных H.245, но без открытия Н.245 как такового.
Впрочем, на глубокие знания данного предмета я не претендую.. smile.gif
И давайте по-спокойнее... Корейцы, по крайней мере, пытаются найти решение, а не занимаются отписками, как обычно поступает Панас.


--------------------
Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
Перейти в начало страницы
 
+Цитировать сообщение
WAHLW
сообщение 3.10.2012, 11:01
Сообщение #13


Частый гость
***

Группа: Участники
Сообщений: 32
Регистрация: 24.5.2012
Пользователь №: 17539



2exzerodivide:
Объясняйся доступней, а то видишь что мимо выпалил.smile.gif
Перейти в начало страницы
 
+Цитировать сообщение
harris
сообщение 3.10.2012, 11:07
Сообщение #14


ГУРУ
********

Группа: Участники
Сообщений: 12388
Регистрация: 23.11.2006
Из: Москва
Пользователь №: 146



Цитата(WAHLW @ 3.10.2012, 11:01) *
2exzerodivide:
Объясняйся доступней, а то видишь что мимо выпалил.smile.gif

blink.gif Я что-то не так понял??


--------------------
Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 3.10.2012, 12:38
Сообщение #15


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Цитата(harris @ 3.10.2012, 11:23) *
С чего Вы это взяли?? Такие же возможности, как и в TCS.
Отвечать на TCS обязательно для открытия H.245, но при FS канал H.245 как таковой не открывается:
With the use of Fast Connect, there is no need to open an H.245 channel, as long as all needed media can be negotiated via Fast Connect.

Давайте не будем читать обзорные презентации по протоколу с packetizer.com (да-да, страницы 110-112 презентации), а обратимся к официальному описанию протокола H.323 v4
Код
8.1.7   Fast connect procedure
H.323 endpoints may establish media channels in a call using either the procedures defined in Recommendation H.245 or the "Fast Connect" procedure described in this subclause. The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection.
The calling endpoint initiates the Fast Connect procedure by sending a Setup message containing the fastStart element to the called endpoint. The fastStart element consists of a sequence of OpenLogicalChannel structures describing media channels which the calling endpoint proposes to send and receive, including all of the parameters necessary to immediately open and begin transferring media on the channels. Details of the content and usage of the fastStart element are discussed below.


Поясняю мысль - в элементе fastStart содержатся структуры OpenLogicalChannel вида:

Код
OpenLogicalChannel    ::=SEQUENCE
{
    forwardLogicalChannelNumber    LogicalChannelNumber,

    forwardLogicalChannelParameters    SEQUENCE
    {
        portNumber    INTEGER (0..65535) OPTIONAL,
        dataType    DataType,
        multiplexParameters    CHOICE
        {
            h222LogicalChannelParameters    H222LogicalChannelParameters,
            h223LogicalChannelParameters    H223LogicalChannelParameters,
            v76LogicalChannelParameters    V76LogicalChannelParameters,
            ...,
            h2250LogicalChannelParameters    H2250LogicalChannelParameters,
            none    NULL  -- for use with Separate Stack when
                  -- multiplexParameters are not required
                  -- or appropriate

        },
        ...,
        forwardLogicalChannelDependency    LogicalChannelNumber OPTIONAL,
            -- also used to refer to the primary logical channel when using video redundancy coding
        replacementFor    LogicalChannelNumber OPTIONAL

    },


где DataType это:

Код
DataType        ::=CHOICE
{
    nonStandard    NonStandardParameter,
    nullData    NULL,
    videoData    VideoCapability,    
    audioData    AudioCapability,
    data        DataApplicationCapability,
    encryptionData    EncryptionMode,
    ...,
    h235Control    NonStandardParameter,
    h235Media    H235Media,
    multiplexedStream    MultiplexedStreamParameter
}


А теперь TCS: (документ H.245 v.4)

Код
B.2.2.1 Capability Table
A TerminalCapabilitySet may contain zero or more CapabilityTableEntrys. At the start, no table entries are defined. When a CapabilityTableEntry is received, it replaces the previously received CapabilityTableEntry with the same CapabilityTableEntryNumber. A CapabilityTableEntry without a Capability may be used to remove the previously received CapabilityTableEntry with the same CapabilityTableEntryNumber.

B.2.2.2    Capability Descriptors
CapabilityDescriptors are used to indicate a terminal's capability to transmit and receive. Each CapabilityDescriptor provides an independent statement about the terminal's capabilities.

B.2.2.3    Capability
The choices receiveVideoCapability, receiveAudioCapability, receiveDataApplicationCapability, receiveUserInputCapability and receiveMultiplexedStreamCapability indicate the capability to receive according to the respective VideoCapability, AudioCapability, DataApplicationCapability, UserInputCapability and MultiplexedStreamCapability.
The choices transmitVideoCapability, transmitAudioCapability, transmitDataApplicationCapability, transmitUserInputCapability and transmitMultiplexedStreamCapability indicate the capability to transmit according to the respective VideoCapability, AudioCapability, DataApplicationCapability UserInputCapability and MultiplexedStreamCapability.
The choices receiveAndTransmitVideoCapability, receiveAndTransmitAudioCapability, receiveAndTransmitDataApplicationCapability, receiveAndTransmitUserInputCapability and receiveAndTransmitMultiplexedStreamCapability indicate the capability to receive and transmit symmetrically according to the respective VideoCapability, AudioCapability, DataApplicationCapability and UserInputCapability and MultiplexedStreamCapability. These code points may be useful for indicating that the receive and transmit capabilities are not independent

Capability        ::=CHOICE
{
    nonStandard    NonStandardParameter,

    receiveVideoCapability    VideoCapability,
    transmitVideoCapability    VideoCapability,
    receiveAndTransmitVideoCapability    VideoCapability,

    receiveAudioCapability    AudioCapability,
    transmitAudioCapability    AudioCapability,
    receiveAndTransmitAudioCapability    AudioCapability,

    receiveDataApplicationCapability    DataApplicationCapability,
    transmitDataApplicationCapability    DataApplicationCapability,
    receiveAndTransmitDataApplicationCapability    DataApplicationCapability,

    h233EncryptionTransmitCapability    BOOLEAN,
    h233EncryptionReceiveCapability    SEQUENCE
    {
        h233IVResponseTime    INTEGER (0..255),    -- units milliseconds    
        ...
    },
    ...,
    conferenceCapability    ConferenceCapability,
    h235SecurityCapability    H235SecurityCapability,
    maxPendingReplacementFor    INTEGER (0..255),
    receiveUserInputCapability    UserInputCapability,
    transmitUserInputCapability    UserInputCapability,
    receiveAndTransmitUserInputCapability    UserInputCapability,

    genericControlCapability    GenericCapability,
    receiveMultiplexedStreamCapability    MultiplexedStreamCapability,
    transmitMultiplexedStreamCapability    MultiplexedStreamCapability,
    receiveAndTransmitMultiplexedStreamCapability    MultiplexedStreamCapability,
    receiveRTPAudioTelephonyEventCapability    AudioTelephonyEventCapability,
    receiveRTPAudioToneCapability    AudioToneCapability
}


Разница в полях OLC в FS и структурах TCS надеюсь понятна стала ?

Насчет того, что при FS H.245 "как таковой не открывается" - это опять-таки заблуждение. Если кто-то из сторон хочет процедуру (как например панас) - она запускается.

Код
8.1.7.2    Switching to H.245 procedures
After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. Either endpoint may initiate the use of H.245 procedures at any point during the call using tunneling as described in 8.2.1 (if h245Tunneling remains enabled). An H.323 Version 4 or higher entity that uses Fast Connect in a call shall use H.245 tunneling when an H.245 Control Channel is required and shall always set the h245Tunneling field to TRUE. The process for switching to a separate H.245 connection is described in 8.2.3 and may be used by Version 3 or older entities or by newer H.323 entities when communicating with Version 3 or older entities for the purpose of maintaining backward compatibility.
When a call is established using the Fast Connect procedure, both endpoints shall keep the Q.931 Call Signalling Channel open until either the call is terminated or, for compatibility with older endpoints, until a separate H.245 connection is established.
When H.245 procedures are activated, all mandatory procedures of H.245 that normally occur upon initiation of an H.245 connection shall be completed prior to initiation of any additional H.245 procedures. The media channels that were established in the Fast Connect procedure are "inherited" as though they had been opened using normal H.245 openLogicalChannel and openLogicalChannelAck procedures. In order for such "inheritance" to succeed, media sessions opened during the Fast Connect procedure shall use only well-known sessionID values defined in Recommendation H.245.
.......SKIP......
However, an endpoint may exchange the terminalCapabilitySet message and the masterSlaveDetermination message in the Setup message as described in section 8.2.4. Such an exchange constitutes the opening of the H.245 Control Channel, but does not preclude either endpoint from proceeding with Fast Connect.


Цитата
Вся проблема, видимо, в том, что MG отвечает сообщением SetupAck без FS. Но MG в этот момент не знает, сможет ли она принять вызов, т.к не было Sending_Complete, и возможно не все цифры номера получены.
И видимо, поэтому Панас более не реагирует на поля FS, которые MG включает уже в след. сообщения (в Call_Proc).

Поделитесь с нами дампом, нам тоже интересно :-)

Цитата
2 exzerodivide:
Значит мы по-разному понимаем стандарты. Вы наблюдаете за дождем, а мы - за ротой красноармейцев. И неизвестно, что в данном случае важнее.

Игорь, не нужно мне приписывать того, что я не делаю. Я же Вам не приписываю того, чего Вы не делаете.

Цитата
Еще раз перечитал доки... Early H.245 вовсе не является дополнением к Fast Start. Это вполне самостоятельный метод.

Я это сказал в контексте связки FS и parallel H.245 в сообщениях панаса.

Цитата
Оба практически преследуют одни и те же цели - возможность передачи RTP до установления соединения (до Connect).

Опять-таки, это не совсем так. Посмотрите на структуры OLC и TCS.

Цитата
Но при Early H.245, лог. канал H.245 действительно открывается до Connect'а, а при FS стороны обмениваются необходимой информацией в сообщениях, аналогичных H.245, но без открытия Н.245 как такового.

B где-же там аналогичные сообщения ? Приведите примеры что-ли.

Цитата
Впрочем, на глубокие знания данного предмета я не претендую.. smile.gif

На глубокие знания тут никто не претендует. Достаточно читать стандарты и делать выводы.

Цитата
И давайте по-спокойнее... Корейцы, по крайней мере, пытаются найти решение, а не занимаются отписками, как обычно поступает Панас.


Да мы в общем-то и не волнуемся. К слову все забываю спросить - МГ перестала валится при получении в Setup с FS более 3(или 4) кодеков ? :-)


--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
harris
сообщение 3.10.2012, 14:28
Сообщение #16


ГУРУ
********

Группа: Участники
Сообщений: 12388
Регистрация: 23.11.2006
Из: Москва
Пользователь №: 146



Вы в чем меня хотите убедить, что MG не отвечает на TCS?? - Так я это вижу.
Я же Вам пытаюсь пояснить, почему она не отвечает на TCS. От Панаса был запрос на FS, вот она и отвечает тоже Fast Start'ом.

Дампы?? Пожалуйста: http://rusfolder.com/32941464 Пароль: panas-mg

Panasonic - MG
Panasonic - Avaya
Panasonic- iPECS LDK (cм. 1-й вызов)

Обратите внимание:
LDK (и LIK) не запрашивает след. цифры номера (не отвечает с SetupAck), а сразу дает Call_Proc с Fast Start. И Панасоник нормально работает по FS, и не запрашивает TSC (!!!). Т.е. здесь нормальный рабочий процесс установления соединения по FS.
Avaya также, как и MG отвечает с Fast Start'ом, но во втором (!!) сообщении (MG - в Call_Proc, а Avaya - в Alert). И именно это "не нравится" Панасу. Получив первое ответное сообщение без FS, Панас переходит на запрос TCS (переходит на Early H.245). Причем Панас переходит на процедуру открытия Н.245 уже после получения ответа с FS во втором сообщении от вызываемой стороны.
Правда, надо признать, что Avaya отвечает на TCS, а MG - нет. MG продолжает работать с по FS.
Вопрос: а ответ на FS станция MG обязательно должна была дать в первом ответном сообщении?? Или же в любом??
Что там по стандарту?


--------------------
Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
Перейти в начало страницы
 
+Цитировать сообщение
harris
сообщение 3.10.2012, 15:13
Сообщение #17


ГУРУ
********

Группа: Участники
Сообщений: 12388
Регистрация: 23.11.2006
Из: Москва
Пользователь №: 146



OK. Я понял, почему Панас может запрашивать TCS, даже при FS.
Непонятно, почему он тогда не запрашивает это при вызове на ipLDK/LIK.


--------------------
Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 3.10.2012, 16:46
Сообщение #18


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Цитата(harris @ 3.10.2012, 15:28) *
Вы в чем меня хотите убедить, что MG не отвечает на TCS?? - Так я это вижу.
Я же Вам пытаюсь пояснить, почему она не отвечает на TCS. От Панаса был запрос на FS, вот она и отвечает тоже Fast Start'ом.

Дампы?? Пожалуйста: http://rusfolder.com/32941464 Пароль: panas-mg

Panasonic - MG
Panasonic - Avaya
Panasonic- iPECS LDK (cм. 1-й вызов)

Обратите внимание:
LDK (и LIK) не запрашивает след. цифры номера (не отвечает с SetupAck), а сразу дает Call_Proc с Fast Start. И Панасоник нормально работает по FS, и не запрашивает TSC (!!!). Т.е. здесь нормальный рабочий процесс установления соединения по FS.
Avaya также, как и MG отвечает с Fast Start'ом, но во втором (!!) сообщении (MG - в Call_Proc, а Avaya - в Alert). И именно это "не нравится" Панасу. Получив первое ответное сообщение без FS, Панас переходит на запрос TCS (переходит на Early H.245). Причем Панас переходит на процедуру открытия Н.245 уже после получения ответа с FS во втором сообщении от вызываемой стороны.
Правда, надо признать, что Avaya отвечает на TCS, а MG - нет. MG продолжает работать с по FS.
Вопрос: а ответ на FS станция MG обязательно должна была дать в первом ответном сообщении?? Или же в любом??
Что там по стандарту?

Ну вот, пошел конструктив на одном языке :-)

В общем, по мнению-консенсу с Иваном (случай Panas-MG)
1. Панас присылает setup с canOverlapSend = FALSE и без Sending Complete, что означает неспособность работать оверлапом. Sending Complete согласно параграфу 5.2.1 Q.931 Reccomendations является опициональным:
Код
If en bloc receiving is used, the SETUP message shall contain all the information required by the
called user to process the call. In this case, the SETUP message may contain the Sending complete
information element.


2. MG присылает в ответ Setup Ask, чем изрядно удивляет панас, в ответ он шлет Status.
3. С учетом того, что панас прислал SETUP c OLC, а MG ответил CallProc с OLC, процедуру FS можно считать состоявшейся.
4. Принимая во внимание пункт 3(процедура FS состоялась), панас начинает процедуру H.245, отправляя TCS и MSD, запуская таймеры T101 и T106, MG не отвечает на указанные сообщения до истечения таймера, звонок рвется.

Что касается ответа на FS - стандарт говорит следующее:
Параграф 8.1.7

Код
When the called endpoint desires to proceed with the Fast Connect procedure, it sends a Q.931 message (Call Proceeding, Progress, Alerting, or Connect) containing a fastStart element selecting from amongst the OpenLogicalChannel proposals offered by the calling endpoint. The calling endpoint shall process each of these messages until it determines that Fast Connect is accepted or refused. Although the calling endpoint may receive the fastStart element in a Facility message sent by a Gatekeeper, the called endpoint shall not use the Facility message to send fastStart. Channels thus accepted are considered opened as though the usual H.245 openLogicalChannel and openLogicalChannelAck procedure had been followed. The called endpoint shall not include a fastStart element in any Q.931 message sent after the Connect message and shall not include fastStart in any Q.931 message unless the Setup message contained a fastStart element.


То есть, ответ может прийти в любом пакете, включая коннект.

В общем, проблем со стороны MG видится две:
1. Setup Ask в ответ на Setup со сброшенным canOverlapSend. Насколько это повлияло на общую картину - сложно сказать, но это в любом случае неправильно.
2. Игнорирование H.245-процедур до коннекта.

В качестве воркэраунда я бы посоветовал:
1. Уйти от FS и parallel (Early) H.245 на обоих станциях.
или для проверки:
1. На обоих сторонах dtmf поставить в in-band
2. T.38 выключить, факс поверх g.711alaw (ulaw)

Как-то так.


--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
exzerodivide
сообщение 3.10.2012, 17:03
Сообщение #19


Продвинутый пользователь
****

Группа: Участники
Сообщений: 169
Регистрация: 31.5.2010
Из: Default City
Пользователь №: 14690



Цитата(harris @ 3.10.2012, 16:13) *
OK. Я понял, почему Панас может запрашивать TCS, даже при FS.
Непонятно, почему он тогда не запрашивает это при вызове на ipLDK/LIK.

А точно настройки на панасе одинаковые везде ? DTMF и факс могут влиять на наличие H.245


--------------------
The sum of intelligence on the planet is a constant; the population is growing.
Перейти в начало страницы
 
+Цитировать сообщение
harris
сообщение 3.10.2012, 19:09
Сообщение #20


ГУРУ
********

Группа: Участники
Сообщений: 12388
Регистрация: 23.11.2006
Из: Москва
Пользователь №: 146



Цитата(exzerodivide @ 3.10.2012, 17:03) *
А точно настройки на панасе одинаковые везде ? DTMF и факс могут влиять на наличие H.245

В данном случае я прислал снифер вызова от другого клиента (с Панаса на ipLDK), но на котором точно такая же проблема при его стыковке с MG.
Но есть и другая трассировка именно с того же Панаса на разные направления: MG, Avaya (то, что я уже выложил) и на iPECS LIK. Так вот трассировки LIK и ipLDK одинаковые.


--------------------
Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
Перейти в начало страницы
 
+Цитировать сообщение

4 страниц V   1 2 3 > » 
Ответить в данную темуНачать новую тему
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 



Текстовая версия Сейчас: 29.4.2024, 19:22