Форумы  ·  Войти  · 

Тема: GDK-162 source-номер при исх.вызове в потоке E1

04.06.07 19:28   biffant  (75/20.03.07)  

Добрый день, ув.специалисты!

Подскажите, каким образом заставить станцию GDK-162 отправлять в E1 (сигнализация Q931) при исходящем вызове идентификатор номера звонящего.

Насколько я понимаю, речь идет о заполнении поля Called party number сообщения SETUP потока в режиме Circut-mode.

Полистав доки, нашел ПГМ 52,53,78, а также LCR. Чтобы нормально работало последнее, необходимо перепрошить станцию, что готов делать только в крайнем случае.

[ #1 ]  04.06.07 20:14   harris  EXPERT  

Что-то Вы путаете... Нужно отсылать идентификатор номера абонента GDK????
Тогда Вам нужен не CallED Party Number, а CallING…
Все перечисленные Вами программы никакого отношения к формированию Calling Number не имеют.
См. программы:
ПГМ37/1
ПГМ08/2,3,6,8
ПГМ09
ПГМ23/4.
Попробуйте поискать по форуму.. Это уже неоднократно обсуждалось...

[ #2 ]  05.06.07 10:25   biffant  (75/20.03.07)  

1. Насколько я понял, Called/Calling Party Number меняются местами в направлениях u->n и n->u.

2. Я хочу не идентифицировать звонящего внутреннего абонента, а иметь возможность передать оборудованию оператора номер маршрута, по которому пойдет исходящий вызов. Дело в том что в потоке E1 проброшены 4 прямых номера, идущие в двух разных каналах вышестоящего провайдера. Я хочу иметь возможность запрограммировать на станции номера таймслотов, использующихся для одного канала при исходящих вызовов, и для другого.

[ #3 ]  05.06.07 10:49   Sergey70  EXPERT  

Линии разбить в разные исходящие группы и далее LCR(если кроме этого Е1,больше других линий нет ,то можно поробовать просто исходящими группами).
А какая версия ,что для LCR перешивать хотите?
А может пров по Вашему CLI пробрасывать на нужный маршрут?

[ #4 ]  05.06.07 12:59   harris  EXPERT  

2 biffant:
1. Вы неправильно это поняли...Это никак не связано с направлением вызова (u->n или u<-n).
2. Да уж, весьма путанно Вы задачу расписали...
Это решается разными способами и в большей степени - на стороне провайдера (в любом случае это д.б. согласованное решение)... Например, может быть провайдеру нужно присылать разные префиксы для разных направлений.

[ #5 ]  05.06.07 17:18   biffant  (75/20.03.07)  

Ещё почитал мат.часть, поискал по форуму...

В связи с невозможностью задать произвольный АОН у GDK-162, уточняем задачу:
Необходимо задать таймслотам E1 префиксы, которые будут передаваться при исходящем вызове в пакете Setup и по которым будет маршрутизироваться вызов.

Сейчас попробую сделать по рекомендации с форума, посредством ПГМ37/ПГМ09

2 harris:
1. Ок
2. Бесспорно решение будет согласованным, мне надо просто как-то дать понять циске прова по какому маршруту хочу звонить.

2 Sergey70: Версия 5.5Ek, уважаемый Harris в свое время сказал что в этой версии LCR некорректно работает с потоком в случае набора Enbloc.

[ #6 ]  05.06.07 17:54   harris  EXPERT  

1.ПГМ37 и ПГМ09 - это формирование вашего АОНа (Calling Number).
Я же имел в виду посылку разных префиксов перед номером Вызываемого абонента (Сalled Number) для вышестоящей АТС. Например, как сейчас маршрутизирует МГТС:
853 - на ММТ, 855- на РосТелеком (как-то так)...
А можно поделить поток на несколько транков. Каждый транк - другое направление...Но это нужно делать с двух концов.
2. Что значит задать произвольный АОН???? АОН привязан как к каналу (ПГМ37/1), так и к абоненту...
В GDK есть несколько вариантов АОНа:
- 1 глобальный номер для всех абонентов,
- номер внутр. абонента,
- префикс + номер абонента,
- Зональный код + префикс + номер абонента.
3. А при чем здесь Enloc??? Можно же использовать посылку Overlap’ом. Но в принципе, версию поменять - не проблема.
4. Честно говоря, я вообще не пойму - в чем суть вашей суеты. Пусть провайдер выдаст свои требования, что он должен получать от GDK для правильной маршрутизации вызовов.😠

[ #7 ]  05.06.07 18:22   biffant  (75/20.03.07)  

harris,
никакой суеты нет, это называется что-то делаем в первый раз, век живи век учись 😊

1. Все правильно, мы формируем маршрутизацию на основе переданных данных АОНа. По крайней мере когда сейчас начал играть с ПГМ37/09 - провайдер сказал что это то что ему надо для маршрутизации.

2. Вы писали в теме Berkyt’а о том что в GDK-162 лишь несколько жестко заданных вариантов передаваемых АОНу данных. Т.е. я не могу выделить группу абонентов, задать им один произвольный номер, выделить другу, задать другой и т.д.

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

===

На данный момент ситуация следующая - выделил для экспериментов один таймслот, указал в нем ПГМ37/1 девятую строку ПГМ09, в ней указал городской номер (7 цифр), пров цифры увидел но сказал присылать с 7495 в начале. Это уже 11 цифр и в ПГМ09 просто не влезет. Указал в ПГМ08/2 код 7495, и начал пробовать разные значения ПГМ08/6 - при типе 0(unknown) префикс не выдается, при типе 1(international) выдается префикс 827495, откуда берется 82 непонятно. При типе 2(national) станция возвращает 000

[ #8 ]  05.06.07 18:38   biffant  (75/20.03.07)  

Договорились с провайдером что префикс 7495 он добавляет самостоятельно, второй исходящий поток заработал, всем спасибо за помощь!

[ #9 ]  05.06.07 18:42   harris  EXPERT  

1.Ну, OK
2.Да, это верно. В таком варианте нельзя.
3.OK.
—————————————-
Вам нужен формат номера = International(ПГМ08/6). 7-ка - это код страны. Но судя по всему, у Вас остался код страны =82 (Корея). Т.е. нужно изменить код страны (ПГМ00). Но так просто его не удастся поменять (при смене инициализируется вся база данных - все настройки “слетят”!!!!!!). Либо нужно будет “обмануть” станцию, чтобы не программировать все с нуля.
А в поле “My Area Code” (ПГМ08/2)нужно прописать=495.

[ #10 ]  06.07.07 15:37   biffant  (75/20.03.07)  

История с нашим АОНом имеет продолжение :((

Сейчас пров говорит что оказывается он видит только 7-10% АОНов при исходящих вызовах, остальные вызовы идут с пустым calling number.

У нас все настроено так как я писал в этой теме.

Пожалуйста, подскажите, в чем может быть дело если станция действительно ничего не плюет в поток!

[ #11 ]  06.07.07 15:47   biffant  (75/20.03.07)  

Трассировка потока при исходящем вызове на мой мобильный (с сотового после трех гудков отправил сигнал “занято”):

3046 -:04 10, C0 01 16 (01)
3046 -:04 10, FC 0F D5 05 04 03 80 90 A3 18 03 A9 83 90 6C 02 01 80 (01)
3046 P:04 10, FC 06 D6 0D 18 03 A9 83 91 (03)

(здесь идет набор номера)

3057 P:04 10, FC 01 D1 02 (06)
3059 P:04 10, FC 01 D0 01 (06)
3067 P:04 10, FC 05 DE 45 08 02 82 91 (06)
3070 -:04 10, FC 05 DF 4D 08 02 80 90 (06)
3070 -:04 10, C1 01 16 (06)
3070 P:04 10, FC 01 E0 5A (0F)

[ #12 ]  06.07.07 16:55   Евген_й  EXPERT  

Какую первую цифру при внутренней номерации используете? Номер “А” отсутствует у каких внутренних номеров?

[ #13 ]  06.07.07 17:04   biffant  (75/20.03.07)  

Внутренние номера 100-ые и 200-ые, про номер “А” не понял.

Дело в том что я запросил у прова, при каких звонках станция отправляла АОН, и проверил эти вызовы по своим логам - никакой закономерности с внутренними абонентами и занимаемыми тайм-слотами не нашел.

Иными словами, абонент 131 дважды за день позвонил с АОНом, и трижды без АОН. То же можно сказать о таймслотах

[ #14 ]  06.07.07 18:56   biffant  (75/20.03.07)  

Так:
1. На потоке не DSS1 а QSIG, пров сказал что кто-то там был в отпуске и его заместитель что-то там изменил, потому и проблема с АОНом появилась.

2. После попытки переключения циски на DSS1, на потоковой плате станции загорелся LED5 (ошибка сверхцикловой синхронизации), при этом возврат обратно на QSIG ситуацию не меняет! На циске тоже генерятся какие-то ошибки. Рестарт железок, перетыкание кабеля, переключение свитчей на потоковой плате результата не дают :( Соответственно внешнии линии в потоке возвращают Queuing.

[ #15 ]  06.07.07 19:52   biffant  (75/20.03.07)  

Проблема решилась настройкой циски, она почему-то вдруг решила что слейв.

Когда подняли сигнализацию DSS1 (на циске это называется Net5), АОН заработал!

Komendant.pro
 ©1999-2024  Инженерная лаборатория "Комендантъ"