Все инженеры СC08 - объединяйтесь !

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Все инженеры СC08 - объединяйтесь ! » Работаем с Huawei » Запрет вызовов без номера А


Запрет вызовов без номера А

Сообщений 1 страница 15 из 15

1

Привет всем - кто нибудь реализовывал такое, если приходит вызов без номера А его нужно отклонять. Как можно реализовать данную задачу? Мысли есть - но нехочется экперементировать на живых абонентах (вдруг что не так сделаю).

0

2

У меня есть похожая проблема: УПАТС присоединена к сишке по EDSS1. Получается такая ситуация-УПАТС может создавать у себя любые "кривые" А номера не из выделенного сегмента номеров, а сишка устанавливает соединение по таким номерам. Соответственно, они идут в отсев по биллингу. Вопрос в следующем: можем ли мы делать преданализ, чтобы отклонять такие вызова? Техподдержка предлагает прописать все номера УПАТС у себя через ADD PRA и на линке поставить флаг "netwqork check flag"=YES. Нас такой вариант не устраивает из-за большого количества абонентов и направлений. Может быть кто-нибудь решил такую проблему?

0

3

Та же беда :-)

0

4

Коллеги, я что не пойму. У моих коллег была подобная ситуация. Местная сельская АТС не слала А-номер. Это для нашей станции был входящий. На станции ничего не сделали с билиндерами договорились, что они буду подставлять unknown. А по Вашей схеме дедушка с маленьго села не сможет дозвониться, а это есть вообще не правильно. Или я чего-то не понял...?

0

5

Да нет не в дедушке дело. Ситуация такая: Есть городская АТС (сишка), к нему по PRA подцеплена УПАТС, которая шлет кривые номера А. В свою очередь, абоненты УПАТС выходят через сишку на телефонную сеть, посему в биллинге вызова получаются исходящие, соответственно кривые вызова падают в отсев. Приходится разбираться с какого направления эти вызова пришли, т.к. таких присоединенных УПАТС у нас более 20-ти.

0

6

Не ужели никто не делал такое? Суть просто в том, что есть недобросовестные абоненты которые шлют левые номера или вообще вызова без номера. В таком случае тарификация ложится на пилотный номер. Но нас не совсем это устраивает.

0

7

А кто что может подсказать по такой проблемке: есть оконечки M-200 (на 320 платформе) и координатки АТСК с АОН на крокусах работают по CAS, так вот при звонках с них на вышестоящую АМТС (работает по ОКСу) моя АТС формирует IAM без номера "А", а отдаёт его только после запроса АМТС? Уже всю голову сломал. Если в настройках транкгруппы ставлю запрашивать АОН, то процесс обмена: занятие канала, передача мне информации "B", посылка туда 500гц, тишина и потом соединение рассыпается по таймауту... Пробовал и через дополнительную сигнализацию AUSSIG, всё-равно сразу не отдаёт. Игрался полями в настройке транкгруппы отвечающие за запрос и передачу информации о вызывающем аб., ноль эмоций... Хотя если мне нужно что-то сделать с номером аб. "А" через PFXPRO, т.е. изменение номера "А", то IAM формируется с caller и called.

0

8

rus, попробуй на входящей ТГ поставить:
soft para of service CTRL = Request CLI when CLD complete

0

9

obe написал(а):

rus, попробуй на входящей ТГ поставить:soft para of service CTRL = Request CLI when CLD complete

Ранее пробовал не помогло...
В общем изначально задача была такая: необходимо было выполнить преобразование номера с закрытого типа нумерации на открытую, проще говоря абонент набрал три циферки, а я на АТС делаю подмену и отдаю на АМТС. Всё работало хорошо, только вот IAM уходил без информации о аб. "А". Тогда я и обратил внимание что она то у меня и не запрашивается с этих оконечек. В итоге пока сделал так, прописал всё-таки AUSSIG и уже через него запрашиваю инфу, только ранее моя ошибка состояла в том, что я отлавливал её через тот префикс, который приходил с оконечки, но не учитывал что после реанализа в PFXPRO он уже подменён, исправил префикс на подменённый и теперь всё работает как надо :flirt:. Понимаю что не совсем правильно, но по другому никак не получается...

0

10

По моему все просто:

MOD PRATG: TG=***, NOCLR=NO;

0

11

подниму тему, проблема та же:
отдаем клиенту поток PRA с 7-значной нумерацией, а клиент ставит на своей станции переадрисацию и в итоге в сеть летят совершенно левые номера, как их закрыть и как составить таблицу разрешенных АОНов?

Отредактировано Pogrem (2010-08-06 14:05:34)

0

12

Присоединяюсь.
Есть проблема.
Правильный номер  - высвечивается правильно, коннект.
Неправильный - высвечивается пилот, коннект.
А нужно неправильный отбить.
По переадресации вообще всегда вставляется пилот.

По 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)

0

13

Sasha написал(а):

Need black and white destination code analysis  =  TRUE

где вообще этот список белых и темных искать кто-нибудь знает?)

0

14

Кто решил данную проблему некорректные А номера  PRA

0

15

Можно ввести дискриминационную группу. Чтоб вызова проходили ровно с тем АОН который прописан в условиях
У нас так (в листинг выведен только 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)

0


Вы здесь » Все инженеры СC08 - объединяйтесь ! » Работаем с Huawei » Запрет вызовов без номера А


создать свой форум бесплатно