Добрый день! Есть АТС hipath 3800. Внешний мир подключен через E1. В настройках extensions выбраны номера CLIP для определенных внутренних номеров. В случае если это обычный номер (на конце есть аналоговый ТА), при звонке с этого номера callerid приходит верный (тот, что указан в настройках). Если это виртуальный номер (обычный номер с включенной переадресацией), то при звонке на него и дальнейшей переадресации номер приходит по умолчанию в потоке (первый из доступных), а не тот, что указан в АТС.

...если это обычный номер..., при звонке с этого номера callerid приходит верный.
Если это виртуальный номер, то при звонке на него и дальнейшей переадресации...

Вы сами-то поняли, чего написали?
В одном случае "с этого номера".
В другом - "на него и дальнейшей переадресации".
Так какой случай рассматривать?
И что значит: "по умолчанию в потоке, а не тот, что указан в АТС"?

Есть внутренний номер 180 (физический ТА, за которым сидит пользователь), в настройках CLIP у этого номера стоит XXXX90. При звонке с этого номера вызов на сотовом определяется также XXXX90
Есть внутренний номер 181 (на нем включена переадресация на сотовый), в настройках CLIP у номера 181 указано XXXX91. При звонке на этот номер, срабатывает переадресация на сотовый и уже на сотовом данный номер определяется как XXXX89.
В потоке идут номер XXXX89-XXXX99 - 10 номеров.
Так вот после общения с провайдером он подтвердил, что от АТС по Е1 не приходит callerid к нему, поэтому провайдер связи подставляет первый номер из потока.

И не должно.
Или будет приходить номер звонящего извне, или Ваша УАТС должна вместо него подставлять свой номер, который должен быть прописан в линейных настройках.
Номер извне - это нонсенс, иначе как операторы связи будут производить биллинг звонков?
Остаётся подставной номер от Вашей УАТС.
А поскольку в УАТС данный номер, наверняка, не прописан (т.к. у каждого абонента имеется свой CLIP), то оператор связи вынужден сам подставлять тот номер, который первый в пуле номеров.
===
Или сделайте данному абоненту другой CLIP, совпадающий с тем, который подставляет оператор.

Все правильно - в поток вы не отдаете вообще АОН, поэтому провайдер закрывает звонок первым номером из всего купленного вами пула городских номеров.
Попробуйте формировать АОН на транках, а не только у каждого абонента отдельно. Поэксперементируйте:
Routes- PABX number-outgouing - формируете шаблон.
Routing parametrs - No. and type, outgouing - с какого поля в шаблоне берутся значения.
После каждого изменения - включайте трассировку и смотрите по факту каким аоном закрывается звонок.

У Вас пул номеров всего-то 10 штук.
Зачем каждому абоненту давать свой CLIP?
Можно поток разделить на пучки (10 пучков), каждому пучку присвоить свой номер, а абонентов прикрепить каждого к своему пучку.
Тогда Ваша УАТС будет отдавать в поток тот номер, который присвоен данному пучку.
И если абонент 181 прикреплен к пучку, например, 3, у которого прописан номер XXXX91, то и в поток будет уходить именно этот номер.

И не должно.
Или будет приходить номер звонящего извне, или Ваша УАТС должна вместо него подставлять свой номер, который должен быть прописан в линейных настройках.
Номер извне - это нонсенс, иначе как операторы связи будут производить биллинг звонков?
Остаётся подставной номер от Вашей УАТС.
А поскольку в УАТС данный номер, наверняка, не прописан (т.к. у каждого абонента имеется свой CLIP), то оператор связи вынужден сам подставлять тот номер, который первый в пуле номеров.
===
Или сделайте данному абоненту другой CLIP, совпадающий с тем, который подставляет оператор.
Здесь вопрос скорее почему если в настройках extensions указан номер какой подставлять, то на обычном ТА эта настройка работает нормально (номер при исходящем подставляется), а в случае переадресации не работает? Получается что переадресация использует транк напрямую, минуя настройки extension?

Получается, что переадресация использует транк напрямую, минуя настройки extension?

Именно так!

А где-то можно настроить выбор транка для переадресации или указать какой CLIP использовать в случае переадресации?

Вы переадресовываете звонок в какой-то пучок линий.
CLIP этого пучка и есть тот самый CLIP.

Все правильно - в поток вы не отдаете вообще АОН, поэтому провайдер закрывает звонок первым номером из всего купленного вами пула городских номеров.
Попробуйте формировать АОН на транках, а не только у каждого абонента отдельно. Поэксперементируйте:
Routes- PABX number-outgouing - формируете шаблон.
Routing parametrs - No. and type, outgouing - с какого поля в шаблоне берутся значения.
После каждого изменения - включайте трассировку и смотрите по факту каким аоном закрывается звонок.
Пробовал менять настройки на транках, результат тот же при звонке. Трассировку пробовал смотреть только через SMDR. Подскажите трассировка должна быть со стороны провайдера?

