ipecs-100 voip panasonic tde-200 Опции

[Den]

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

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

подскажите где искать проблему? трейс снимался с тде, на картинках странности:

Прикрепленные файлы

 ipecs_tde.rar ( 2,08 килобайт ) Кол-во скачиваний: 30
 1.jpg ( 101,52 килобайт ) Кол-во скачиваний: 96
 2.jpg ( 111,84 килобайт ) Кол-во скачиваний: 75

 

[All is not what ...]

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

[exzerodivide]

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

[Den]

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]

Или шестизначный номер это правильно?
Тогда почему не оформил должным образом, чтоб на него не приходилось отвечать setupAcknowledge?

6значный - правильно.
Как понять не оформил правильно?

[exzerodivide]

С планом нумерации все в порядке, он и должен быть 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 заодно.

[exzerodivide]

6значный - правильно.
Как понять не оформил правильно?

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

[Fray]

Вечер добрый.
Есть ли решение для данной проблемы? На версии 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]

Вечер добрый.
Есть ли решение для данной проблемы? На версии 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]

"возможности терминала" в FS гораздо меньше чем в TCS.
Панас в своём праве.
Отвячать на TCS обязательно.

[exzerodivide]

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

Увы. Решения этой ситуации до сих пор нет, хотя корейцы пытались на нескольких версиях скорректировать эту ситуацию со своей стороны, в том числе и на версии 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 если сами не могут.

[harris]

"возможности терминала" в 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 как такового.
Впрочем, на глубокие знания данного предмета я не претендую..
И давайте по-спокойнее... Корейцы, по крайней мере, пытаются найти решение, а не занимаются отписками, как обычно поступает Панас.

[WAHLW]

2exzerodivide:
Объясняйся доступней, а то видишь что мимо выпалил.

[harris]

2exzerodivide:
Объясняйся доступней, а то видишь что мимо выпалил.

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

[exzerodivide]

С чего Вы это взяли?? Такие же возможности, как и в 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 где-же там аналогичные сообщения ? Приведите примеры что-ли.

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

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

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

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

[harris]

Вы в чем меня хотите убедить, что 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]

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

[exzerodivide]

Вы в чем меня хотите убедить, что 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)

Как-то так.

[exzerodivide]

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

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

[harris]

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

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

[exzerodivide]

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

Выложите пож. одинаковые(одна и та же станция при неизменных настройках) с Avaya, Cisco и LIK/ipLDK.
А то разные станции (а их видно по версиям и фирмварям) немного смущают.

[harris]

Выложите пож. одинаковые(одна и та же станция при неизменных настройках) с Avaya, Cisco и LIK/ipLDK.
А то разные станции (а их видно по версиям и фирмварям) немного смущают.

Предыдущие трассировки с MG и с Avaya были сняты на одной станции, по крайней мере мы получили их от одного нашего партнера. Во вложении в данном посте снифер трасcировки с LIK, полученный от того же партнера.

Прикрепленные файлы

 panas_lik_120622.rar ( 223,92 килобайт ) Кол-во скачиваний: 9

 

[exzerodivide]

Вердикт в двух словах: партнеру незамедлительно выправить руки, особенно сетевикам-затейникам.
Теперь развернуто:
1.Мы видим классический состоявшийся FS между панасом и ликом.
2. По завершению процедуры FS, исходя из того, что у обоих сторон стоит h225.h245Tunnelling = FALSE, панас в соответствии с требованиями стандарта, параграф 8.2.3 Switching to a separate H.245 connection

Код

When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. In order to facilitate initiation of the separate H.245 connection by either endpoint, each endpoint may include h245Address in any Q.931 message it sends during the call. 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. Use of the separate H.245 connection is initiated by opening the H.245 TCP connection and accepted by acknowledgement of the H.245 TCP connection.

отправляет facility (пакет номер 81 в дампе) с reason:startH245, при этом поле ipAddress = 192.168.0.103, но адрес, с которого на самом деле шлет панас - 80.69.147.250.
Далее LIK, в соответствии с вышеуказанным параграфом:

