Всем доброго времяни суток !
Подскажите в данном вопросе.
Суть:
Есть на рабочем месте телефон OS40HFA.
Запрограмирован на определённую клавишу, нормально работающая функция FWD, перевод на мой сотовый (удобно :) как бы я и на рабочем месте :) , да и вообще, приходится бегать... ).
НО. Если мне звонят на рабочий - вызов приходит естественно на сотовый, АОН сотового определяет номер как моего рабочего (понимаю, что это наверное правильно).
Вопрос:
Реально ли, что бы определялся номер именно _звонящего_ абонента ???
И что тогда нужно "посмотреть" в станции...
Заранее спасибо.
Пока.
Олег.
З.Ы. НР4000 версия 4.0

Доброго дня!
Этот вопрос уже неоднократно поднимался на форуме - смотри предыдущие темы.
Если вопрос состоит в том чтоб изменить то правило, которое работает на станции - видится тот номер с которого выполнена переадресация - только для тебя, то придется огорчить - правило одно для всех.

Есть еще нюанс, у нас например , ни один провайдер такой звонок (с чужим CLIP) не пропустит, или отбьют, или сами пилот подставят.

Доброго дня!
Этот вопрос уже неоднократно поднимался на форуме - смотри предыдущие темы.

Спасибо, дорогой.
Млин.... Больно... Если несложжно :). Отпавь... на конкретную тему...

Если переадресация будет через поток Е1, то можно сделать чтобы ты на сотовом видел или свой рабочий номер или номер звонящего. Настраивается в параметрах транка.
НО! Как уже написали выше, провайдер вас либо "отобьет", либо оповестит, что от вас идет некорректный АОН и потребует исправить, а так же сообщить на какой аон поменять. Учтите тот момент, что ОАН влияет на билинг, и кому выставлять счет за исходящий вызов с вашей АТС с "чужим" аоном? А если переадресация на междугородний номер? С вашего направления должны "уходить" тоьлко АОНы выделенного вам диапазона. В противном случае могут вам совсем закрыть выход в город.
Дабы не навлеч на себя проблем не советую это пробовать, т.к. фокус не пройдет 100%!
Самому пришлось с этим столкнуться N-ное количество лет назад и тоже по-незнанию. Сейчас решаю другим способом, благо call-центр стоит и переадресация через него идет. При переадресации в догонку летит СМС-ка с номером, т.к. бывает необходимым видеть номер.

Для решения поставленной в топике задачи нужно, чтобы "абоненту C" пришли правильные дополнительные поля в сигнализации ОКС7. Тогда АБОНЕНТСКИЙ АОН для "абонента C" извлекается из дополнительного поля и "абонент C" увидит номер A (вызывающего), а не номер B (переадресующего).
Но для правильной ТАРИФИКАЦИИ переадресованного вызова обязательно должен быть использован номер B.

Но для УПАТС, через сигнализацию EDSS1 выдать расширенную инфу практичеси невозможно (с чужих слов некоторые УПАТС с EDSS это все же умеют).

Мало вероятно, что УПАТС по Окс7 подключена ибо они подключаются как абонентские установки по EDSS1.

Мало вероятно, что УПАТС по Окс7 подключена ибо они подключаются как абонентские установки по EDSS1.
Дык, ТС хочет на СОТОВОМ смотреть "Номер А". Сотовый оператор всяко работает по ОКС и в принципе способен использовать разные АОН-ы для тарификации и отображения абоненту. Особенность в том, некоторые УПАТС якобы способны выдать расширенный EDSS (со слов техперсонала бывшего Связьинформа, кто-то из субабонентов выдавал сложную структуру переадресации на EDSS1), но как правило нет.

Дык, ТС хочет на СОТОВОМ смотреть "Номер А". Сотовый оператор всяко работает по ОКС и в принципе способен использовать разные АОН-ы для тарификации и отображения абоненту. Особенность в том, некоторые УПАТС якобы способны выдать расширенный EDSS (со слов техперсонала бывшего Связьинформа, кто-то из субабонентов выдавал сложную структуру переадресации на EDSS1), но как правило нет.

