Коллеги приветствую!

OXE 7.0 выход в город через транк PRA.

В общем внимание вопрос::)

Абонент А - городской абонент.
Абонент Б - внутренний абонент, с заведенной переадресацией по не ответу на сотовый.

Итак звонит абонент А, абоненту Б у него срабатывает переадресация на сотовый.
Реально в транковой группе ПРА получается такой звонок:
Номер абонета А (Calling party) -городской номер
Номер абонента Б (Called party) -номер сотового.

Т.е. на лицо чистый транзит. Это не нравится вышестоящему оператору назовем это так.

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

В сетапе PRA должно быть я так понимаю поле с номером изначально кому звонили и некий редирект намбер уже.

Вопрос: как можно настроить отображение этого поля., что бы можно было идентифицировать кому всё таки звонили в биллиннге.

Поднял сейчас Q.931 и нашел информационный элемент в сетапе отвечающий за это. Вот именно его как поднять?

4.6.7 Redirecting number
The purpose of the Redirecting number information element is to identify the number from which
call diversion or transfer was invoked.
The Redirecting number information element is coded as shown in Figure 4-43 and Table 4-32.

Коллеги может я неправильно выразил свою мысль? Есть соображения по этому вопросу?

Станция может принимать и использовать Redirecting number, но сама его не формирует (насколько я знаю).

Так может быть это не редирект намбер поле? Это я как бы предположил...

Т.е. по логике именно oxe должна делать это.

Transfer же стоит на OXE и именно алкатель должен в сетапе оттадавать реальный номер с которого переадресуется..

ОХЕ и отдает реальный номер (поле Calling number) абонента заказавшего переадресацию. Если в NPD for external forwarding поставить не "-1" то для внутренних абонентов будет отдаваться номер звонящего абонента. А вот при внешнем звонке, ушедшем по переадресации - отдается внутренний номер (если отдать номер внешнего абонента - город откажет в звонке (хотя в некоторых странах это разрешено). Формально при таких звонках используется дополнительное поле redirecting number (зачастую можно посмотреть, если сделать переадресацию с сотового на номер в станции).

Я понимаю про тему NPD for external forwarding.
Просто ну это неудобно крайне когда человек реально не видет кто ему звонит при переадресации. Для этого же и придумали такую технологию что бы на АОНах можно реально было видеть кто кому звонит , но в тоже время обсчет вести по полю редирект.К примеру EWSD в таких звонках разбирает что звонил именно тот человек который в редиректе стоит и деньги образно говоря ему защитывает если грубо так выразиться.



Почему ж формально?
почему охе не может также формировать redirecting number как это умеют многие станции цэж стандарт Q931?

А многие - это какие?

softX3000, EWSD, AXE-10, да в принципе раз у него заявлено q931 значит он должен отвечать этому стандарту тем более настройка NPD for external forwarding присутствует, т.е. как бы проброс реально того кто звонит, но в этом случае должнор все равно информация оставаться с какого телефона была инициирована данный вид звонка для того что бы его "город" тире встречная станция могла правильно идентифицировать у себя в биллинге, а не так получается чистый транцит номер а и номер б не номера OXE. и информации этой нет.

настроишь чтоб номер от А выталкивался в наружу а прова стоит такая фишка - если номер выходит за пределы диапозона выделенных номеров то сразу идет пилот номер, да и зачем прову лишние разбирательства когда когда он предоставит вам траффик а там окажутся те самые номера которые от которых вы будите по началу отнекиваться и доказывать что ТАКОЕ с наша атс не могла сделать

логично истолковываю?!

В этом случае не видно кто звонит!!! дА видно что звонит некий общий номер, но невидно изначально номер А. Да и зачем все иэти сложности с пилот намбер у прова (хотя там такое настроено), когда это всё включается отключается одной кнопочкой NPD for external forwarding -1.

Вопрос как раз в том что бы настроить отображение реально А номера, но в тоже время с сохранением номера от куда идёт звонок.т.е. поле редиректинг набер.

К примеру:


звонит
А номер 277156
на Б номер (алкатель) 450045

На Б номере стоит форвардинг на сотовый 9147778899

В сетапе идет
А номер 277156
Б номер 9147778899
редиректинг намбер 450045.

Интересные настройки нашел в станции, но они непривели к нужному результату, может что то еще надо крутануть?

Итак всё там же system/other system parameters/external signaling: redirecting number used

Там же есть масса тем с темой редиректинга.:)