Код

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. Use of the separate H.245 connection is initiated by opening the H.245 TCP connection and accepted by acknowledgement of the H.245 TCP connection.

отправляет TCP SYN с адреса 61.41.111.85 на адрес 192.168.0.103 порт 10109 (пакет номер 83 в дампе).
Разумеется, это ни к чему не приводит, что подтверждается отсутствием ACKов.
С учетом того, что стандарт не содержит указаний, что делать в таких случаях, панас замирает в таком состоянии и не реагирует на запросы LIK об открытии H.245 (см Connect LIKа).

Так что вывод простой: панас ПЫТАЕТСЯ вести себя, как и в предыдущих снифах, но кривые настройки сети (NAT и т.д.) мешают ему это сделать.

UPD: Если возвращаться к началу разговора то видно, что между панасом и МГ H.245 нормально открывается (startH245->SYN->SYN,ACK->ACK), панас отправляет TCS и MSD, но МГ отвечает только на MSD, TCS игнорирует, что и приводит к обрыву звонка.

[harris]

ОК. Спасибо.
Запрос по поводу TCS я давным-давно отправил в Корею. Сделали несколько тестовых версий с попытками скорректировать софт, но пока что так и не устранили проблему. Напишем еше раз.

Так все-таки, можно ли для проверки сделать так, чтобы Панас присылал Sending Complete??

[exzerodivide]

Я бы для начала убедился что в настройках у порнослоника действительно стоит en bloc.
Все гайды пишут что у него по дефолту overlap, а при включенном наборе en bloc ом нужно добавлять #.

ИМХО это особо на ситуацию не влияет, но потренироваться можно.

[All is not what ...]

Port No. Settings
H.225 Port No. 1720
H.245 Port No. 1721
RAS Port No. 1719
RTP/RTCP Port No. 5004
Voice CODEC Settings
Voice CODEC Priority
1st G711
2nd none
3rd none
4th none
Gatekeeper Settings
Gatekeeper - Use / Don't use
Primary Gatekeeper IP Address
Primary Gatekeeper Port No.
Secondary Gatekeeper IP Address
Secondary Gatekeeper Port No.
Gatekeeper Connection Checking Interval (min) 0-1440min
Call Signaling Model Direct / Routed (via Gatekeeper)
Others
Fast Connect Use / Don't use
Возможные настройки на панасоник.

[exzerodivide]

Ты прям для сабжевого панаса написал ?

[exzerodivide]

Нашел кстати в закромах родины дамп.
172.16.18.1 - Cisco 2821, инициатор
172.16.18.250 - транслятор имен Display IE <-> H.450
172.16.20.100 - MG 100
Делал год назад примерно.
Что примечательно:
1. Цыска шлет SETUP без SENDING COMPLETE, но с h225.canOverlapSend = FALSE
2. MG присылает SetupAck, но цыска не ругается Status'ом.
3. Цыска инициирует H.245 до коннекта, при этом процедура корректно отрабатывается MG.
4. Единственный баг - на факсе MG переключается с G.729 на G.711 вместо T.38

Так что early h.245 раньше прекрасно работал, сломали где-то по пути.

Прикрепленные файлы

 1341_5207_tun_on_fs_on_fax_g711.pcap.zip ( 3,81 килобайт ) Кол-во скачиваний: 3

 

[harris]

Нашел кстати в закромах родины дамп.
172.16.18.1 - Cisco 2821, инициатор
172.16.18.250 - транслятор имен Display IE <-> H.450
172.16.20.100 - MG 100
Делал год назад примерно.
Что примечательно:
1. Цыска шлет SETUP без SENDING COMPLETE, но с h225.canOverlapSend = FALSE
2. MG присылает SetupAck, но цыска не ругается Status'ом.
3. Цыска инициирует H.245 до коннекта, при этом процедура корректно отрабатывается MG.
4. Единственный баг - на факсе MG переключается с G.729 на G.711 вместо T.38

Так что early h.245 раньше прекрасно работал, сломали где-то по пути.

