Вот полная (надеюсь) информация про UTR. ────────────────────────────────────────────────────────────────────── С недавних пор наша группа как будто бы располагает полной информацией о причинах возникновения и сути ошибки UTR, появившейся в 94 году. Я впервые излагаю здесь все, от начала до конца ... Итак, во всех модемах весны и осени 93 года, как спортстерах так и курьерах, есть такая ошибка: при обнаружении несущей сигнальная часть модема выдает супервизору код 4: CARRIER DETECTED. А в супервизоре ожидается почему-то несуществующий код 9, а 4 - вообще игнорируется. В результате, происходит обрыв связи, вне зависимости от значения S10 (кроме 255), в случаях, когда иные косвенные признаки появления несущей (например, Receive channel opened) не успели проявиться из-за помех на линии. Это касается протоколов группы V.32 и HST. Весьма долгое время (полтора года) эта ошибка присутствовала во всех моделях USR. Затем она была замечена, и исправлена: стали ожидать не 9, а 4. Hо при этом появился такой побочных эффект: кривые сигналы BUSY попадают в полосу частот V.32 и HST, и модемы весьма долго висят на линии, пытаясь сконнектится с короткими гудками. Все время приходят коды 5 (Carrier lost) и 4 (carrier detected), попременно, пока не исечет время на ретрейн, которое измеряется минутами. USR решила это дело поправить, добавив в ретерйн еще одну стадию, которая по их замыслу должна быть короткой, и если удаленный модем не ответил на ретрейн, то немедленно прерывать связь с кодом UTR. Эта идея вобщем-то корректная, если бы они правильно ее реализовали. А они вместо этого забыли поставить в DSP возврат кодов начала ретрейна, в результате чего первая стадия ретрейна, с точки зрения супервизора, вообще никогда не могла закончится. Hо специфика обработки кодов такова, что если код второй фазы пришел до истечения таймаута первой, то ретрейн все же проходит. Hо покольку эхогашение у них опять же сделано криво, то в 90% случаев полный ретрейн не успевает закончиться за время, отведенное для первой фазы, что и имеет название "ошибка UTR", с которой они борятся и по сей день. Теперь несколько слов о том, как это исправляется. Во-первых, считается что обладатели моделей 93 года избавлены от этой ошибки. Это так и есть, но только взамен они имеют другую -- неопределение CARRIER DETECT, которая лишь проявляется заметно реже. Hигде, кроме RC-21600, она не исправлена. Все остальные прошивки для модемов 93 года ее имеют. Во-вторых, практически любой апгрейд модемов 94 года, в первую очередь продразумевает исправление ошибки UTR. Hо исправляется она не путем добавки недостаюшего кода в DSP (это технически довольно сложно), а путем фактически ликвидации двухстадийного ретрейна путем увеличения таймаута первой фазы до таймаута второй. Так делают на сегодня все команды, включая нашу. Очевидным побочным эффектом ликцидации UTR путем растягивания первой фазы, а так же исправления ошибки CARRIER DETECT в моделях 93 года, является затягивание ретрейнов при обрыве связи, при "CONNECT с BUSY". Увы, это так и останется, как альтернатива более серьезным ошибкам. Hекоторые мейлеры (а точнее, один из них), невероятно любит делать так: посылает удаленному мейлеру, что сессия закончена, и немедленно отрубает свой же модем, не дав ему передать это сообщение. В результате, на удаленном конце это выглядит, как неожиданный разрыв связи. Специально для борьбы с идиотами в модемах USR есть регистр S38, в который можно _с обеих сторон_ записать 1 или 2, после чего этот эффект исчезает. Гораздо правильнее было бы попросить УБЕДИТЕЛЬHО автора этого мейлера исправить глюк, ибо в других мейлерах его нет, но это пока еще никому не удалось. Сложение же двух глюков - модемного и Елкинского - дает не очень приятную картину, когда в случае, если удаленный мейлер - тот самый, и он бросил трубку, не успев сказать вашему, что он кончил, то ваш модем будет минуту-другую слушать BUSY из линии, пока ваш мейлер не дернет ему DTR от безнадежности получить ответ от удаленного мейлера. Я регулярно наблюдаю эту картину при звонках ко мне с /78, и ни разу не видел при звонках моих пойнтов, пользующих FrontDoor.