Не путайте подключение сотового оператора к ТфОП и абонента.

Мало вероятно, что УПАТС по Окс7 подключена
Извините, что встреваю... Именно по ОКС7 подключены.
Пока.
Олег.

Извините, что встреваю... Именно по ОКС7 подключены.
Пока.
Олег.
Дык, как и я, наверное, через конвертер М-200. Конвертер сам данные в сигнализации не порождает, только преобразует их от первичной УПАТС. Т.е. проблема в УПАТС остается.
Ancle Fedor, попробуйте техподдержку конвертера попытать, интересно, что скажут. Извлекали они из какой-нибудь УПАТС переадресацию с номером А и с не поломанным биллингом?

для дяди федора
Посмотрите
http://bbs.radiolink.ru/forum/showthread.php?t=54203&highlight=%C0%CE%CD
или
http://bbs.radiolink.ru/forum/showthread.php?t=55791&highlight=%C0%CE%CD
да зайдите в поиск и задайте критерий поиска АОН - счастья будет не мерено.
Для общего обсуждения
мужики как можно что-то требовать от поддержки М-200 каких-то доп возможностей если до него по протоколу EDSS в принципе не может дойти информация об дополнительных переадресациях... Это ограничено возможностями самого протокола. Кто сможет передать по EDSS или QSIG два и более адреса переадресации - тот решит этот вопрос. Я думаю так и надо отвечать на данный вопрос.

2 ДобрыйЙорик, lq74, Baskett, Dymk
Ребята, спасибо за консультации !
Попробую все "варианты" ...
Ещё раз спасибо !
Пока.
Олег.
ЗЫ. 2 lq74 Да, через М-200

Уважаемые Коллеги!
Столкнулся с такой проблемой. HP4000 v6, имеется два подключения - через местного оператора по Е1 и оператора МТТ по SIP. Местному оператору шлю АОН в формате 88452хххххх, а МТТ хочет только в формате 78452хххххх. При обычных звонках проблем нет, все разруливается в KNMAT, а вот если у абонента установлен FWD на федеральный мобильный, то через SIP звонок не проходит, т.к. при переадресации формируется АОН 88452..., а надо 78452... . Если переадресацию направить через местного оператора, то все ОК. Вопросы - откуда берется АОН при переадресации, почему не работает нужная строка в KNMAT? Подозреваю, что нужно что-то изменить в COT или KNMAT. Натолкните на путь истинный, пожалуйста. С любимым тут на форуме параметром DSDL:rolleyes: не пркатывает по той же причине.

В догонку:

ADD-TDCSU:NEW ,1-03-079-0,112,112,5,0,112,1,1,"IP-TRUNK ",0
,ECMAV2,8,,NONE,,,,GDTR,Y,TIE,NONE,N,0,,,,,, ,31,MANY,520,2,1,1,EMPTY,112,3,N,
,,,,SIDEA,16,8,1,10,,EC&G711,"TEST01",151,CIR,Y,TRADITIO,HG3550IP,
1&&20,Y,1,11,0,0,0,0,0,N;

ADD-COT: 112,ANS&CEBC&CBBN&CBFN&BSHT&BLOC&LWNC&NLCR& TSCS&ICZL&DFNN&NLRD&NOFT&NTON;
CHANGE-COT:112,COTADD,,INDEP;
Для местного оператора:
CHA-KNMAT: ISDN,0,520,,105,,A,ALL,88452111111,;
CHA-KNMAT: UNKNOWN,0,520,,105,,A,ALL,88452111111,;
Для МТТ:
CHA-KNMAT: ISDN,0,520,,305,,A,ALL,78452111111,;
CHA-KNMAT: UNKNOWN,0,520,,305,,A,ALL,78452111111,;

Для начала хотел добиться отправлять просто правильный "пилотный" АОН.