А какая версия прошивки была на MG?? 1.7 ??

[exzerodivide]

[GS55H17Ai.rom] Html V File Extract Success![745]
[HtmlExtractProcess]extract end
Thu Jun 30 14:45:00 UTC 2011
[SYSLOG ][11/06/30 14:45:38]

[SYSLOG ][11/06/30 14:45:38] ===== START iPECS-MG_SYSTEM =====
[SYSLOG ][11/06/30 14:45:38] Version : iPECS-MG 55M-1.7Ai
[SYSLOG ][11/06/30 14:45:38] Release Date : MAR/11
[SYSLOG ][11/06/30 14:45:38] Working Dir : /
[SYSLOG ][11/06/30 14:45:38] Process ID : (PID 81)
[SYSLOG ][11/06/30 14:45:38] First Main Act2 Init-Complete Ver(1.1)

[harris]

[GS55H17Ai.rom] Html V File Extract Success![745]
[HtmlExtractProcess]extract end
Thu Jun 30 14:45:00 UTC 2011
[SYSLOG ][11/06/30 14:45:38]

[SYSLOG ][11/06/30 14:45:38] ===== START iPECS-MG_SYSTEM =====
[SYSLOG ][11/06/30 14:45:38] Version : iPECS-MG 55M-1.7Ai
[SYSLOG ][11/06/30 14:45:38] Release Date : MAR/11
[SYSLOG ][11/06/30 14:45:38] Working Dir : /
[SYSLOG ][11/06/30 14:45:38] Process ID : (PID 81)
[SYSLOG ][11/06/30 14:45:38] First Main Act2 Init-Complete Ver(1.1)

ОК. Спасибо!

[Alexey A. Astash...]

Сейчас скажу оффтопом:
НИКОГДА, НИКОГДА не используйте H.323 протокол для связки LG с обордованием отличным от LG, иначе будут прекрасные танцы с бубном проще всего использовать протокол SIP, и еще лучше связать данные станции через промежуточный Asterisk учстановленный гденибудь на виртуалке. Кстати панас с Астером по H.323 вроде живет нормально, LG вроде тоже работает, но есть проблемы, результат - перевели все на SIP.

[vldmr]

Так вроде? Или живёт?

[All is not what ...]

Вместо офтопа специалист излагает конкретные факты, того что не так.
Если не может сам то обращается к специалистам, вам насколько мне известно, предлагалась помощь, однако вы скомпрометировали того кто пытался вам помочь, а теперь делаете тоже самое с производителем станций.

[Dron]

Вместо офтопа специалист излагает конкретные факты, того что не так.
Если не может сам то обращается к специалистам, вам насколько мне известно, предлагалась помощь, однако вы скомпрометировали того кто пытался вам помочь, а теперь делаете тоже самое с производителем станций.

Согласен на все 100! К сожалению, неквалифицированная установка, зачастую, создает негативное отношение к оборудованию в целом! Легче всего свалить все на оборудование, чем признаваться(особенно перед заказчиком), что не знаешь каких то тонкостей настройки данного оборудования.
А совсем уж идеальных железок нет...

[exzerodivide]

Сейчас скажу оффтопом:
НИКОГДА, НИКОГДА не используйте H.323 протокол для связки LG с обордованием отличным от LG, иначе будут прекрасные танцы с бубном проще всего использовать протокол SIP, и еще лучше связать данные станции через промежуточный Asterisk учстановленный гденибудь на виртуалке. Кстати панас с Астером по H.323 вроде живет нормально, LG вроде тоже работает, но есть проблемы, результат - перевели все на SIP.

Ничего подобного. У меня в связке через 2821 работали: CUCM 6, ipLDK-300 и MG-100 по h.323 с сетевым планом. Единственное, что потребовало доработки - имена абонентов между лыжей и не-лыжей.
Так что - дорогу осилит идущий, все проблемы решаемы, тем более - при наличии опенсорсного астера.

[Alexey A. Astash...]

