Проблемы с кодом DSP от Conexant

[Antarex]

Так как это сообщение делается, когда в нашем городе уже наступило 8 марта, а в Москве еще было 7 марта :-) то прежде всего я хотел бы поздравить женский персонал компании Inpro с праздником и пожелать удачи, счастья и благополучия! Отдельные поздравления девушкам-пользователям IDC!

Ну а теперь 2 моих вопроса:

1. Некоторое время назад на модемном Форуме iXBT обсуждалась интересная ситуация с DSP от Conexant, когда при определенных помехах во время пересогласования скорости, которое запрашивает IDC /VR+ после помехи, происходит сбой и из динамика модема слышен очень необычный звук, который продолжается примерно секунд 6. По истечении этого промежутка времени IDC запрашивает ретрейн. Так вот, самое интересное - это как отреагирует удаленный модем на такую исключительную ситуацию, например, удаленные ZyXEL Omni 56K, которые применяет в нашем городе один провайдер, по истечении этих 6 секунд просто бросает трубку... :-( Cisco 3600, который применяет у нас другой провайдер также иногда по истечении этих 6 секунд бросает трубку, но иногда дело заканчивается обычным ретрейном и связь не рвется. В некоторых случаях после этих 6 секунд у IDC бывает 2-секундный "вертолет" (еще одна исключительная ситуация чипсета от Conexant), после которого Cisco 3600 бросает трубку.

Напомню, что по умолчанию в IDC /VR+ используется фирменный режим %E3, которого нет в других модемах на таком же чипсете, то есть даже при сильных помехах модем стремится к пересогласованиям скорости после помех, а ретрейны запрашиваются только при очень сильных помехах. Так вот, парадокс в том, что если при сильных помехах IDC запрашивает fallback, то иногда возникает вышеописанная ситуация со "странным" 6-секундным звуком, иногда переходящем в 2-секундный "chopper" ("вертолет") и при коннекте с ZyXEL Omni 56K и Cisco 3600 проблема приводит к тому, что эти удаленные модемы бросают трубку.

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

Я задавал вопросы о этой исключительной ситуации разработчику микропрограмм IDC Майку Телису и получил такой ответ:

--------------------------------------

Mike Telis>

Dear Dmitry,

sorry for the delay. I've been discussing this situation with Conexant's DSP
group and Yuri Bondarenko (you've reported this problem to him, haven't
you?).

Here is the summary:

Take a look at the last 5-8 seconds prior to disconnect. If you applied a
spectrum analysis algorithm (like Walsh or Blackmann) you'd see that the
signal
is a mix of 2400 Hz (tone B) and 1800 Hz (TRN). It means that our modem is
sending TRN and ZyXEL is in error recovery (sending tone B). It went on for
about 5-6 seconds and then ZyXEL dropped connection. Soon after that our
modem
would switch to sending of tone A (1200 Hz), it's easy to check "between the
busy tones".

Of course, the problem with ZyXEL is that ZyXEL was not waiting enough for
our
modem to respond to tone B. The WAV you sent me is _very_ wrong: it's
start-up handshake and the modem is supposed to wait S7 seconds. Retrains
are different but most of the modems (all but ZyXEL, so far) are waiting for
either 1 minute or S7/2 seconds.

About these 6 seconds. In many cases our DSP can't handle this situation
(failure at 64 or 84) correctly and we need to run a workaround to push the
DSP
back to phase 2.

This workaround is fired 6 seconds after the DSP gets stuck. I used to have
a
shorter time-out (4 seconds) but it caused problems with CISCO/MICA (and
maybe,
some other modems). It seems like our DSP needs 6 seconds to setup its
internal
flags; if I push it earlier than 6 secs, it would transmit INFO0 which is
dead
wrong.

I think that his only option is to contact ZyXEL about this issue, send them
this recording and ask to extend their wait time.

Yuri wasn't very optimistic about this idea (contacting ZyXEL), his
experience with their tech support is very bad - they never bothered to fix
the problems he reported to them. Nevertheless, it's the only way.

Using %E2 or %E1 does not fix the problem. It might reduce the probability
of running into this exceptional situation but does not in any way helps the
modems to recover from it. Thus, if you do face with the problem - ZyXEL
would disconnect :-(

-------------------------------

Так вот, в модемной конференции iXBT Temperton (автор замечательной программы ModemSPD ) предложил использовать 4-секундную задержку при работе по протоколу v34bis и 6-секундную задержку при работе по протоколу v90. Я хотел бы спросить, насколько такое предложение целесообразно?

2. Могли бы уважаемые Inpro Technical Support расказать о другой исключительной ситуации с DSP от Conexant, насколько я помню это сбой во время одной из фаз ретрейна, который был "обойден" в IDC? (я читал упоминание об этом в данном Форуме)

[Oxy]

Очень интересные вопросы. Хотелось бы все-же услышать мнение Technical Support

[Technical Support]

В общем-то, тут и комментировать нечего. Есть ZyXEL, который швыряет трубку, не дождавшись ответа на тон B. Есть теоретическая возможность с этим бороться (сократив тайм-аут). Проверить, сработает ли, можно (перепрошив версию 2.20, как было сказано в форуме).

В любом случае, речь идёт об ошибке у ZyXEL, которую надо (им) исправлять.
_________________
Inpro
Technical Support