Все мы знаем, что в телефонных сетях ссуществует услуга анти-АОН (блокировка отображения вашего CALLERID). Многие знают, что присутствует также услуга анти-анти-аон (так называемая блокировка блокировки).

Но вот какой вопрос - никто никогда не пытался решить вопрос вскрытия блокированных CALLERID на базе ASTERISK?
Недавно озаботился этой проблемой и понял, что никак не могу найти её решения. Где уже только не полазил в *, пока всё только сплошные обломы. Поможите, люди добрые, кто чем может!!!

Это возможно не всегда. Если астериск подключен к оператору связи как оконечное устройство, то оператор при передаче вызова скроет CallerID полностью.

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

Такое возможно только при стыке с оператором по SS7 и то только если он правильно скрывает "аон" звонящего (то бишь просто выставляет CLIR).

Тут ведь вот какая тема. Если уж уходить в эти технические дебри, то могу сказать следующее: callerid не блокируется в принципе! Он передаётся всегда (иначе каким образом вести тарификацию абонента, работать с СОРМ и т.д.). Просто при включении услуги так называемого антиаон'а происходит блокировка "приглашения" на отображение этого колерайди.

В моём случае астериск цепляется несколькими E1 к ТФоП. Так что получается такая ситуация:

Приходит, значит, звонок ко мне на астериск с номера, где подключен антиаон; мой астериск просит коммутатор ТФоП-оператора "знаешь ли ты, добрый друг, коллерайди этого вызова?", коммутатор ему отвечает "знаю, конечно!", на что мой астериск реагирует следующим вопросом "а не соизволишь ли ты мне его показать?", и вот тут следует ответ "нет, не могу, мне злой бабайка не велел!".

И вот тут как бы мне теперь заставить мой астериск наехать на коммутатор фразой "я сам тот ещё бабай! если не даш коллерайди, я тебя наругаю сильно-много!!!", чтобы коммутатор испугался и дал мне этот коллерайди.

В классической телефонии это решается на уровне работы протоколов сигнализации (насколько я помню). В принципе, того же самого должно быть можно добиться и на уровне SIP, но вот КАК - это для меня пока загадка...

Вопрос остаётся открытым, не сталкивался ли кто-либо с этой проблемой, и, самое главное, нет ли у кого её решения?!

У E1 нет опции CLIR, а у ОКС7 есть. Если провайдер скрывает callerid у себя с помощью CLIR а затем отправляет вам в поток E1 то вместо номера А ты увидишь дырку от бублика. Если же вы оператор то вы обязаны иметь стык с другим оператором именно по ОКС7, а не по E1. А если вы не оператор а просто клиент то никто ничего не обязан вам передавать, т.к. в этом случае СОРМ-а у вас нет.

CLIR есть и в сипе. Я проверял работу CLIR в SIP на станции Siemens. Абоненту приходит именно дырка от бублика и нет способа представиться "бабаем".

http://forum.nag.ru/forum/index.php?showtopic=49964
"Подарю" замечательную находку в Cisco IOS SIP при шлюзовании в ISDN...
Если отправить INVITE с From: "Unknown" <sip:1234567@192.168.1.3> то получится пренеприятнейшая вещь.
В ISDN Setup А-номер "Calling Party" выедет с Presentation Indicator = Number not avaible due to internetworking. Причем сам номер "1234567" будет.
Проблема именно в части Display-name From-URI равный слову "Unknown", без разницы в больше/маленькие буквы.
Думаю понятно, что RFC3261 об этом "ни сном ни духом".
После долгих поисков, найден был источник "счастья" - Cisco PGW2200 (транзитный софт-свитч) так передает Presentation Indicator через SIP. А PI=Restricted соотв. как Display-name = "Annonymous".
На данный момент способа обойти этого средствами только Cisco IOS не найдено.. А юзеров с таким Display-name - увы хватает (во многих софтфонах по умолчанию).
Попалось на AS5450, подтверждено на AS5350XM. IOS 12.4 и 12.4T все серии. Есть подозрение, что IOS выпущенный до PGW2200 v9 (примерно 2000 год) этого глюка иметь не будет, но будет очень старый..
Простейший workaround - принудительное выставление PI = Restricted на dial-peer'e (12.4T позволяет), хоть остальные станции не будут ругаться на сочетание нормальный номер с PI=Unvailable.

"IgorG", спасибо за жизненный опыт, учту.

"ZloMurz", если не знаете терминологию, то не надо ей оперировать. Так, к слову просто, чтобы на будущее вы так больше не лажались: Е1 - это тип интерфейса (подразделяется на два вида - framed, иногда обозначают как G.704, и unframed - G.703). А ОКС7 - это один из множества протоколов сигнализации. И если уж вести разговор об опциях, то могу вас заверить, что в каждом конкретно взятом потоке E1 есть ровно только опций, сколько будет туда впихано соответствующими сигнальными протоколами. Это первое.

Второе. Вытекает из первого. Я как оператор ОБЯЗАН стыковаться с остальными именно потоками Е1! А вот уж какой там тип сигнализации будет: PRI, ОКС7 - это никого не волнует совершенно (ну вот ни разу не волнует, хоть ты тресни). Можно хоть R2 сигнализацию сделать, лишь бы обоюдне согласие сторон на это было.

All_is_not_what_it_seems, на данную ветку я тоже натыкался. Но у меня немного другая ситуация.

Вопрос остаётся открытым. Прошу помощи!!!