Ничего подобного. У меня в связке через 2821 работали: CUCM 6, ipLDK-300 и MG-100 по h.323 с сетевым планом. Единственное, что потребовало доработки - имена абонентов между лыжей и не-лыжей.
Так что - дорогу осилит идущий, все проблемы решаемы, тем более - при наличии опенсорсного астера.

Я и не говорил что работать не будет, работать будет, но пляски с бубном обеспечены H.323 очень специфический протокол и разные вендоры его реализуют хрен пойми как в отличии от SIP, с которым тоже проблемы есть но гораздо меньшие.

[Alexey A. Astash...]

Вместо офтопа специалист излагает конкретные факты, того что не так.
Если не может сам то обращается к специалистам, вам насколько мне известно, предлагалась помощь, однако вы скомпрометировали того кто пытался вам помочь, а теперь делаете тоже самое с производителем станций.

Для любой задачи каждый сам решает какое количество услий необходимо потратить, в нашем случае было проще изучить Asterisk и сменить протокол на SIP. От себя добавлю, что лучше связки чем iPECS--Asterisk я еще не видел, они прекрасно дополняют друг друга, и следующая станция которую я буду брать именно iPECS.
А (ИМХО) H.323 прекарсный протокол, но он в действительности отлично работает между оборудованием одного вендора, тем не менее все настраивается и с Panasonic возможно работать будет и с Avaya работает, но он устарел этот протокол и крупные вендоры врядли будут дорабатывать реализацию.
LG с Asterisk по H.323 работает ужасно и хотя были найдены некоторые пути решения, они также не дали в конечном итоге жалаемого результата.

[AXEL]

Дополню. НИКОГДА, НИКОГДА не связывайтесь с Астериском . Иначе вся ваша дальнейшая деятельность будет сводится к тому, чтоб только поддерживать его работоспособность. А если еще он и в открытом доступе в интернете, то защита от злоумышленников будет съедать львиную долю вашего времени.

[Alexey A. Astash...]

Дополню. НИКОГДА, НИКОГДА не связывайтесь с Астериском . Иначе вся ваша дальнейшая деятельность будет сводится к тому, чтоб только поддерживать его работоспособность. А если еще он и в открытом доступе в интернете, то защита от злоумышленников будет съедать львиную долю вашего времени.

ну уже на самом деле не все так грустно, ненадо просто забывать о некоторых вещах при настройке системы и с работоспособностью, и с безопаностью проблем не будет. Конечно для изуения Asterisk и его настройки уйдет времени гораздо больше чем при изучении аппаратных коммерческих решений.

[AXEL]

ну уже на самом деле не все так грустно, ненадо просто забывать о некоторых вещах при настройке системы и с работоспособностью и с безопаностью проблем не будет.

Угу. А китайскому школьнику не получить никогда хорошей отметки, если он не вскрыл ни одного русского астериска.

[exzerodivide]

Я и не говорил что работать не будет, работать будет, но пляски с бубном обеспечены H.323 очень специфический протокол и разные вендоры его реализуют хрен пойми как в отличии от SIP, с которым тоже проблемы есть но гораздо меньшие.

Использование SIP на лыже дает 2 существенных ограничения:
1. Невозможность использования сетевого плана в том виде, как это предусмотрено разработчиками.
2. Имена абонентов пропадают.

H.323 ни разу не специфичный, в отличие от сипа он базируется на Q.931 и жестко стандартизирован, чего не скажешь о сипе, где каждый лепит что может, кладя на RFC огромный болт. Для общего развития рекомендую посмотреть что с сипом сделала МС в линке, а так же зоопарк с шифрованием.
То, что конкретно в вашем случае в меньшей степени повезло с h.323 и в большей - с сипом - заслуга сугубо Ваша и астера.
Основные косяки лыжного h.323-стека изъезжены вдоль и поперек, способы обхода описаны, как мной так и Иваном, и работало это как в связке, описанной мной (причем базовый функционал был поднят за 2 дня), так и в связке с астером у Ивана.
Пользуясь случаем хотел спросить - как у Вас на сипе работает трансфер и форвард когда оба плеча на voip ? :-)

[Alexey A. Astash...]

