Здравствуйте.

Наткнулся на ситуацию: если входящий вызов попадает в момент ожидания ответа на AT+CIICR, то ответить или сбросить вызов невозможно.
Модем не отвечает ни на какие команды...

[16:04:34] Recv: AT+CIICR
[16:04:37] Recv:
[16:04:37] Recv: RING
[16:04:37] Recv:
[16:04:37] Recv: +CLIP: "+ххххххххххх",145,"",0,"",0
[16:04:37] Recv:
[16:04:37] Recv: ATA - и тишина пока вызов не окончится (прилетают только URC)...

P.S. Согласен, что ситуация редкая, однако в SIM900 URC в таком месте никогда не прилетало, сперва был ответ на саму команду AT+CIICR

Ну, во-первых, все-таки не стоит подавать команду, пока не получили OK на предыдущую. Где OK на +CIICR?
Во-вторых,
》》Модем не отвечает ни на какие команды...
не отвечает это сколько? На +CIICR Max Response Time 85 seconds по инструкции.
В-третьих, если связь устанавливаем и таймауты большие, но звонок может проходить, тут мультиплексор напрашивается....

PS: экспериментирвал тут с неответом на команду во время "инициализации" модема.
Так вот, ответ приходил от 5 секунд, до, видимо, бесконечности. Видел ответ и через 60+ секунд... Бывало, и через 100 не дожидался (больше не ждал, но ответ на повторную команду тут же приходил).

На то и URC))
Попробуйте AT&D и управляйте выводом DTR модема.

В том то и дело, что ответ на CIICR прилетает только после окончания вх.вызова.

Я не против URC, но среагировать то надо как-то
Да, DTR - это решение, жаль железо уже не переделать в текущей ревизии...

Знакомое поведение, но проверял это очень давно и подробностей уже не помню.
То ли еще на SIM300 проверял, то ли уже на SIM900,
но было какое-то состояние при поднятии GPRS, когда при входящем звонке появлялся RING RING,
и модем на команды не отвечал и ожидал окончания этого входящего звонка.
После отбоя (внешнего) вываливались одним махом все мною посланные команды вместе с ответами модема.

Такое впечатление, что при звонке модем уходил на более приоритетную задачу и все другое просто приостанавливалось (подвисало).

Так что этот баг (или фича? ) у Симкома испокон веков...

Я с этим никак не борюсь, поскольку не вижу возможности, да и ситуация редкая.
Просто алгоритмы отлавливания ошибок при GPRS соединении эту ситуацию определяют и перезапускают подключение.
Вряд ли кому то нужно специально "валить" устройство при помощи такой DDOS-атаки.

з.ы. дергать DTR-ом не пробовал, может и поможет...

>>>Наткнулся на ситуацию: если входящий вызов попадает в момент ожидания ответа на AT+CIICR, то ответить или сбросить вызов невозможно.

А просто взять и на момент GPRS запретить входящие?

Так вроде и так абонент должен быть недоступен... А нас же не класс A модуль? Или, все-таки А?


Мультиплексор переразводки не потребует...

Правда, работает ли он адекватно (с MTK RTOS, ведь все проблемы от нее идут)?

Нет, не класс А, но и у вас на момент подачи команды AT+CIICR еще GPRS соединение не установлено. Оно появится только после AT+CIPSTART.
Потому и рекомендую пользоваться AT+GSMBUSY

Дурацкий вопрос. Что делать, если я не хочу запрещать входящие?
Хочется и GPRS держать как можно дольше, и дать пользователю резервный канал управления в виде DTMF'а.
Запретить - попробовать поднять сессию - разрешить?


PS старое наше решение (на модеме от другой конторы) тупо игнорирует входящий вызов, когда пытается поднять GPRS. Клиенты расстраиваются - в интернете устройства нет, и дозвониться до него сложно...

Что делать, что делать - коллизии разгребать. Особенно при выполнении операторозависимых команд.
Или вы думаете что у операторов софт умнее написан, если он позволяет отправить вызов устройству зная что устройство ждет от него ответ на команду.
Тут уж оператору надо иди крестик снять или трусы одеть.

А кто сказал, что оператор ПОЛУЧИЛ команду раньше, чем он послал вызов устройству? Логи?
Крайний случай - оба одновременно послали друг другу.
Что делать в таких случаях - должно быть описано в стандартах.
Послал != Получил(дошло).

Стандарты читают тогда, когда документация производителя уже не помогает (то есть редко).
Симком будет пенять на MTK, МТК на лицензионный GSM стек.
Опсосы будут пенять на софтописателей, те будут пенять на производителей оборудования, а они, в свою очередь, на лицензионный GSM стек, который прошел все сертификаты..

Потому и не исключены подобные ситуации.
Только опираясь на то что основная масса потребителей услуг это простые абоненты с трубками, вся эта логика у операторов строится на одном постулате.
- работает как-то и фиг с ним, а случатся коллизии - перезвонят. Потому и чудят иногда операторы не по детски зная что мало кто докопается до того что они нарушают.
Это мы видим что происходит при обмене командами-ответами. А простой юзер услышав тишину в трубке, отобьется и еще раз номер наберет.

Не по теме, но возможно будет интересно...
Наткнулся на странный ответ модема "SIM800 R14.18":

на линии обмена с модулем нет помех?..
т.к. этот ответ активирует другая команда