Есть идеи?:)

звонит
А номер 277156
на Б номер (алкатель) 450045

На Б номере стоит форвардинг на сотовый 9147778899

В сетапе идет
А номер 277156
Б номер 9147778899
редиректинг намбер 450045
Во первых - город пошлет вас нафиг (или подставит базовый номер) когда вы отправите calling number 277156 (это номер не принадлежит диапазону номеров закрепленных за данным направлением).
Второе - чтоб сформировать номер 450045 - NPD for ext. forwarding должно быть "-1", а тогда вы не получите желаемый номер А.
Redirecting number used - используется когда вы из города получаете setup с calling number и redirecting number - вы задаете что хотите видеть на внутреннем аппарате станции.
Как я понимаю с точки зрения работы PRA в городской станции типа S12 - это абонентский вынос, не предполагающий вызов от номеров не в плане нумерации данного выноса. Например S-12 не может передать в PRA ничего кроме диапазона закрепленных номеров (4500ХХ) и ничего больше. Такие вещи бегают наверное при подключении оператор-оператор по ОКС-7.

ДА собственно приводя примеры сEWSD SS3000 и прочим я имел ввиду ОКС7.

Ну оглянув беглым взглядом Q931 я подумал там тоже должен быть реализован механизм данный.

на одном объекте к ОХЕ подходят pra от двух провов (на тот случай если один поток отвалится), на одном из pra диапозон номеров можно выдать хоть с зимбабве и без припятственно будут бегать эти номера но лишь с одной оговоркой - притензии потом не принимаются (просили сделать так у обоих провов и один только согласился)

давно поднималась тема по поводу OKC7 и оказалось что это гиблое дело, т.к. ОКС7 на 4400 и OXE не работает в полнофункциональном режиме

так что остается одно из двух зол сказать начальству что так не получится либо с провом договорится (на 99% уверен что он на это не пойдет) :)))



Редактировано 1 раз. Последний раз 03.10.2007 15:40 пользователем conf.

для ситуации с внешней переадресацией - начиная с релиза не помню, 7 или 7.1 - есть в транковой группе галка на call diversion (правда провайдер должен обеспечивать ее. В этом случае не будут заниматься В каналы в потоках. Может чего и с номерами произойдет.

Столкнулись с подобной проблемой.
Абонент А (внешний) звонит на абонента В (внутренний). На В активирована переадресация на абонента С (внешний)
Оператор требует при исходящем звонке отдавать еще сообщение facility с указанием позвонившего извне абонента А, ссылаясь на рекомендацию ITU-T Q.932 п.7.1.1 Раньше просто требовали соответствия информационных элементов как для обычных вызовов, что успешно и делали.
Оператор пургу гонит или я что-то не понимаю?
Кста.
Где можно ознакомиться с ITU-T Q.932?

Может быть здесь: http://www.itu.int/rec/T-REC-Q.932-199805-I/e

Я как раз изучал этот вопрос и хотел написать что это должно передаваться в мсообщениях facility. Согласно Q.952 я так понел именно в этом сообщении должна передоваться информация о изначально звонившем абоненте.

Интерсист помогайте как организовать это сообщение от Алкателя?

могу выслать кому треба Q.932, 952

Есть у кого еще какие идеи?

На самом деле в документации описывается это ISDN T0 Detailed Discrip - Call Diversion

там описано что можно при переадресациях не задействовать б канал норвый, именно это помоему и есть данная фича.

Я попробывал выставить нужные галки как описано в документации, но нечего не изменяется.

Все упирается в провайдере - на курсах по ОХО при объединении двух станций по QSIG эта фича работала, то есть при форварденге или трансфере B-каналы освобождались и соединение осуществлялось на "Головной" станции. Может именно в этом и проблема - вызов проходит минуя станцию клиента и как с него тогда брать деньги?