Ложные обнаружения Call Waiting в v.2.26 :(

[Oxy]

А почти замолчать (s91=33)? Call Waiting то по по-громче будет

[Technical Support]

Нельзя менять сигнал собственного передатчика, не перенастроив эхоподавитель. А перенастроить его только через перетренировку.

Не позволяет Conexant лазить грязными руками в свой DSP
_________________
Inpro
Technical Support

[Oxy]

Пока вернулся к в общем-то оффтопному эксперементу с Forced FallBack

[Technical Support]

[Oxy]

[Technical Support]

На сайте Аналитик-ТС есть прекрасная статья Александра Пасковатого о протоколах коррекции ошибок. Статье уж 10 лет, а до сих пор актуальна.

Примерно в это же время (1995г) была его статья о проблемах реализации Selective Reject. К сожалению, отыскать её нам не удалось Но суть такая: с SREJ всё не так однозначно, потери также немаленькие и ждать существенного прироста производительности не стоит. Речь шла о дополнительных 3-5% относительно стандарной процедуры (REJ), что никак не компенсирует потери в 30 с лишним процентов.

[Oxy]

Поэксперементировал с Call Waiting. Заметил следующее.
1. В сеансе модем-модем, процентах в 70 случаев, ситуация саморазрешается в течение секунды (при достаточно большом значении s117). В остальных %28 -- через пересогласование. До Retrain дело доходит крайне редко.
2. Серверный (провайдерский) модем слышит наш CW! И на v90, как правило, он немедлено просит Retrain. Но хуже другое: ещё более немедлено, мы запрашиваем пересогласование FEQM, которое обречено на неудачу. Саморазрешение ситуации на v90 (при запрещенном FEQM и отсутствии удаленного Retrain) также абсолютно исключено. Как ведет себя сервер на v34 -- уже забыл Припоминаю только, что Retrain не есть обязательным, но ситуация хуже, чем в случае с обычным удаленным модемом.

Но алгоритм хотелось бы немного систематизировать.
Итак, факт поимки первого сигнала ставим во главу угла, и временно модифицируем поведение всех алгоритмов запроса пересогласований.
А именно:
v34 -- секунды полторы ждем саморазрешения ситуации (нормального EQM и, если повезет, возобновления предачи данных). Нет -- просим пересогласование; в случае неудачи -- отключаемся (все это время, понятное дело, обращаем внимание на Retrain).
v90 -- воздерживаемся от FEQM (более продвиутая идея: отсрочить его на стандартную длительность сигнала CW) и ждем пару секунд саморазрешения А чего это я ржу? Ведь если это был НЕ CW, то оно вполне вероятно!
И, главное, в обеих случаях ложный CW может и вовсе не создать ощутимой помехи! Тогда спокойно ждем второго сигнала.

Следует также заметить, что сигнал CW является очень сильной помехой. Три-четыре таких сигнала гарантировано валят v90!
Надо бы временно запрещать Fall Back to v34 (и воздерживаться от всяких пересогласований), если disconnect по CW не запланирован. Понятно, что логичнее было бы отключить собственно CW, но наши АТС не всегда ведут себя логично

И наконец, о парамертрах чувствительности к сигналу CW. Их целых три:
1) по амплитуде;
2) по частоте;
3) по длительности сигнала.
Не могли бы Вы объяснить, почему считаете нецелесообразной регулировку каждого из них?
И, если не секрет, какой вриант применялся в старой версии программы?

PS
Доводилось наблюдать в природе явление, вполне претендующее на ложный CW, и очень характерное для Украины (а возможно, и для всего Союза). При звонке по междугородке на занятую линию, частенько происходит кратковременное (~0,7 с) соединение с вызываемым абонентом. При этом последний слышит щелчек, иногда сопровождаемый коротким DialTone (в несколько раз корочше, чем CW). Но в моём случае причина, скорее, какая-то иная.

PPS Пишу всё это не для "красного словца", а в связи с тем, что задолбали ложные срабатывания!

[Oxy]

Удалил повтор. Кстати, разрешили бы удалять последний пост

[Technical Support]

[Oxy]

[Technical Support]

[Oxy]

[Technical Support]

[Oxy]

[Technical Support]