Угу. А китайскому школьнику не получить никогда хорошей отметки, если он не вскрыл ни одного русского астериска.

у меня Asterisk внутренний, наружу не глядит, потому незнаю как там китайцы будут его ломать, в одном повторюсь что Asterisk всеголишь лучшее дополнение к iPECS. потому что iPECS у нас по нормальному так и не заработал с МТС и с Ростелекомом, а вторая версия прошивки в которой действительно разработчиками исправлен баг (который я отправлял и помогал описать) еще сырая. в дальнейшем это просто будет бесполезный оффтоп.

[AXEL]

, а вторая версия прошивки в которой действительно разработчиками исправлен баг (который я отправлял и помогал описать) еще сырая. в дальнейшем это просто будет бесполезный оффтоп.

Прошивка официальная, сделанная по Россию.

[Alexey A. Astash...]

Использование SIP на лыже дает 2 существенных ограничения:
1. Невозможность использования сетевого плана в том виде, как это предусмотрено разработчиками.
2. Имена абонентов пропадают.

H.323 ни разу не специфичный, в отличие от сипа он базируется на Q.931 и жестко стандартизирован, чего не скажешь о сипе, где каждый лепит что может, кладя на RFC огромный болт. Для общего развития рекомендую посмотреть что с сипом сделала МС в линке, а так же зоопарк с шифрованием.
То, что конкретно в вашем случае в меньшей степени повезло с h.323 и в большей - с сипом - заслуга сугубо Ваша и астера.
Пользуясь случаем хотел спросить - как у Вас на сипе работает трансфер и форвард когда оба плеча на voip ? :-)

1. Действительно для нормального сетевого плана по SIP ipLDK не годится, нужен минимум iPECS.
2. Имена да, действительно на SIP работают в один конец это минус.

Все трансферы и форварды работают нормально по SIP.
Нормально также работет IVR и распределеие звонков через IVR на любой офис. Есть нюанс, все LG станции между собой свзязаны по H.323, и все звонки между Asterisk шлюзами и ipLDK разруливает iPECS-MG, вот тут и вышло его прекрасное дополнение. А так при необходимости с телефонного аппарата можно сделать Transfer вызова на любую станцию включая Asterisk абонентов и наоборот.

[Alexey A. Astash...]

Прошивка официальная, сделанная по Россию.

К сожалению после последней вздрючки (на 1.7Di станция перезагружается при работе с МТС, прошивался на B.0Ce возникли другие проблемы), генералы запретили эксперементирвать с прошивками станции потому пришлось откатываться на 1.7Di и искать альтернативу, после настройки теперь все работает даже лучше чем хотелось в B.0Ce было много багов, частично которые я успел отправить. одним из багов было то, что не освобождаются внешние линии, что в результате приводит к невозможности совершить звонок. теперь я вынужден ждать нормальных релизов
еслибы мне было на чем эксперементировать т.е. стоял бы у меня инженерный образец я бы обязательно проводилбы эксперименты и выдавал бы регулярные отчеты о найденых багах.

[exzerodivide]

1. Действительно для нормального сетевого плана по SIP ipLDK не годится, нужен минимум iPECS.
2. Имена да, действительно на SIP работают в один конец это минус.

Все трансферы и форварды работают нормально по SIP.
Нормально также работет IVR и распределеие звонков через IVR на любой офис. Есть нюанс, все LG станции между собой свзязаны по H.323, и все звонки между Asterisk шлюзами и ipLDK разруливает iPECS-MG, вот тут и вышло его прекрасное дополнение. А так при необходимости с телефонного аппарата можно сделать Transfer вызова на любую станцию включая Asterisk абонентов и наоборот.

Рекомендую посмотреть на занятие VOIB каналов при трасфере на MG когда оба плеча на сипе.

[Alexey A. Astash...]

Рекомендую посмотреть на занятие VOIB каналов при трасфере на MG когда оба плеча на сипе.

Не выявил проблем (да и раньше их небыло)