2 Andvn
я думаю что не там ищете. Вы посмотрите маршрутизацию на предмет каким образом абоненты могут звонить Я так понимаю что набирают один и тот же префикс но ограничение идет по набираемым индексам после префикса - на разных операторов. Так если оно так и обстоит, то все просто - кто имеет основным местного оператора, форвардинг будет на местного даже при ограничении наборных индексов (префикс то один). Дальше все понятно.
Если у направлений (операторов) разные префиксы выхода - тогда я не помогу, поскольку представленные данные считаю правильными. DSDL вообще непричем.

ДобрыйЙорик
Может я не правильно описал суть проблемы, но сейчас уже после более плотных "ковыряний" могу дополнить. Все абоненты выходят, например, на федеральные номера мобильных операторов по одному маршруту 0-8-9-ххххххххх через одного оператора по SIP. При прямых звонках все нормально, а вот если установлена переадресация с внутреннего абонента на мобильный, то абонент, установивший переадресацию видит на своем мобильнике номер звонящего, т.е. АОН звонящего пролетает транзитом через НР4000 без изменений. Оператору SIP это не принципиально и он в отличии от местных оператов ТфОП этот вызов пропускает. Тут многие были бы счастливы иметь такое у себя, но считаю это не правильным. Хотелось бы сделать по аналогии с протоколом EDSS1 при помощи параметра DSDL, но с ECMAV2 это не работает. Как сделать, чтоб к оператору улетал АОН абонента, установившего FWD? Ну или заставить такой вызов обрабатываться KNMAT?

2 Andvn
Тогда так
На v4 для HiPath4000 на протоколах QSIG(ECMA) подстановка или удаление DSDL рояля не играет, вот если поставите PROT=EDSS1 и подольете патч (так было на версии 4), то DSDL начинает работать. Про версию 6 точно сказать не могу но терзают смутные сомнения, что принципиально не поменялись условия...
Все что могу, Пусть поправят кто больше знает по версии 6

При переадресации на сип транк HP всегда будет транслировать номер вызывающего абонента. Была такая необходимость транслировать номер телефона, на котором стоит переадресация, но и сами не смогли сделать и сам! Сименс сказал, что по-другому не получиться, т.к. для HP сип-транк рассматривается как внутренний, а туда только транзит аона система гонит. Понимаю, что прогресс не стоит на месте, может быть что и подправили, подкрутили, но на нашей 6-й версии пока так.

ДобрыйЙорик
Baskett
У меня тоже вера на благополучный исход покидает меня. Еще пару деньков помучаюсь и забью. Только тут попутно проблема нарисовалась в том, что нельзя установить FWD на федеральную мобилу, так как АОН от позвонившего прилетает к оператору СИП с "8" и они отбивают. Останется только абонентам запретить пользоваться внешним FWD.
Спасибо за ответы.

Для Andvn
быть может идея не очень, но подави " 8" и подставь "+7 " ну или что тама нада. Воспользоваться форматонезависимым АОН.
С Уважением

Volanchik
не скромный вопрос - как это сделать для транзита на СИП?

2 Andvn
Тогда так
На v4 для HiPath4000 на протоколах QSIG(ECMA) подстановка или удаление DSDL рояля не играет, вот если поставите PROT=EDSS1 и подольете патч (так было на версии 4), то DSDL начинает работать. Про версию 6 точно сказать не могу но терзают смутные сомнения, что принципиально не поменялись условия...
Все что могу, Пусть поправят кто больше знает по версии 6
Если не трудно, подскажите, о каком патче идет речь?
У меня HP4k v4.2.50, но параметр DSDL в COT не работает, т.е. вызов не закрывается АОН-ом абонента, установившего FWD!

Можно попробовать через PUBNUM и KNPRE.
в абоненте пропиши номер, а в knpre по одному направлению 8 а по другому 7 с параметром выход.

Можно попробовать через PUBNUM и KNPRE.
в абоненте пропиши номер, а в knpre по одному направлению 8 а по другому 7 с параметром выход.

Не не прокатит попробовал.

В догонку:

ADD-TDCSU:NEW ,1-03-079-0,112,112,5,0,112,1,1,"IP-TRUNK ",0
,ECMAV2,8,,NONE,,,,GDTR,Y,TIE,NONE,N,0,,,,,, ,31,MANY,520,2,1,1,EMPTY,112,3,N,
,,,,SIDEA,16,8,1,10,,EC&G711,"TEST01",151,CIR,Y,TRADITIO,HG3550IP,
1&&20,Y,1,11,0,0,0,0,0,N;

