| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
 Добавлено: Вт Июн 13, 2006 11:29 pm Заголовок сообщения: |
 |
|
Хух, еле откопал тему  Чет поиск у Вас глючит: по запросу "Call Waiting" я сюда почему-то не попал  (а слово "CallWaiting" на форуме и вовсе не встречается  )
Ну ладно.
Лучше расскажите, какие есть новости по сабжу за это время? |
|
| Вернуться к началу |
|
 |
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Июн 14, 2006 10:40 am Заголовок сообщения: |
|
|
Пока идея не реализована, но ... Надеемся, можно будет поэкспериментировать недельки через две.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Пн Авг 07, 2006 12:45 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Можно продолжить тему - есть код для тестирования |
Попробовал на v34 (модем--модем) --пока впечатления наилучшие По крайней мере, однозначно лучше, чем было: ложные срабатывания ушли, а несрабатываний не прибавилось. Напомню, что при таком варианте связи (у меня) CW не приводит к перетренировке. Вызванное им повышение EQM разрешается либо само по себе, либо посредством пересогласования. Но любопытно, что даже до разрешения ситуации с высоким EQM (при большом значении s117), второй сигнал успешно принимается модемом!
С серверами поэксперементирую чуть позже...
Замечание: поскольку код тестовый, можно добавить к статистике счетчик ложных (одиночных) обнаружений CW. Так будет гараздо нагляднее. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пн Авг 07, 2006 7:21 am Заголовок сообщения: |
|
|
| Цитата: | | По крайней мере, однозначно лучше, чем было: ложные срабатывания ушли, а несрабатываний не прибавилось. |
А есть ли они вообще, эти несрабатывания? Если да, то как это происходит? (Перетренировка, которая началась до прихода сигнала CW, перетренировка, вызванная сигналом CW, но не приводящая к разрыву соединения с соотв. кодом, и т.п.)
| Цитата: | | Но любопытно, что даже до разрешения ситуации с высоким EQM (при большом значении s117), второй сигнал успешно принимается модемом! |
Такое вполне возможно в ситуации, когда модем на другом конце линии достаточно терпелив. Как правило, партнёр реагирует на CW, инициируя перетренировку, и в ответ на запрос перетренировки Ваш модем должен отключаться.
В случае с V.90 перетренировка - вещь практически неизбежная.
| Цитата: | | Замечание: поскольку код тестовый, можно добавить к статистике счетчик ложных (одиночных) обнаружений CW. Так будет гараздо нагляднее. |
Если возникнут сомнения в правильности работы кода, добавим средства отладки. Ждём результатов Вашего тестирования на V.90 и будем выкладывать код на всеобщее обозрение
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Вт Авг 08, 2006 7:11 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): |
А есть ли они вообще, эти несрабатывания? |
Крайне редко несрабатывания наблюдались и со старым кодом (v2.26). Причина мною не установлена (ввиду редкости явления). Предположительно это нестандартный сигнал CW (наличие сигнала подтверждалось индикаторами EQM).
Ни каких новых несрабатываний в тестовом коде мною пока не зарегистрировано. Поэтому я и написал, что "несрабатываний не прибавилось"
Пока новый код работает корректно.
| Technical Support писал(а): | | Цитата: | | Но любопытно, что даже до разрешения ситуации с высоким EQM (при большом значении s117), второй сигнал успешно принимается модемом! |
Такое вполне возможно в ситуации, когда модем на другом конце линии достаточно терпелив. Как правило, партнёр реагирует на CW, инициируя перетренировку, и в ответ на запрос перетренировки Ваш модем должен отключаться. |
На другом конце действительно терпиливый IDC. Но с дефолтными настройками (или близкими к таковым). У меня же значение s117 ~ в 4 раза больше нормы. Тем не менее, в случае несаморазрешения ситуации, пересогласование запрашивает именно мой модем! Это наводит на мысль, что мой CW не слышен аппоненту.
Впрочем, это уже оффтоп
| Technical Support писал(а): |
В случае с V.90 перетренировка - вещь практически неизбежная.
|
Да, так и есть. На v90, после неудачного FEQM (пока 100%), мы запрашиваем перетренировку, и отключаемся.
В v34-сеансе с сервером, retrain запрашивает удаленная сторона (тоже пока в 100% случаев), и мы отключаемся.
Замечено, что в некоторых сеансах модем-модем, отключение происходло после третьего CW (случалось редко и дополнительной информации пока нет).
| Technical Support писал(а): | | Цитата: | | Замечание: поскольку код тестовый, можно добавить к статистике счетчик ложных (одиночных) обнаружений CW. Так будет гараздо нагляднее. |
Если возникнут сомнения в правильности работы кода, добавим средства отладки. |
Вы меня не правильно поняли Речь не об отладке кода, а о наглядной оценке эффективности идеи. Т.е. в конце сеанса, в статистике я хочу увидеть кол-во ситуаций, в которых v2.26 отключилась бы, а v2.27 -- нет.
PS
А есть ли еще какие-то нововведения в v2.27? |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Авг 09, 2006 9:29 am Заголовок сообщения: |
|
|
| Цитата: | | Это наводит на мысль, что мой CW не слышен аппоненту |
При правильной работе АТС так и должно быть. В направлении "к Вам" сигнал подменяется тоном Call Waiting, в направлении "от Вас" ничего не меняется.
При другом развитии событий есть риск пропустить сигнал Call Waiting. Услышав сигнал Call waiting (или изменения в сигнале партнёра), удалённый модем может инициировать перетренировку (это особенно вероятно при работе на V.90). Во время перетренировки детектировать сигнал Call waiting технически невозможно. Соответственно, если перетренировка началась до того, как сигнал Call waiting был получен и обнаружен Вашим модемом, он будет пропущен.
С этой неприятностью можно попробовать бороться, уменьшая порог обнаружения сигнала Call waiting (сейчас это допустимо, поскольку у нас есть дополнительный защитный механизм, предохраняющий от ложных срабатываний). Однако, если сигнал CW поступает после того, как удалённый модем имел шанс почувствовать изменения в качестве принимаемого сигнала и инициировал перетренировку, всё бесполезно  К счастью, у Вас такого не происходит
| Цитата: | | Замечено, что в некоторых сеансах модем-модем, отключение происходло после третьего CW |
Этой беде можно помочь, уменьшив порог срабатывания детектора.
| Цитата: | | Речь не об отладке кода, а о наглядной оценке эффективности идеи. Т.е. в конце сеанса, в статистике я хочу увидеть кол-во ситуаций, в которых v2.26 отключилась бы, а v2.27 -- нет. |
Это можно сделать, но тогда на данном этапе нельзя менять порог срабатывания, иначе сравнение будет некорректным.
| Цитата: | | А есть ли еще какие-то нововведения в v2.27? |
Есть, они появятся в whatsnew.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Ср Авг 09, 2006 8:07 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): |
Услышав сигнал Call waiting (или изменения в сигнале партнёра), удалённый модем может инициировать перетренировку (это особенно вероятно при работе на V.90). Во время перетренировки детектировать сигнал Call waiting технически невозможно. Соответственно, если перетренировка началась до того, как сигнал Call waiting был получен и обнаружен Вашим модемом, он будет пропущен. |
На мой взгляд, эта ситуация крайне маловероятна. По крайней мере, на практике такого не наблюдалось.
Ведь удаленный модем тоже руководствуется какими-то тайм-аутами, прежде чем запросить retrain. Кроме того, как правило
мы запрашивает FEQM раньше, чем удаленный успевает опомниться.
| Technical Support писал(а): | | Цитата: | | Замечено, что в некоторых сеансах модем-модем, отключение происходло после третьего CW |
Этой беде можно помочь, уменьшив порог срабатывания детектора.
|
Пожалуй, это лишено смысла. Пропуск одного сигнала и так достаточно редкое явление, так что о несрабатывании вообще речь здесь не идет.
И вообще, по моим наблюдениям несрабатывания крайне редки, и эта проблема не актуфльна.
| Technical Support писал(а): | | Цитата: | | Речь не об отладке кода, а о наглядной оценке эффективности идеи. Т.е. в конце сеанса, в статистике я хочу увидеть кол-во ситуаций, в которых v2.26 отключилась бы, а v2.27 -- нет. |
Это можно сделать, но тогда на данном этапе нельзя менять порог срабатывания, иначе сравнение будет некорректным. |
Так предоставьте это пользователю, а дефолтное зачение оставьте пока старым.
| Technical Support писал(а): | | Цитата: | | А есть ли еще какие-то нововведения в v2.27? |
Есть, они появятся в whatsnew. |
А REQ еще принимаются? |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Авг 09, 2006 10:02 pm Заголовок сообщения: |
|
|
| Цитата: | Ведь удаленный модем тоже руководствуется какими-то тайм-аутами, прежде чем запросить retrain. Кроме того, как правило
мы запрашивает FEQM раньше, чем удаленный успевает опомниться. |
К сожалению, у большинства провайдеров сервера настроены таким образом, что тайм-аут практически нулевой (тут уже не раз обсуждались Cisco, запрашивающие перетренировку на каждый "чих" в линии). При срабатывании детектора Call waiting механизм FEQM блокируется; "сработавший" FEQM свидетельствует о том, что сигнал Call waiting не был обнаружен. Да и к тому же, какая разница, кто инициировал перетренировку или пересогласование? Важно лишь то, что во время этих процедур обнаружение CW не работает.
| Цитата: | | И вообще, по моим наблюдениям несрабатывания крайне редки, и эта проблема не актуфльна. |
А вот обобщать не нужно! К сожалению, не всем повезло с АТС, и случаи несрабатывания нам известны. Причём происходит это по описанному раньше сценарию: сигнал Call waiting приходит после того, как удалённый модем инициировал перетренировку.
| Цитата: | | Так предоставьте это пользователю, а дефолтное зачение оставьте пока старым. |
Всё не так просто, как кажется: порог зависит от типа модуляции и прочих факторов. Так что лёгкого способа обеспечить регулировку нет.
| Цитата: | | А REQ еще принимаются? |
REQ всегда принимаются!
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Пт Авг 11, 2006 4:47 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Причём происходит это по описанному раньше сценарию: сигнал Call waiting приходит после того, как удалённый модем инициировал перетренировку. |
Ну ведь в этом случае "медицина бессильна"! (насколько мне известно, воздержаться от перетренировки, инициированой удаленным модемом, невозможно). Следовательно, и обсуждать тут нечего.
| Technical Support писал(а): | | Всё не так просто, как кажется: порог зависит от типа модуляции и прочих факторов. Так что лёгкого способа обеспечить регулировку нет. |
Я бы решил проблему так: создается необходимое кол-во констант (отдельно для каждого типа модуляции; они уже есть), управляющий параметр (значение регулирующего регистра) приводится к числу в диапазоне 0.8--1.2, и при инициализации сеанса связи все константы умножаются на него.
(Кстати, аналогичным методом можно воздействовать и на таблицы EQM )
А теперь REQ
Просьба реализовать следующие возможности:
1) НЕ мгновенное отключение от линии при поднятии трубки паралл./послед. телефонов.
Пауза необходима, чтобы человек, поднявший трубку, мог услышать, что линия занята модемом, и принять решение о необходимости разрыва соединения.
Отключаться здесь следует либо спустя секунд 10-15 после поднятия трубки (если за это время она не была положена), либо после 2--3(4) последовательных нажатий на рычаг (с небольшими интервалами).
2) Отключаться по поднятию только параллельного, а последовательный игнорировать.
Необходимо, когда послед. тел. используется для ведения разговора в перемешку с сеансами модемной связи (в процессе одного соединения). |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Авг 11, 2006 7:50 am Заголовок сообщения: |
|
|
| Цитата: | | Ну ведь в этом случае "медицина бессильна"! (насколько мне известно, воздержаться от перетренировки, инициированой удаленным модемом, невозможно). Следовательно, и обсуждать тут нечего. |
В некоторых случаях сигнал CW приходит, но очень короткий. Так что можно поэкспериментировать.
| Цитата: | | при инициализации сеанса связи все константы умножаются на него |
Ах, если бы только зависимость была линейной...
| Цитата: | НЕ мгновенное отключение от линии при поднятии трубки паралл./послед. телефонов.
Пауза необходима, чтобы человек, поднявший трубку, мог услышать, что линия занята модемом, и принять решение о необходимости разрыва соединения. |
В случае последовательно включённого телефона человек ничего не услышит: во время сеанса связи телефон отключён от линии.
Если телефон включён параллельно, то датчик информирует только о событии снятия трубки телефона. О том, что её положили опять на рычаг, модем ничего не знает.
| Цитата: | Отключаться по поднятию только параллельного, а последовательный игнорировать.
Необходимо, когда послед. тел. используется для ведения разговора в перемешку с сеансами модемной связи (в процессе одного соединения). |
Когда человек находится рядом с модемом, реакция на снятие трубки вообще не нужна: всё легко и удобно делается вручную. Кнопка "One Touch Phone" может быть использована для разрыва соединения.
Другое дело, что иметь возможность блокировки датчика последовательного телефона вполне логично, поскольку такая блокировка предусмотрена для датчика параллельного.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
Oxy
Member
Зарегистрирован: 03.03.2004
Сообщения: 175
Откуда: Киев
|
| Добавлено: Пт Авг 11, 2006 10:43 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | В некоторых случаях сигнал CW приходит, но очень короткий. Так что можно поэкспериментировать. |
Согласен. Но, воизбкжание ненужных большинству(?) пользователей проблем, рекомендую сделать поддержку таких "клинических случаев" опциональной.
| Technical Support писал(а): | | Цитата: | | при инициализации сеанса связи все константы умножаются на него |
Ах, если бы только зависимость была линейной...
|
Если так, то см. абзац первый Т.е. просто вкл/выкл повышеной чувствительности к CW.
| Technical Support писал(а): | | Цитата: | НЕ мгновенное отключение от линии при поднятии трубки паралл./послед. телефонов.
Пауза необходима, чтобы человек, поднявший трубку, мог услышать, что линия занята модемом, и принять решение о необходимости разрыва соединения. |
В случае последовательно включённого телефона человек ничего не услышит: во время сеанса связи телефон отключён от линии. |
Всё нормально! В этом случае, именно тишина и будет признаком занятости линии
Впрочем, речь шла именно о параллельных телефонах, установленых в соседних помещениях.
| Technical Support писал(а): | | Если телефон включён параллельно, то датчик информирует только о событии снятия трубки телефона. О том, что её положили опять на рычаг, модем ничего не знает. |
Я думал об этом, поэтому и предусмотрел второе решение :
| Oxy писал(а): | | Отключаться здесь следует либо спустя секунд 10-15 после поднятия трубки (если за это время она не была положена), либо после 2--3(4) последовательных нажатий на рычаг (с небольшими интервалами). |
| Technical Support писал(а): | | Цитата: | Отключаться по поднятию только параллельного, а последовательный игнорировать.
Необходимо, когда послед. тел. используется для ведения разговора в перемешку с сеансами модемной связи (в процессе одного соединения). |
Когда человек находится рядом с модемом, реакция на снятие трубки вообще не нужна |
Реакция на снятие трубки последовательного телефона здесь не просто не нужна, а недопустима!
В то же время, параллельные телефоны, установленые в соседних помещениях, ни кто не отменял
| Technical Support писал(а): | | иметь возможность блокировки датчика последовательного телефона вполне логично, поскольку такая блокировка предусмотрена для датчика параллельного. |
Реализуете--тогда поглядим, какой из аргументов был весомее |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