внешний Вх.звонок по SIP на Asterisk(1) IVR --> transfer по SIP --> iPECS-MG внутр.абонент --> transer SIP --> Asterisk(2) внутр.абонент --> transfer SIP --> iPECS-MG внутр.абонент --transfer H.323 --> ipLDK внутр.абонент.

Итого на iPECS-MG занялось всего 4 канала из 32 имеющихся (VOIB24+VOIB8), тем не менее все тесты прошли успешно, и удалось поговорить по всем тестируемым линиям. Понятно что режим reroute работать не будет, но в общем нам всеравно при таком количестве каналов, темболее таких сложных звонков у нас просто не бывает.

[mixaz]

а по сабжу новости есть? развели оффтоп....

[mixaz]

Еще разок подниму тему.
Есть ли какие-нибудь изменения по этому вопросу?

[Andrew87]

Добрый день,

Тоже интересует данный вопрос. Новостей нет?

[harris]

Добрый день,

Тоже интересует данный вопрос. Новостей нет?

Вниманию всех заинтересованных лиц!!
Данная затянувшаяся на долгое время ( увы) проблема по связке Panasonic и MG по H.323 наконец-то решена (после очередного "пинка" разработчикам). Корейцам наконец-то удалось найти баг в софте и устранить его. Теперь входящие H.323 вызовы от Панаса нормально отрабатываются в MG, и Панас не отбивает вызов.
В данный момент проблема устранена на тестовой версии B[2].1Bx.
В ближайшее время аналогичные исправления будут внесены в официальную версию 2.5.

[Andrew87]

Вниманию всех заинтересованных лиц!!
Данная затянувшаяся на долгое время ( увы) проблема по связке Panasonic и MG по H.323 наконец-то решена (после очередного "пинка" разработчикам). Корейцам наконец-то удалось найти баг в софте и устранить его. Теперь входящие H.323 вызовы от Панаса нормально отрабатываются в MG, и Панас не отбивает вызов.
В данный момент проблема устранена на тестовой версии B[2].1Bx.
В ближайшее время аналогичные исправления будут внесены в официальную версию 2.5.

Добрый день,

Не появилась версия 2,5? Сроки выхода не известны?

[harris]

Добрый день,

Не появилась версия 2,5? Сроки выхода не известны?

По последней информации от разработчиков они внесли изменения в версию B[2].5Bb аналогично выше упомянутой B[2].1Bx.
Так что данная проблема должна быть решена на B.5Bb.
Увы, проверить версию В.5Bb с Panasonic'ом у нас нет сейчас возможности.
Если есть желание проверить, то могу выслать этот тестовый софт.

Официальный релиз версии 2.5B должен появиться в течении 1- 1,5 мес.

[NektoSK]

По посcjбледней информации от разработчиков они внесли изменения в версию B[2].5Bb аналогично выше упомянутой B[2].1Bx.
Так что данная проблема должна быть решена на B.5Bb.
Увы, проверить версию В.5Bb с Panasonic'ом у нас нет сейчас возможности.
Если есть желание проверить, то могу выслать этот тестовый софт.

Официальный релиз версии 2.5B должен появиться в течении 1- 1,5 мес.

Вышлите софт на selkonst собака rikt.ru или на selkonst собака ya.ru , давно ждём, вчера вот напомнили.
и

[harris]

Вышлите софт на selkonst собака rikt.ru или на selkonst собака ya.ru , давно ждём, вчера вот напомнили.
и

О какой именно версии идет речь: B[2].1Bx или B[2].5Bb ?

[NektoSK]

О какой именно версии идет речь: B[2].1Bx или B[2].5Bb ?

Хотелось бы официальну, но пока поджимают можно и попробовать тестовую. В общем ту, которая через 8 сек. не рвёт связь с Panasonic_ом. Я так понял пока только есть B[2].1Bx. версия, 2.5 ещё ждать месяц?

[Dron]

Хотелось бы официальну, но пока поджимают можно и попробовать тестовую. В общем ту, которая через 8 сек. не рвёт связь с Panasonic_ом. Я так понял пока только есть B[2].1Bx. версия, 2.5 ещё ждать месяц?