ADD-COT: 112,ANS&CEBC&CBBN&CBFN&BSHT&BLOC&LWNC&NLCR& TSCS&ICZL&DFNN&NLRD&NOFT&NTON;
CHANGE-COT:112,COTADD,,INDEP;
Для местного оператора:
CHA-KNMAT: ISDN,0,520,,105,,A,ALL,88452111111,;
CHA-KNMAT: UNKNOWN,0,520,,105,,A,ALL,88452111111,;
Для МТТ:
CHA-KNMAT: ISDN,0,520,,305,,A,ALL,78452111111,;
CHA-KNMAT: UNKNOWN,0,520,,305,,A,ALL,78452111111,;

Для начала хотел добиться отправлять просто правильный "пилотный" АОН.

А если попробовать прописать аон для не 520,105 А 105, 305 и там прописать аон с 7.

vorug
о чем речь?

CHA-KNMAT: ISDN,0,305,,105,,A,ALL,78452111111,;
CHA-KNMAT: UNKNOWN,0,305,,105,,A,ALL,78452111111,;
или наоборот 105,305

vorug
это все ерунда, проблема в том, что переадресованный звонок нельзя модифицировать на SIP-trunk. Надеюсь, что пока нельзя...

to Peter hi
Надо сделать так
DEACT-PATCH: PATCH,PS20Q38;

to Peter hi
Надо сделать так
DEACT-PATCH: PATCH,PS20Q38;
Сработало, благодарствую! :)



P.S.
Сработало, но... не совсем так, как хотелось бы. DPLN-ы мешают. :(

Абонент А (PABNUM=4951111111) вызывает абонента В (PABNUM=4952222222), у которого установлена безусловная перадресация на внешнего абонента С. Если абоненты A и B в одном DPLN-е, то на аппарате абонента С показывается АОН=4952222222. Если абоненты A и B в разных DPLN-ах, то АОН=4951111111.

Может кто подскажет, а существует ли возможность исправить эту зависимость от DPLN-а вызывающего абонента А?:confused:

P.P.S.
И еще заметил один баг, связанный с DPLN-ами, если отключить патч PS20Q38.
Дополнительно к примеру выше, абонент B находится в hunt-группе(EXECCFW=Y).
Если абоненты A и B находятся в разный DPLN-ах, то при вызове абонента B, у которого установлена переадресация на внешнего абонента С, абонент A получит сигнал "fast busy". Причем, судя по трейсу, внешний канал связи даже не занимается.
Если A и B находятся в одном DPLN-е, то такой проблемы не наблюдаю.
Так что, если отключать патч PS20Q38, то надо всех абонентов/транки держать в одном DPLN-е, а LCR разруливать только метками. :(
По-прежнему, вопрос выше "о зависимости от DPLN-ов" остается в силе...

to Peter_hi
Предлагаю чтоб ничего не мешало по жизни, не обсуждать сложные конструкции маршрутизации станций в объеме форума (вопрос-ответ), а связаться напрямую с серьезными спецами они полагаю все "разложат по полочкам" почему и как происходит. Поверьте все станет ясно и на свои места.

Еще дополню, если абоненты в разных DPLN-нах, причем с привязанными своими транками то такой вопрос(с переадресациями) практически не решается на прямую, а только через пилотные номера, да и то с привлечением провайдерской стороны...Так, что ищите спецов на месте..или в Сименсе..

Сименс сказал, что по-другому не получиться, т.к. для HP сип-транк рассматривается как внутренний, а туда только транзит аона система гонит.

Интересно, это относится ко всему семейству HP? Мне бы на 3800 это провернуть

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

ДобрыйЙорик
OLD_Operator
Благодарю за очень полезную для меня консультацию! :)

Я привык, что DPLN меняется только от территориальной принадлежности, чтобы набирая 9, выходили через свои, местные линии на транки. А доступы разруливаю только LCOSV'ами.