TAU-32M добавляет цифры к хотлайну при входящем звонке( если в линии запрос АОН)
Добавлено: 21 янв 2016 12:41
Добрый день, коллеги!
Тема добавления цифр к номеру hotline при входящем звонке на порт FXO TAU мной уже поднималась, но развития в силу непонятной
эпизодичности воспринимаемого дефекта развития не получила.
Выявить закономерность помог случай. Итак, новое внедрение в нашем филиале- отделении, районный центр. Оборудование на "приземлении" - TAU-32m.IP с модулем FXO, порты зарегистрированы на астериске.
Астериск - 192.168.19.220, Тау - 192.168.19.230, регистрирующиеся номера 195Х, номера hotline 197Х соответственно.
После внедрения начались жалобы на невозможность дозвона со "старых" номеров поселка.
Поскольку такое уже было и на это вовремя обратили внимание, проблему обнаружили и зафиксировали быстро.
Перед внедрением поменяли номера на "новые", умеющие работать в тоне. Межгород/мобильные/новые поселковые- без проблем, "старые" номера - проблема. Запросили провайдера об используемом оборудовании "новом" и "старом", вот ответ:
---==============================----------
Тип станции:
9-90-хх(9-91-хх) - АЛС-4096С цифровая;
9-7х-хх (9-8х-хх) АТСК 100/2000 (аналоговая, координатная) Для работы
оборудования АПУС на данной АТС, необходимо что бы информация АОН выдавалась
непрерывно, т.е. при любом входящем вызове, при установлении соединения,
информация АОН поступает вызываемому абоненту без специального запроса.
---==============================-----------
Догадались? Если сходу нет ( а это нужно разок принять вызов с АТСК100/2000) то поясню: входящий звонок ВСЕГДА сопровождается отправкой со стороны АТС информации АОН о звонящем, это слышно при поднятии трубки. Звонок с "новой" АТС этим и отличается от звонка со "старой", других различий нет. Факт повторяемый и фиксируемый, так что говорить о стечении обстоятельств давайте не будем. Моя версия:
----=============-----------
Суть проблемы:Вчера обратились из С* коллеги с жалобами на
недозвон на наши номера 9-90-ХХ (всех, не буду перечилслять это пока
непринципиально) со СТАРОЙ АТС п.С* ( номера 9-70-ХХ).С новой АТС
С*, с мобильных и пр дозвон в обе стороны отличный и проблем
нет.Выяснилось следующее: когда идет дозвон со старых номеров при поднятии
трубки АТС отдает номер вызывающего в формате "безинтервальный пакет" (АОН).
Наше оборудование ( Eltex TAU-32m.ip) принимает вызов, и как показали
исследования, реагирует на "безинтервальный пакет" добавлением (!!!) к
запрограммированному номеру горячей линии дополнительной цифры, что и
вызывало сбой в работе оборудования.Ошибка трудноуловимая, ибо всякой логике
такое противно, а поймать было сложно( схожие проблемы были с Eltex в
В* и Г*), но вот теперь есть все подтверждения со стороны нашего
оборудования,достаточные для реакции со стороны производителя.
----============-----------
Есть дампы и сислог с ТАУ, ну и сама ситуация. Вот в качестве примера звонок с 5 порта ( номер 1954 на 1974 hotline, а по факту на 19743):
---=============-----------
|Time | 192.168.19.230 |
| | | 192.168.19.220 |
|538.110695 | INVITE SDP (g711A g7 |SIP From: "1954" <sip:1954@192.168.19.220 To:<sip:19743@192.168.19.220
| |(5065) ------------------> (5060) |
|538.111508 | 401 Unauthorized |SIP Status
| |(5065) <------------------ (5060) |
|538.442524 | ACK | |SIP Request
| |(5065) ------------------> (5060) |
|538.571853 | INVITE SDP (g711A g7 |SIP From: "1954" <sip:1954@192.168.19.220 To:<sip:19743@192.168.19.220
| |(5065) ------------------> (5060) |
|538.574939 | 100 Trying| |SIP Status
| |(5065) <------------------ (5060) |
|538.769370 | 180 Ringing |SIP Status
| |(5065) <------------------ (5060) |
|538.825053 | 180 Ringing |SIP Status
| |(5065) <------------------ (5060) |
|541.124448 | 200 OK SDP (g711U g7 |SIP Status
| |(5065) <------------------ (5060) |
|541.181481 | RTP (g711U) |RTP Num packets:452 Duration:9.015s SSRC:0x52984E6
| |(35202) <------------------ (17526) |
|541.624264 | 200 OK SDP (g711U g7 |SIP Status
| |(5065) <------------------ (5060) |
|542.038743 | ACK | |SIP Request
| |(5065) ------------------> (5060) |
|543.869514 | RTP (g711U) |RTP Num packets:358 Duration:7.140s SSRC:0x6271D048
| |(35202) ------------------> (17526) |
|550.228897 | BYE | |SIP Request
| |(5065) <------------------ (5060) |
|550.318331 | 200 OK | |SIP Status
| |(5065) ------------------> (5060) |
-------=================-----------
Дампы и пр вышлю по запросу если нужно. Повторяю- ситуация АБСОЛЮТНО повторяема, для простоты астериск сконфигурирован такие звонки на 197ХХ обрабатывать, так что даже статистика есть. Железная зависимость- есть посылка безинтервального пакета, добавляется цифра, нет- не добавляется.
Другое дело как быть с тем, что в 3 населенных пунктах (2 города и 1 пгт) благодаря такой "особенности" ВАШЕГО оборудования связь для наших клиентов была выборочно - невозможна? Учитывая особенности глубинки ( подумаешь, какой то потребитель не дозвонился, чего управление беспокоить- порочная логика на местах), мог бы вообще ничего не узнать.А мы гарантирующий поставщик электроэнергии в регионе, для нас связь жизненно необходима. Возможно, мы не одни. Выискивать ошибки такого рода где всё должно быть вылизано- себе дороже.
Если информация по ошибке будет вами подтверждена, то хотелось бы лично встретиться и пообщаться, получается, это уже не первая выявленная мной особенность. Пожелания и предложения тоже было бы эффективнее проговорить непосредственно. Приглашение и пр с вас, дорогие коллеги.
Тема добавления цифр к номеру hotline при входящем звонке на порт FXO TAU мной уже поднималась, но развития в силу непонятной
эпизодичности воспринимаемого дефекта развития не получила.
Выявить закономерность помог случай. Итак, новое внедрение в нашем филиале- отделении, районный центр. Оборудование на "приземлении" - TAU-32m.IP с модулем FXO, порты зарегистрированы на астериске.
Астериск - 192.168.19.220, Тау - 192.168.19.230, регистрирующиеся номера 195Х, номера hotline 197Х соответственно.
После внедрения начались жалобы на невозможность дозвона со "старых" номеров поселка.
Поскольку такое уже было и на это вовремя обратили внимание, проблему обнаружили и зафиксировали быстро.
Перед внедрением поменяли номера на "новые", умеющие работать в тоне. Межгород/мобильные/новые поселковые- без проблем, "старые" номера - проблема. Запросили провайдера об используемом оборудовании "новом" и "старом", вот ответ:
---==============================----------
Тип станции:
9-90-хх(9-91-хх) - АЛС-4096С цифровая;
9-7х-хх (9-8х-хх) АТСК 100/2000 (аналоговая, координатная) Для работы
оборудования АПУС на данной АТС, необходимо что бы информация АОН выдавалась
непрерывно, т.е. при любом входящем вызове, при установлении соединения,
информация АОН поступает вызываемому абоненту без специального запроса.
---==============================-----------
Догадались? Если сходу нет ( а это нужно разок принять вызов с АТСК100/2000) то поясню: входящий звонок ВСЕГДА сопровождается отправкой со стороны АТС информации АОН о звонящем, это слышно при поднятии трубки. Звонок с "новой" АТС этим и отличается от звонка со "старой", других различий нет. Факт повторяемый и фиксируемый, так что говорить о стечении обстоятельств давайте не будем. Моя версия:
----=============-----------
Суть проблемы:Вчера обратились из С* коллеги с жалобами на
недозвон на наши номера 9-90-ХХ (всех, не буду перечилслять это пока
непринципиально) со СТАРОЙ АТС п.С* ( номера 9-70-ХХ).С новой АТС
С*, с мобильных и пр дозвон в обе стороны отличный и проблем
нет.Выяснилось следующее: когда идет дозвон со старых номеров при поднятии
трубки АТС отдает номер вызывающего в формате "безинтервальный пакет" (АОН).
Наше оборудование ( Eltex TAU-32m.ip) принимает вызов, и как показали
исследования, реагирует на "безинтервальный пакет" добавлением (!!!) к
запрограммированному номеру горячей линии дополнительной цифры, что и
вызывало сбой в работе оборудования.Ошибка трудноуловимая, ибо всякой логике
такое противно, а поймать было сложно( схожие проблемы были с Eltex в
В* и Г*), но вот теперь есть все подтверждения со стороны нашего
оборудования,достаточные для реакции со стороны производителя.
----============-----------
Есть дампы и сислог с ТАУ, ну и сама ситуация. Вот в качестве примера звонок с 5 порта ( номер 1954 на 1974 hotline, а по факту на 19743):
---=============-----------
|Time | 192.168.19.230 |
| | | 192.168.19.220 |
|538.110695 | INVITE SDP (g711A g7 |SIP From: "1954" <sip:1954@192.168.19.220 To:<sip:19743@192.168.19.220
| |(5065) ------------------> (5060) |
|538.111508 | 401 Unauthorized |SIP Status
| |(5065) <------------------ (5060) |
|538.442524 | ACK | |SIP Request
| |(5065) ------------------> (5060) |
|538.571853 | INVITE SDP (g711A g7 |SIP From: "1954" <sip:1954@192.168.19.220 To:<sip:19743@192.168.19.220
| |(5065) ------------------> (5060) |
|538.574939 | 100 Trying| |SIP Status
| |(5065) <------------------ (5060) |
|538.769370 | 180 Ringing |SIP Status
| |(5065) <------------------ (5060) |
|538.825053 | 180 Ringing |SIP Status
| |(5065) <------------------ (5060) |
|541.124448 | 200 OK SDP (g711U g7 |SIP Status
| |(5065) <------------------ (5060) |
|541.181481 | RTP (g711U) |RTP Num packets:452 Duration:9.015s SSRC:0x52984E6
| |(35202) <------------------ (17526) |
|541.624264 | 200 OK SDP (g711U g7 |SIP Status
| |(5065) <------------------ (5060) |
|542.038743 | ACK | |SIP Request
| |(5065) ------------------> (5060) |
|543.869514 | RTP (g711U) |RTP Num packets:358 Duration:7.140s SSRC:0x6271D048
| |(35202) ------------------> (17526) |
|550.228897 | BYE | |SIP Request
| |(5065) <------------------ (5060) |
|550.318331 | 200 OK | |SIP Status
| |(5065) ------------------> (5060) |
-------=================-----------
Дампы и пр вышлю по запросу если нужно. Повторяю- ситуация АБСОЛЮТНО повторяема, для простоты астериск сконфигурирован такие звонки на 197ХХ обрабатывать, так что даже статистика есть. Железная зависимость- есть посылка безинтервального пакета, добавляется цифра, нет- не добавляется.
Другое дело как быть с тем, что в 3 населенных пунктах (2 города и 1 пгт) благодаря такой "особенности" ВАШЕГО оборудования связь для наших клиентов была выборочно - невозможна? Учитывая особенности глубинки ( подумаешь, какой то потребитель не дозвонился, чего управление беспокоить- порочная логика на местах), мог бы вообще ничего не узнать.А мы гарантирующий поставщик электроэнергии в регионе, для нас связь жизненно необходима. Возможно, мы не одни. Выискивать ошибки такого рода где всё должно быть вылизано- себе дороже.
Если информация по ошибке будет вами подтверждена, то хотелось бы лично встретиться и пообщаться, получается, это уже не первая выявленная мной особенность. Пожелания и предложения тоже было бы эффективнее проговорить непосредственно. Приглашение и пр с вас, дорогие коллеги.