MPB-100 B[2].5Bb
MPB-300 B[2].5Bb

[NektoSK]

MPB-100 B[2].5Bb
MPB-300 B[2].5Bb

Спасибо, попробуем как подготовимся.

[Andrew87]

Добрый день!

Снова вернусь к данному вопросу.
Правильно ли я понимаю.
Прошивка iPECS-MG/GS56M-2.5Ci OCT/14, новее чем iPECS-MG/GS56M-B.5Bb FEB/14?

Столкнулись с тем что на 2.5Ci вновь происходят обрывы при звонке по voip(h.323) на Panasonic. Ещё пока тестируем может у нас баг какой-то. Кто-то может проверить у себя? Не могли Корейцы в новой прошивки вернуть старый баг?

[harris]

Добрый день!

Снова вернусь к данному вопросу.
Правильно ли я понимаю.
Прошивка iPECS-MG/GS56M-2.5Ci OCT/14, новее чем iPECS-MG/GS56M-B.5Bb FEB/14?

Столкнулись с тем что на 2.5Ci вновь происходят обрывы при звонке по voip(h.323) на Panasonic. Ещё пока тестируем может у нас баг какой-то. Кто-то может проверить у себя? Не могли Корейцы в новой прошивки вернуть старый баг?

Могли... Но только давайте уточним суть проблемы. Если я правильно помню, то это не совсем уж баг MG, Панас тоже ведет себя не совсем "в рамках приличия". Запрашивает Fast Start, и MG отвечает тоже как Fast Start. А потом Панас переходит на процедуры, которые применяются в процессе Normal Start. Это Панас разъединяет вызов, а вовсе не MG !!
Проблема всплыла только со старыми Панасами. Kорейцы пошли навстречу, и подправили свой софт, чтобы "подыграть" Панасу!!

[Andrew87]

Могли... Но только давайте уточним суть проблемы. Если я правильно помню, то это не совсем уж баг MG, Панас тоже ведет себя не совсем "в рамках приличия". Запрашивает Fast Start, и MG отвечает тоже как Fast Start. А потом Панас переходит на процедуры, которые применяются в процессе Normal Start. Это Панас разъединяет вызов, а вовсе не MG !!
Проблема всплыла только со старыми Панасами. Kорейцы пошли навстречу, и подправили свой софт, чтобы "подыграть" Панасу!!

Harris, добрый день!

Я полностью с вами согласен, мы с вами как-то давно в личке ещё по этому вопросу переписывались. Так же согласен что косячет Панас, что было выявлено нами, а позже мы нашли эту тему на форуме и поняли что не одиноки. Причём при обращение в службу поддержки панаса, они вежливо шлют всех куда подальше... Честно сказать, я тогда был приятно удивлен что Корейцы пошли на встречу и достаточно быстро решили этот вопрос. Просто хотелось бы, что бы в новых прошивках тоже все правильно было для работы с Панасоником, что бы можно было не задумываясь обновляться (лично я так и думал, что так будет). Есть возможность проверить новую прошивку?

[harris]

Harris, добрый день!

Я полностью с вами согласен, мы с вами как-то давно в личке ещё по этому вопросу переписывались. Так же согласен что косячет Панас, что было выявлено нами, а позже мы нашли эту тему на форуме и поняли что не одиноки. Причём при обращение в службу поддержки панаса, они вежливо шлют всех куда подальше... Честно сказать, я тогда был приятно удивлен что Корейцы пошли на встречу и достаточно быстро решили этот вопрос. Просто хотелось бы, что бы в новых прошивках тоже все правильно было для работы с Панасоником, что бы можно было не задумываясь обновляться (лично я так и думал, что так будет). Есть возможность проверить новую прошивку?