Для трассировки есть специальная функция в Maintenance.
И есть также приложение для расшифровки сделанных трассировок.
Ими и надо пользоваться, а не SMDR.
Трассировку также можно попросить сделать и со стороны провайдера.
===
Может ещё быть вариант, при котором независимо от правильности номера, передаваемого вашей УАТС, провайдер просто тупо подставляет свой (то бишь, ваш пилотный).
Поскольку ранее ваша УАТС передавала неправильные ("левые") номера, провайдер подстраховался и сделал у себя такую тупую подстановку.
Его надо попросить, чтобы он её убрал.
А для этого он сначала должен оттрассировать транзитные звонки.

Подскажите трассировка должна быть со стороны провайдера?
У себя на станции заходим в Maintenance - CallMonitoring - выбираешь что будешь трассировать(указываешь первый таймслот в твоем потоке) - стартуешь.
Совершаешь звонок(в твоем случае просто сделать набор), видишь как побежали некоторые сообщения - сохраняешь их как текст.
Открываешь пуск-программы-isdn tracer-фаил-открыть (ASN поставь в euro ISDN). Открываешь текст. Как всем известно- АОН передается в сообщении SETUP:) - ищешь calling number - это и есть те цифры которыми ты закрыл исходящий набор. Если пусто - то вообще никакого АОНа не посылаешь.
Логично будет, что находясь по разные концы одного провода провайдер от тебя увидит то же самое, но по входящему для него направлению.
В итоге- добейся что бы от тебя уходил нормальный АОН, а потом что бы провайдер его пропускал.

У себя на станции заходим в Maintenance - CallMonitoring - выбираешь что будешь трассировать(указываешь первый таймслот в твоем потоке) - стартуешь.
Совершаешь звонок(в твоем случае просто сделать набор), видишь как побежали некоторые сообщения - сохраняешь их как текст.
Открываешь пуск-программы-isdn tracer-фаил-открыть (ASN поставь в euro ISDN). Открываешь текст. Как всем известно- АОН передается в сообщении SETUP:) - ищешь calling number - это и есть те цифры которыми ты закрыл исходящий набор. Если пусто - то вообще никакого АОНа не посылаешь.
Логично будет, что находясь по разные концы одного провода провайдер от тебя увидит то же самое, но по входящему для него направлению.
В итоге- добейся что бы от тебя уходил нормальный АОН, а потом что бы провайдер его пропускал.
Спасибо за развернутый ответ.
Вывод вот такой:
Time = 10:50:14
Slot/Port = DIUN2 7 - 1 - 4
Hipath -> SETUP
cr : 331 (from originating side)
bearer capab : 04 03 90 90 A3
Coding Standard: CCITT
Information Transfer Capability: 3.1 kHz audio
Transfer Mode: circuit mode
Information Transfer Rate: 64 kbit/s
User information layer 1 protocol: Recommendation
G.711 A-law
channel id : 18 03 A1 83 9E
Interface type: other interface
Preferred/Exclusive: preferred
D-Channel Indicator: not the D-channel
Information Channel Selection: as indicated in
following octets
Coding Standard: CCITT
Number/Map: number
Channel/Map Element Type: B-channel units
Channel number: 30
facility : 1C 34 91 A1 31 02 02 15 6A 02 01 0F 30 28 02
01 01 0A 01 01 A1 0F A0 0D A1 0B 0A 01 00 12
06 35 31 36 33 39 33 A2 0F A0 0D A1 0B 0A 01
00 12 06 35 31 36 33 39 33
Protocol Profile: ROSE
invokeComp
invokeID 5482
operationValue
localValue divertingLegInformation2
argument
diversionCounter 1
diversionReason cfu
divertingNr
presentationAllowedAddress
publicPartyNumber
publicTypeOfNumber unknown
publicNumberDigits 516393
originalCalledNr
presentationAllowedAddress
publicPartyNumber
publicTypeOfNumber unknown
publicNumberDigits 516393
progress ind : 1E 02 81 83
Coding Standard: CCITT
Location: private network serving the local user
Progress Description: origination address is
non-ISDN
calling num : 6C 08 01 80 35 31 36 33 39 33
Type of Number/Numbering Plan: unknown/ISDN
Presentation Indicator: presentation allowed
Screening Indicator: user-provided, not screened
Digit(s): 516393
called num : 70 0C 81 38 39 30 33 38 36 33 30 33 30 33
Type of Number/Numbering Plan: unknown/ISDN
Digit(s): 89038630303
user user : 7E 12 00 53 48 4F 07 0C 0E 31 34 37 34 32 33
37 30 30 33 31

Time = 10:50:15
Slot/Port = DIUN2 7 - 1 - 3
Hipath <- CALL PROCEEDING

