Привет всем - кто нибудь реализовывал такое, если приходит вызов без номера А его нужно отклонять. Как можно реализовать данную задачу? Мысли есть - но нехочется экперементировать на живых абонентах (вдруг что не так сделаю).
Запрет вызовов без номера А
Страница: 1
Сообщений 1 страница 15 из 15
Поделиться22010-04-05 03:13:54
У меня есть похожая проблема: УПАТС присоединена к сишке по EDSS1. Получается такая ситуация-УПАТС может создавать у себя любые "кривые" А номера не из выделенного сегмента номеров, а сишка устанавливает соединение по таким номерам. Соответственно, они идут в отсев по биллингу. Вопрос в следующем: можем ли мы делать преданализ, чтобы отклонять такие вызова? Техподдержка предлагает прописать все номера УПАТС у себя через ADD PRA и на линке поставить флаг "netwqork check flag"=YES. Нас такой вариант не устраивает из-за большого количества абонентов и направлений. Может быть кто-нибудь решил такую проблему?
Поделиться32010-04-05 08:03:44
Та же беда 
Поделиться42010-04-06 08:58:20
Коллеги, я что не пойму. У моих коллег была подобная ситуация. Местная сельская АТС не слала А-номер. Это для нашей станции был входящий. На станции ничего не сделали с билиндерами договорились, что они буду подставлять unknown. А по Вашей схеме дедушка с маленьго села не сможет дозвониться, а это есть вообще не правильно. Или я чего-то не понял...?
Поделиться52010-04-06 09:11:49
Да нет не в дедушке дело. Ситуация такая: Есть городская АТС (сишка), к нему по PRA подцеплена УПАТС, которая шлет кривые номера А. В свою очередь, абоненты УПАТС выходят через сишку на телефонную сеть, посему в биллинге вызова получаются исходящие, соответственно кривые вызова падают в отсев. Приходится разбираться с какого направления эти вызова пришли, т.к. таких присоединенных УПАТС у нас более 20-ти.
Поделиться62010-04-07 10:12:55
Не ужели никто не делал такое? Суть просто в том, что есть недобросовестные абоненты которые шлют левые номера или вообще вызова без номера. В таком случае тарификация ложится на пилотный номер. Но нас не совсем это устраивает.
Поделиться72010-06-30 18:35:24
А кто что может подсказать по такой проблемке: есть оконечки M-200 (на 320 платформе) и координатки АТСК с АОН на крокусах работают по CAS, так вот при звонках с них на вышестоящую АМТС (работает по ОКСу) моя АТС формирует IAM без номера "А", а отдаёт его только после запроса АМТС? Уже всю голову сломал. Если в настройках транкгруппы ставлю запрашивать АОН, то процесс обмена: занятие канала, передача мне информации "B", посылка туда 500гц, тишина и потом соединение рассыпается по таймауту... Пробовал и через дополнительную сигнализацию AUSSIG, всё-равно сразу не отдаёт. Игрался полями в настройке транкгруппы отвечающие за запрос и передачу информации о вызывающем аб., ноль эмоций... Хотя если мне нужно что-то сделать с номером аб. "А" через PFXPRO, т.е. изменение номера "А", то IAM формируется с caller и called.
Поделиться82010-07-01 20:36:39
rus, попробуй на входящей ТГ поставить:
soft para of service CTRL = Request CLI when CLD complete
Поделиться92010-07-03 17:35:54
obe написал(а):
rus, попробуй на входящей ТГ поставить:soft para of service CTRL = Request CLI when CLD complete
Ранее пробовал не помогло...
В общем изначально задача была такая: необходимо было выполнить преобразование номера с закрытого типа нумерации на открытую, проще говоря абонент набрал три циферки, а я на АТС делаю подмену и отдаю на АМТС. Всё работало хорошо, только вот IAM уходил без информации о аб. "А". Тогда я и обратил внимание что она то у меня и не запрашивается с этих оконечек. В итоге пока сделал так, прописал всё-таки AUSSIG и уже через него запрашиваю инфу, только ранее моя ошибка состояла в том, что я отлавливал её через тот префикс, который приходил с оконечки, но не учитывал что после реанализа в PFXPRO он уже подменён, исправил префикс на подменённый и теперь всё работает как надо 
. Понимаю что не совсем правильно, но по другому никак не получается...
Поделиться102010-07-07 09:22:49
По моему все просто:
MOD PRATG: TG=***, NOCLR=NO;
Поделиться112010-08-06 14:05:03
подниму тему, проблема та же:
отдаем клиенту поток PRA с 7-значной нумерацией, а клиент ставит на своей станции переадрисацию и в итоге в сеть летят совершенно левые номера, как их закрыть и как составить таблицу разрешенных АОНов?
Отредактировано Pogrem (2010-08-06 14:05:34)
Поделиться122010-08-06 17:14:02
- Проффи
- Зарегистрирован: 2007-11-01
- Приглашений: 0
- Сообщений: 166
- Уважение: [+2/-0]
- Позитив: [+1/-0]
- Провел на форуме:
1 день 10 часов - Последний визит:
2017-03-09 16:30:14
Присоединяюсь.
Есть проблема.
Правильный номер - высвечивается правильно, коннект.
Неправильный - высвечивается пилот, коннект.
А нужно неправильный отбить.
По переадресации вообще всегда вставляется пилот.
По TG установлено
Default connect = FALSE
Connecting without or with invalid caller number = FALSE
Need black and white destination code analysis = TRUE
По линку
Network check flag
TRUE
Ничего не помогает 
Отредактировано Sasha (2010-08-06 17:55:18)
Поделиться132011-08-10 16:53:19
Sasha написал(а):
Need black and white destination code analysis = TRUE
где вообще этот список белых и темных искать кто-нибудь знает?)
Поделиться142015-10-23 14:00:39
Кто решил данную проблему некорректные А номера PRA
Поделиться152015-12-08 09:00:33
- Проффи
- Откуда: Казахстан, Караганда
- Зарегистрирован: 2014-02-13
- Приглашений: 0
- Сообщений: 61
- Уважение: [+2/-0]
- Позитив: [+0/-0]
- Пол: Мужской
- Возраст: 40 [1983-10-05]
- Провел на форуме:
17 часов 41 минуту - Последний визит:
2016-08-05 09:30:28
Можно ввести дискриминационную группу. Чтоб вызова проходили ровно с тем АОН который прописан в условиях
У нас так (в листинг выведен только 1 номер, а так там диапазон номеров)
%%LST CLRDSG: DSP=2, SCLI=K'7212972000, ECLI=K'7212972000, ISTKIF=TRUE;%%
RETCODE = 0 Operation succeeded
Caller discrimination table
---------------------------
Discrimination group = 2
Caller number = 7212972000
Address nature = All address nature
Function code = Caller number discrimination
Minimum length = 10
Maximum length = 10
Call source code change = 65535
Charging source code change = 255
Barring group change = 65535
Caller category change = No change
Caller priority = No change
Caller number change index = 65535
Nature of address change = No change
Number complete flag change = No change
Presentation ID change = No change
Number plan ID change = No change
Toll call password = eeee
Peru new subscriber = FALSE
User State = Peru unlimited user
User Sub State = Peru user normal
Trunkgroup
----------
Discrimination group Trunk group number Caller category
2 2 254
--- END
Еще думаю как вариант пойдет запрет на соединение при отсутствии номера вызывающего:
MOD PRATG: TG=5, NOCLR=NO;
Отредактировано Нурлан (2015-12-08 09:07:21)
Страница: 1