Добрый день, уважаемый Andrew87!
К сожалению, у меня нет возможности проверить версию 2.5Сi с Панасом. Поэтому я только что просто тупо отправил срочный запрос в Корею, чтобы они проверили версию 2.5Сi на наличие в ней тех же самых правок, ранее сделанных в версиях B.1Bx и B.5Bb.
Надеюсь, что в понедельник-вторник на след. неделе получу ответ от разработчиков. Естественно, сразу же отпишусь здесь. Если вдруг выяснится, что они забыли включить эти правки в официальный релиз ( ), тогда будем их "нагибать", чтобы они срочно устранили следы своей забывчивости.

[vitalii]

Добрый день!

Снова вернусь к данному вопросу.
Правильно ли я понимаю.
Прошивка iPECS-MG/GS56M-2.5Ci OCT/14, новее чем iPECS-MG/GS56M-B.5Bb FEB/14?

Столкнулись с тем что на 2.5Ci вновь происходят обрывы при звонке по voip(h.323) на Panasonic. Ещё пока тестируем может у нас баг какой-то. Кто-то может проверить у себя? Не могли Корейцы в новой прошивки вернуть старый баг?

откатитесь обратно на iPECS-MG/GS56M-B.5Bb FEB/14. что в не устраивало Вас, чтобы подымать версию?

[Andrew87]

Добрый день, уважаемый Andrew87!
К сожалению, у меня нет возможности проверить версию 2.5Сi с Панасом. Поэтому я только что просто тупо отправил срочный запрос в Корею, чтобы они проверили версию 2.5Сi на наличие в ней тех же самых правок, ранее сделанных в версиях B.1Bx и B.5Bb.
Надеюсь, что в понедельник-вторник на след. неделе получу ответ от разработчиков. Естественно, сразу же отпишусь здесь. Если вдруг выяснится, что они забыли включить эти правки в официальный релиз ( ), тогда будем их "нагибать", чтобы они срочно устранили следы своей забывчивости.

Спасибо, за такую оперативность! Даже как-то не удобно, вдруг где-то наш косяк.. до конца пока не успели проверить, объект с панасом был доступен только с утра, на след. недели будем логи снимать смотреть более подробно.

[Andrew87]

откатитесь обратно на iPECS-MG/GS56M-B.5Bb FEB/14. что в не устраивало Вас, чтобы подымать версию?

Да всё в принципе устраивает, мы вообще обновлялись с 1.7)). Если не получится с этой разобраться, то естественно пойдем на B.5Bb.
Тут вопрос в том, что бы хотелось, чтобы это исправление присутствовало во всех новых версиях, чтобы в дальнейшем допустим при важном переходи на прошивку 3.... не получить проблемы с не раб. телефонией. Я думаю если раз решили вопрос, то не тяжело его дальше поддерживать.

[harris]

Да всё в принципе устраивает, мы вообще обновлялись с 1.7)). Если не получится с этой разобраться, то естественно пойдем на B.5Bb.
Тут вопрос в том, что бы хотелось, чтобы это исправление присутствовало во всех новых версиях, чтобы в дальнейшем допустим при важном переходи на прошивку 3.... не получить проблемы с не раб. телефонией. Я думаю если раз решили вопрос, то не тяжело его дальше поддерживать.

Пришел ответ из Кореи от разработчиков. Они подтвердили, что версия 2.5Ci включает в себя все те же исправления в протоколе H.245, сделанные ранее на тестовых версиях B.1Bx и B.5Bb.
Так что, если сейчас опять всплыла какая-то проблема при стыковке с Панасом, то тогда нужно снимать снифер WireShark'ом и смотреть, что там происходит.

[Andrew87]

Пришел ответ из Кореи от разработчиков. Они подтвердили, что версия 2.5Ci включает в себя все те же исправления в протоколе H.245, сделанные ранее на тестовых версиях B.1Bx и B.5Bb.
Так что, если сейчас опять всплыла какая-то проблема при стыковке с Панасом, то тогда нужно снимать снифер WireShark'ом и смотреть, что там происходит.

Большое спасибо, будем смотреть!

[Andrew87]

Добрый день!

Не было времени тут отписаться. Вообщем проверили все несколько раз. Работает эта прошивка с Panasonic'ом. Первый раз, что то регион. администраторы не так настроили. Спасибо всем откликнувшимся!