Denis писал(а):
Решилась ли проблема после перепрошивки?
Перешил на более старую версию 8.51.001, т.к. присланная Вами 8.51.002 оказалась точно такой, что и была в шлюзе в момент покупки.
При входящих звонках со стороны GSM оператора проблема с отваливанием портов вроде как ушла.
При звонках со стороны VoIP в сторону GSM шлюз ведет себя следующим образом:
Первый звонок с момента включения шлюза был сделан на номер ГТС 848762NNNNN без установления голосового соединения (абонент на удаленной стороне не поднял трубку).
[4321.602] GSM-0/0: RTA CALL REQUEST, 848762NNNNN
[ERROR] ReadPDU error!! TPKT must be 4bytes. receive_data result(-4)
// эта ошибка мне непонятна, если возможно прошу пояснить ее смысл.[4331.418] GSM-0/0: RTA CALL DISCONNECT
[4331.797] GSM-0/0: CALL REQUEST FAILED, result(-2)
[4331.897] Interface GSM-0/0, changed state to DOWN
[4332.097] GSM-0/0: RTA CALL DISCONNECT (REJECT), ST(6)
[4337.817] Interface GSM-0/0, changed state to UP
Второй звонок сделан на тот же номер, но уже с установлением голосового соединения.
[4412.837] GSM-0/0: RTA CALL REQUEST, 848762NNNNN
[4419.337] GSM-0/0: CALL CONNECTED (outgoing)
[4431.420] GSM-0/0: CALL DISCONNECT by DISCONNECT event
Третий звонок опять на тот же номер без установления голосового соединения (абонент на удаленной стороне не поднял трубку).
[4445.841] GSM-0/0: RTA CALL REQUEST, 848762NNNNN
[4460.073] GSM-0/0: RTA CALL DISCONNECT
[4460.437] GSM-0/0: CALL REQUEST FAILED, result(-2)
[4460.537] Interface GSM-0/0, changed state to DOWN
[4460.837] GSM-0/0: RTA CALL DISCONNECT (REJECT), ST(6)
[4463.817] Interface GSM-0/0, changed state to UP
Полноценное тестирование требует времени. Единственное, что можно сказать с уверенностью, проблема уже не выглядит настолько катастрофной. Обещаю за выходные протестировать более внимательно и отписаться о результатах.
2. Что касается некорректной обработки занятости мобильного номера, она осталась как и прежде.
Попробую описать ситуацию подробнее.
В шлюз воткнута SIM карта с телефонным номером (910) 946XXXX. Внешний по отношению к нам абонент1 с номером (910) 946YYYY набирает номер (910) 946XXXX. GSM модуль получает запрос на установление соединения, в трубке абонента1 слышен сигнал КПВ.
В этот момент абонент2 с номером (910) 946ZZZZ также пытается позвонить на номер (910) 946XXXX и получает ответ автоинформатора мобильного оператора "в настоящий момент абонент не может быть вызван. перезвоните позже". Т.е. для остальных абонентов сети мобильного оператора на временной отрезок от момента поступления входящего вызова до момента начала разговора с абонентом1 номер (910) 946XXXX оказывается отключенным от сети, а должен быть занят.
С момента начала разговора (включения голосового тракта) до момента окончания разговора абонентов (910) 946XXXX и (910) 946YYYY все остальные абоненты мобильного оператора, позвонившие на номер (910) 946XXXX получают ответ автоинформатора "абонент занят, дождитесь ответа", как это и должно быть.
Т.е. на временной отрезок с момента поступления входящего звонка до момента начала разговора с абонентом1 (т.е. звонок уже поступает, идет ALERTING, абонент1 со стороны мобильного оператора слышит в трубке сигнал КПВ) для остальных абонентов сети мобильного оператора этот номер находится в статусе "абонент недоступен", что есть неправильно. Поскольку если вынуть карту из шлюза и смоделировать эту же ситуацию на обычных мобилах абонент с номером (910) 946ZZZZ получает сигнал занятости абонента (910) 946XXXX, как оно и должно быть.
Почему это неприемлемо:
Если номер (910) 946XXXX в шлюзе принадлежит например колцентру службы такси, внешние абоненты, получившие ответ "абонент не может быть вызван" не перезванивают на этот номер позже, а считают что он больше не обслуживается и тупо стирают его из записных книжек своих телефонов. При этом на рекламу контактного телефона (910) 946XXXX уже потрачены средства. В итоге клиент, купивший шлюз Addpac, останется недоволен.