Исходя из лога, я понимаю, что передаем номер 516393, но у меня на сотовом определяется как 516389 (первый номер потока). Провайдер говорит, что не видит callerid от нас.

Стало быть, надо добиться того, чтобы в поток передавался весь номер (10 знаков), а не его часть.
В абонентских настройках CLIP у абонента такой же: 516393?
А должен быть десятизначный.

Исходя из лога, я понимаю, что передаем номер 516393, но у меня на сотовом определяется как 516389 (первый номер потока). Провайдер говорит, что не видит callerid от нас.

Исходя из лога видим что в поток ушла некая последовательность из 10 цифр закрытая АОНом 516389.
Как минимум 6 значный АОН для провайдера не корректен(длина и значение), поэтому уже на провайдерской станции заменяется на пилотный..
P.S. в трейсе в поле Facility сказано что это переадресуемый звонок c TypeOfNumber-unknown, Поэтому выставляй значения в Routing parametrs - No. and type, outgouing.
Копай значения в настройках АОНа на маршрут, указанные в начальных сообщениях и смотри трейсом. У абонентов CLIP можешь вообще убрать пока

Да пусть выложит KDS!
Быстрее разберёмся.

Стало быть, надо добиться того, чтобы в поток передавался весь номер (10 знаков), а не его часть.
В абонентских настройках CLIP у абонента такой же: 516393?
А должен быть десятизначный.
В абонентский настройках 10ти значный CLIP с кодом города.

файл с выгрузкой: https://yadi.sk/d/GyK_ovh6he06cg

Сначала я бы сделал
1) в Routes - numbering plan - поставил ISDN numbering plan
2) CLIP у абонентов прописал 6 значный.
и с такими условиями уже начал смотреть трейсом чем закрываю звонки
PS в dial plan как минимум в dial rules table:0-СZ, но то такое..

не могу найти первый пункт https://yadi.sk/i/nIT-Nqpn3KYG3A

А версия Менеджера у Вас какая?
Версия станции - V6.0.
Менеджер должен быть как минимум не ниже шестёрки.

Напишите в личку свою почту - кину нормальный менеджер.

в целом получилась ситуация такая:
1) При звонке в город уходит индивидуальный CLID абонента 10 знаков.Что устраивает

2) При переадресации абон_А(internal) ----> абон_B(internal) ---FWD---> абон_С(external)
у абон_С определяется корректный АОН абонента А(индивидуальный CLID абонента). Что устраивает.

3) При звонке Абон_А(external_город) --->абон_B (internal)---FWD--->абон_C(external_моб)
абон_С(external) получает пилотный АОН провайдера.

Поток один. По нему приходит входящий вызов и уходит переадресованый. Для
вызова внутренних номеров- от прова на станцию приходит 6 значный DID и им же закрывается переадресованый звонок(???)
В трейсе видно что на участке "А к B" приходит АОН номера А,
на участке "B к C" в сообщении Facility в качестве АОНа появляется 6 значный DID номер провайдера. Следовательно 6 цифр не понимается провайдером и заменяются пилотным номером.
Все это дело прилагаю в виде трейса тут https://yadi.sk/d/H2sO_lnjawgmRg
P.S. впринципе помоему логично - это провайдер шлет в виде АОНа СВОЙ номер А в формате subscriber(??).
Просить провайдера что бы слал АОН в формате national ? или копать 3800 ?

Ну если продвинулся вперёд это хорошо. Могёшь теперь изменить НаПРавл 2 в что нибудь sitiCFU и не меняя рабочую ситуацию в целом выделить пару тройку каналов на нём вывести по новому префиксу в город попадая токо на эти каналы и продолжать экспериментировать дальше с переадресацией беря токо клип с поля клип. Да и наборный планчик (http://bbs.radiolink.ru/forum/showthread.php?p=391864#post391864) бы по корректней сделал.

И без отдельного направления - при переадресации и при трансфере такая же самая ситуация - 6 цифр аон откуда то берется и отправляется к прову.
PS диалплан потом допилится

Передать CLIP станции на переадресации, при наведении вызова на группу не получится.
Можно настроить в качестве АОН для таких вызовов, чтобы закрывалось тем же DID, на который пришел вызов.
Т.е. при вызове для DID 123456, переадресованный наружу вызов будет закрываться АОН 4742-123456.

Для этого, замените CLIPы у абонентов на 6-ть знаков (убрав 4742), о чем уже в теме писалось, и заполните корректно поля в Routes->PABX-number-outgoing.
Поставив значения -
Local area code: 474
PABX number: 2

Передать CLIP станции на переадресации, при наведении вызова на группу не получится.
Были такие подозрения..
Спасибо, именно так в итоге сделали. Была уже мысль просить прова что бы транслировал 10 значные DID...