| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
 Добавлено: Пт Сен 16, 2005 12:42 pm Заголовок сообщения: |
 |
|
Вопрос: сообщения DATE/TIME/NMBR появляются при каждом входящем звонке, или время от времени Вы их не видите?
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
 |
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Пт Сен 16, 2005 8:16 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Вопрос: сообщения DATE/TIME/NMBR появляются при каждом входящем звонке, или время от времени Вы их не видите? |
Сообщения DATE/TIME/NMBR появляются при каждом входящем звонке с вероятностью 85%. Выслаю вам синхронизированные участки лог-файлов Windows и VentaFax в которых номер не определился. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Сен 16, 2005 9:23 pm Заголовок сообщения: |
|
|
Так в том-то и дело, что Ventafax почему-то слишком рано вступает в игру!
Посмотрите на протокол, в котором номер был "пойман":
| Код: | 12:33:59.97 # Tapi:RING 1 of 6
12:33:59.97 # Tapi:REPLY P1=10043, P2=0
12:33:59.97 # Tapi:(0x010387/0x010352) CALLINFO:
12:33:59.98 # Tapi:(0x010387/0x010352) CONNECTED:
12:34:00.04 # InQS=4096 OutQS=8192 1
12:34:00.04 # InQS=8192 OutQS=8192 1
12:34:00.04 # DCB: fInX=0 XonL=4096 XoffL=1024 fOutX=0 fOutxCtsFlow=0 BRate=115200 fDtrCtrl=1 fRtsCtrl=2
12:34:00.04 # Returned: CRate=115200, FXon=0, FCts=0
12:34:00.08 > ATQ0V1E0&D2X4S0=0
12:34:00.10 < OK
12:34:00.14 > ATI1
12:34:00.16 < 140
12:34:00.16 < OK
12:34:00.20 > ATM1L1S7=50
12:34:00.22 < OK
12:34:00.26 > ATS31.4=1S52=129
12:34:00.28 < OK
12:34:00.28 # Table type: IDC */VR (Rockwell Voice)
12:34:00.34 # IDC-*/VR
12:34:00.34 # MaxSpdOut=5, MaxSpdInp=5, MinSpdOut=0, MinSpdInp=0, ConTime=30
12:34:00.36 > AT#CID=1S52.0=1S19.6=1S113=6S112=10S116=0
12:34:00.38 < OK
12:34:00.60 > ATS22.7?
12:34:00.65 < 000
12:34:00.65 < OK
12:34:00.65 # $ SnoopMode $ (2540909)
12:34:00.65 # ~InOn: RecOn, AONOff; ~OutOn: RecOn
12:34:00.65 # ~Hidden connection: On
12:34:00.65 # Setting: CRate=115200, FXon=0, FCts=1
12:34:00.67 # SnoopMode: Waiting a call
12:34:00.95 < DATE = 0825
12:34:00.95 < TIME = 1231
12:34:00.95 < NMBR = 912492**** |
(номер звонящего "забили" звёздочками). Как видите, информация о Caller ID приходит примерно через секунду после входящего звонка:
12:33:59.97 # Tapi:RING 1 of 6
12:34:00.95 < NMBR = 912492****
При правильной работе через TAPI приём и разбор номера выполняются самим TAPI, т.е. TAPI принимает и разбирает RING/DATE/TIME/NMBR, и только потом управление передаётся Ventafax. У Вас же всё происходит иначе:
| Код: | 09-16-2005 19:52:21.289 - Принято: <cr><lf>RING<cr><lf>
09-16-2005 19:52:21.289 - Интерпретированный ответ: Звонок
09-16-2005 19:52:21.289 - TSP(0000): LINEEVENT: LINE_NEWCALL
09-16-2005 19:52:21.289 - TSP(0000): LINEEVENT: LINECALLSTATE_OFFERING
09-16-2005 19:52:21.289 - TSP(0000): LINEEVENT: LINEDEVSTATE_RINGING(0x1)
09-16-2005 19:52:21.389 - TSP(0000): Вход в сквозной режим
09-16-2005 19:52:21.389 - Сквозной режим вкл. |
Как видите, уже через 100 мс управление попадает к Ventafax, и работа программы "накладывается" на работу FSK Caller ID.
Заметим, что в отличии от АОН, где результат определения номера сохраняется модемом и может быть извлечён позднее (через ati11, например), FSK и DTMF Caller ID - вещь "одноразовая": информация расшифровывается и выдаётся на лету, нигде не сохраняется и впоследствии её уже не достать.
Если выдаваемые программой "навстречу" команды сбивают процесс, то информация теряется.
Вот почему мы просим всё проверить из терминальной программы. Надо убедиться, что в этом варианте всё работает правильно (вероятность проблемы хоть и не велика, но есть). После этого можно приступить к "разбору полётов" с Ventafax.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Пт Сен 16, 2005 11:58 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Так в том-то и дело, что Ventafax почему-то слишком рано вступает в игру! |
Может быть наоборот - слишком поздно, смотрите:
Ошибка определения номера
19:52:21.47 # Tapi:RING 1 of 6
19:52:22.47 # SnoopMode: Waiting a call
19:52:25.34 # Detected RING 2 of 6
Нормальное определение номера
02:52:20.08 # Tapi:RING 1 of 6
02:52:20.71 # SnoopMode: Waiting a call
02:52:21.00 < DATE = 0823
02:52:21.00 < TIME = 0250
02:52:21.02 < NMBR = 912492****
02:52:24.04 # Detected RING 2 of 6
| Technical Support писал(а): | | При правильной работе через TAPI приём и разбор номера выполняются самим TAPI, т.е. TAPI принимает и разбирает RING/DATE/TIME/NMBR, и только потом управление передаётся Ventafax. |
Думаю, что вы заблуждаетесь. TAPI, по возможности, как можно быстрее передает управление программе ожидающей входящий звонок.
Надо попробовать избавиться от лишних команд:
| Код: | 02:52:20.17 > ATQ0V1E0&D2X4S0=0
02:52:20.23 > ATI1
02:52:20.29 > ATM1L1S7=50
02:52:20.35 > ATS31.4=1S52=129
02:52:20.45 > AT#CID=1S52.0=1S19.6=1S113=6S112=10S116=0
02:52:20.69 > ATS22.7? |
и повысить приоритет процесса VentaFax, т.к. я заметил, что вероятность ошибки определения номера увеличивается с повышением загрузки микропроцессора. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Сен 17, 2005 8:05 am Заголовок сообщения: |
|
|
| Цитата: | | Думаю, что вы заблуждаетесь. TAPI, по возможности, как можно быстрее передает управление программе ожидающей входящий звонок |
Правильнее сказать, что TAPI как можно быстрее информирует прикладную программу о событиях, которые случаются с модемом. Этот момент и не оспаривается 
Мы писали: "Так в том-то и дело, что Ventafax почему-то слишком рано вступает в игру!".
Имелось в виду следующее: Ventafax берёт управление на себя слишком рано. Вы настроили программу так, чтобы она отвечала на 6-й звонок:
12:33:59.97 # Tapi:RING 1 of 6
При правильном подходе к делу программа должна была дождаться прихода сообщения о входящем звонке (первом), затем информации о номере звонящего (DATE/TIME/NMBR), опять-таки от TAPI, потом ещё пяти входящих звонках, и уж затем приступить к выполнению своей работы.
У нас есть подозрение, почему Ventafax слишком рано взялся за дело. Наверное, это из-за включённого у Вас режима регистрации входящих звонков (поскольку TAPI посылает одно и то же сообщение как при поступлении входящего звонка, так и при снятии трубки телефонного аппарата).
Эти вопросы надо обсудить с техподдержкой "Венты". Но прежде всего, надо убедиться в том, что при работе в режиме at#cid=1 из терминала номера определяются стабильно. Вы провели такой эксперимент?
| Цитата: | | Надо попробовать избавиться от лишних команд и повысить приоритет процесса VentaFax, т.к. я заметил, что вероятность ошибки определения номера увеличивается с повышением загрузки микропроцессора |
Избавиться от лишних команд без помощи разработчиков программы не удастся.
Предлагаем такой план:
1. Убедиться в правильной работе из терминальной программы (если Вы это ещё не сделали).
2. Если всё хорошо, то написать письмо в службу техподдержки "Венты", как это описано в разделе "Если у вас возникли вопросы" Help-a к программе. Приложите те же журналы, которые отправляли к нам по e-mail и дополнительно, пришлите им ссылку на эту тему (они редко заглядывают в наш форум).
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Сб Сен 17, 2005 2:59 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | TAPI посылает одно и то же сообщение как при поступлении входящего звонка, так и при снятии трубки телефонного аппарата. |
Заблуждаетесь 
TAPI вообще не определяет Caller id, т.к. независимо от правильности определения входящего звонка в лог-файле | Код: | | Tapi: CallerID=, CallerIDName= |
фиксация номера происходит программой VentaFax
| Код: | 02:52:21.00 < DATE = 0823
02:52:21.00 < TIME = 0250
02:52:21.02 < NMBR = 912492**** |
также как и в терминале.
| Technical Support писал(а): | | Избавиться от лишних команд без помощи разработчиков программы не удастся. |
| Код: |
02:52:20.17 > ATQ0V1E0&D2X4S0=0
02:52:20.23 > ATI1
02:52:20.29 > ATM1L1S7=50
02:52:20.35 > ATS31.4=1S52=129
02:52:20.45 > AT#CID=1S52.0=1S19.6=1S113=6S112=10S116=0
02:52:20.69 > ATS22.7?
02:52:20.71 < 000
02:52:20.71 < OK |
Итого 54 мс. Можно безболезнено сократить на 24 мс, если избавиться от | Код: | | AT#CID=1S52.0=1S19.6=1S113=6S112=10S116=0 |
|
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Сен 17, 2005 4:21 pm Заголовок сообщения: |
|
|
| Цитата: | | Заблуждаетесь TAPI вообще не определяет Caller id, т.к. независимо от правильности определения входящего звонка ... фиксация номера происходит программой VentaFax |
Ещё раз: программа работает не так, как должна. При правильной работе разбор сообщения NMBR выполняет TAPI. Для этого в драйвере mdmidc.inf есть соответствующие строчки (поглядите на досуге). В данном конкретном случае TAPI не получает сообщений Caller ID от модема из-за того, что Ventafax перетаскивает одеяло на себя, переводя TAPI в pass-through до того, как от модема приходит NMBR.
Пожалуйста, скажите: Вы проверяли работу Caller ID из терминала?
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Вс Сен 18, 2005 12:01 am Заголовок сообщения: |
|
|
| Technical Support писал(а): | | программа работает не так, как должна. |
Хотя при этом определяет номер с вероятностью 85-90%
Возможно, проблема не в модеме, а в VentaFax. А если точнее - VentaFax не хватает времени на инициализацию и переход в сквозной режим и она теряет пакет (FSK) передаваемый АТС между первым и вторым звонком.
Последний раз редактировалось: HCode (Ср Янв 04, 2006 10:53 am), всего редактировалось 1 раз |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Вс Сен 18, 2005 7:34 am Заголовок сообщения: |
|
|
| Цитата: | | Проблема однозначно не в модеме, а в VentaFax |
Ну вот, наконец-то получили хотя бы косвенный ответ на вопрос:
"Пожалуйста, скажите: Вы проверяли работу Caller ID из терминала?"
| Цитата: | | VentaFax не хватает времени на инициализацию и переход в сквозной режим и она теряет пакет (FSK) передаваемый АТС между первым и вторым звонком |
Возможно, хотя нам более вероятным представляется другой сценарий, изложенный ранее: выдаваемые программой "навстречу" команды сбивают процесс приёма и декодирования FSK Caller ID. Передаваемые модемом сообщения накапливаются в буфере драйвера последовательного порта. Если бы речь шла лишь о "паузе", когда TAPI уже "отдал" порт, а Ventafax ещё не "взял", то DATE/TIME/NMBR попали бы в этот буфер.
В любом случае, Вам нужно приступать к выполнению п. 2 изложенного ранее плана.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Ср Янв 04, 2006 11:20 am Заголовок сообщения: |
|
|
Попробую подвести итоги:
1. Так как нестабильность определения номера наблюдается и при работе в терминале, то ошибка связана не с VentaFax.
2. Как показал эксперимент с записью звука без поднятия трубки
| Код: | atz
ats52.7=1 s52.1=1
at#cls=8 #vbs=8 #vsr=7200
ata:3000
at#vrx |
с последующим анализом содержимого - FSK пакет всегда передается АТС между первым и вторым звонком. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Ср Янв 04, 2006 9:42 pm Заголовок сообщения: |
|
|
За время Вашего отсутствия были выявлены обстоятельства происходящего. "Пропадание" FSK Caller ID наблюдалось на другой АТС при высоком уровне сигнала (короткая абонентская линия). Было найдено аппаратное решение проблемы и идёт работа над микропрограммным решением. К сожалению, из-за праздников не сможем предложить эти решения сейчас... придётся дождаться окончания каникул наших разработчиков.
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Пт Янв 13, 2006 8:51 pm Заголовок сообщения: |
|
|
| Я заметил, что модем с такой же вероятностью 10-15% при наборе номера сообщает, что в линии отсутствует гудок. |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Пт Янв 13, 2006 8:57 pm Заголовок сообщения: |
|
|
Врядли тут есть какая-нибудь связь, но давайте попробуем исследовать.
Скажите, а когда модем сообщает об отсутствии гудка, он (гудок) при этом присутствует? Слышите ли Вы его в динамике модема?
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
HCode
Member
Зарегистрирован: 12.08.2005
Сообщения: 34
|
| Добавлено: Пт Янв 13, 2006 9:13 pm Заголовок сообщения: |
|
|
| Technical Support писал(а): | | Скажите, а когда модем сообщает об отсутствии гудка, он (гудок) при этом присутствует? Слышите ли Вы его в динамике модема? |
Нет |
|
| Вернуться к началу |
|
|
Technical Support
Expert
Зарегистрирован: 31.10.2002
Сообщения: 6330
|
| Добавлено: Сб Янв 14, 2006 7:57 pm Заголовок сообщения: |
|
|
Если гудка нет, то модем и должен сообщать о его отсутствии. Почему нет... это нужно выяснять на АТС. Может быть, слишком часто номер перенабираете?
_________________
Inpro
Technical Support |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Войти и проверить личные сообщения
Вход
