Здравствуйте!

У меня возникла проблема, по одному из потоков корпоративной сети на Меридиане подключен SAMSUNG iDCS-500 в настройках PRI у него указано отдавать АОН типом SUBSCRIBER, план нумерации ISDN. Но Меридиан АОН-ы не видит и не транслирует к операторам. В другой поток корпоративной сети на Меридиане включен голосовой шлюз CISCO AS5300 и из него все АОН-ы идут нормально.

Рекомендовали сравнить настройки маршрутов, сравнил они идентичные, за исключением того, что голосовой шлюз рабоатет как NETWORK, а iDCS-500 как USER. Ранее вместо Меридиана тоже стояла iDCS-500 и она АОН-ы нормально транслировала.

На iDCS-500 сидит более 100 абонентов активно использующих междугороднюю связь, транслируется около 20 АОНов.

Подскажите в чем может быть дело.

трассировочку Д-канала бы увидеть (чего там с самсуня прилетает).
чисто так... для того, что-бы беседа завязалась ;)

Подскажите пожалуйста как D-канал трассировать, как звонки с внутренних абонентов знаю а вот этого нет :(

ld 96
enl msgi <номер d-канала> -- мониторинг входящих сообщений
enl msgo <номер d-канала> -- мониторинг исходящих сообщений.

С Гнусмаса 500-го прилетает все очень криво. У него не соответсвует то что выставляешь в настройках тому что он отдает.

Полгода назад точно было еще криво

Вот и я вижу по трассировке что от него приходит АОН в формате UNKNOWN/UNKNOWN хотя на нем стоит SUBSCRIBER/ISDN

DCH 17 UIPE_IMSG CC_SETUP_IND REF 000003A9 TOD 15:34:30 CK 0BF424B2
CALLING #:7978499 NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:92088578 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 17 UIPE_OMSG CC_PROCEED_REQ REF 000083A9 CH 4 27 TOD 15:34:30 CK 0BF424DB

DCH 17 UIPE_OMSG CC_PROGRESS_REQ REF 000083A9 CH 4 27 TOD 15:34:38 CK 0BF46223
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
PROGRESS: CALL IS NOT END TO END ISDN

DCH 17 UIPE_OMSG CC_SETUP_RESP REF 000083A9 CH 4 27 TOD 15:34:42 CK 0BF486E6
PROGRESS: INTERWORKING WITH PRIVATE WORK

DCH 17 UIPE_IMSG CC_SETUPCOMP_IND REF 000003A9 CH 4 27 TOD 15:34:42 CK 0BF48756

DCH 17 UIPE_IMSG CC_DISC_IND REF 000003A7 CH 4 29 TOD 15:34:44 CK 0BF495AA
CAUSE: #16 - NORMAL CALL CLEARING

DCH 17 UIPE_OMSG CC_RELEASE_REQ REF 000083A7 CH 4 29 TOD 15:34:44 CK 0BF495B3

DCH 17 UIPE_IMSG CC_RELEASE_CONF REF 000003A7 CH 4 29 TOD 15:34:44 CK 0BF4963E
CAUSE: #16 - NORMAL CALL CLEARING

DCH 17 UIPE_IMSG CC_DISC_IND REF 000003A8 CH 4 28 TOD 15:35:36 CK 0BF62569
CAUSE: #16 - NORMAL CALL CLEARING

DCH 17 UIPE_OMSG CC_RELEASE_REQ REF 000083A8 CH 4 28 TOD 15:35:36 CK 0BF62572

DCH 17 UIPE_IMSG CC_RELEASE_CONF REF 000003A8 CH 4 28 TOD 15:35:36 CK 0BF625F7
CAUSE: #16 - NORMAL CALL CLEARING

Ставлю на нем UNKNOWN/ISDN - в CDR появляются номера, но мне нужно отдавать операторам номер именно в формате SUBSCRIBER/<не важно>. На исходящих маршрутах у меня все настроено соответствующим образом.

Побороть то как удалось или все так глухо :(

Во, то шо я и подохревал! Я полгода назад от работы в операторе перешел на более тихое место ,так-шо не скажу полечили или нет. Но полгода назад бороли только выставление билинг номера на меридиане с потока клиента.
У меня еще мрачнее было надо было выставить NATL/ISDN :confused:
Хотя SUBSCRIBER/UNKNOWN вроде получалось.
Долбай поставщика гнусмаса, иначе не лечиться. :(

Можно заставить Меридиан каким-то образом перетранслировать из UNKNOWN в SUBSCRIBER?

И еще можно заставить Меридиан в CDR вместо номеров внутренних телефонов 201, 202 и т.д. подтставлять их АОН, я конечно понимаю что возможно проще это сделать силами самой биллинговой программы, но все-же.

Дело в том, что ранее вместо Меридиана стояла iDCS-500 и она нормально отдавала и транслировала операторам АОН-ы. Со стороны операторов никаких переконфигураций не было. Когда подключали iDCS-500 и настраивали АОН-ы, то прибором смотрели тип номера отдаваемого в поток SAMSUNG-ом и все было в норме. Может я где-то недокрутил?

А вот это ХЗ.
Просто меридиан, рассматривает еще и фасилити сообщения ,а вних у гнусмасов полный бардак.

Включил iDCS-500 PRI потоком в голосовой шлюз AS5300 и стал звоить, включив трассироку q931 на CISCO вот что дает шлюз

ISDN Se3:15 Q931: RX <- SETUP pd = 8 callref = 0x0100
Bearer Capability i = 0x8090A3
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Calling Party Number i = 0xC0, '3634363'
Plan:Unknown, Type:Subscriber(local)
Called Party Number i = 0x80, '989175051020'
Plan:Unknown, Type:Unknown
High Layer Compat i = 0x9181
Sending Complete
ISDN Se3:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8100
Channel ID i = 0xA98381
Exclusive, Channel 1
ISDN Se3:15 Q931: TX -> ALERTING pd = 8 callref = 0x8100
Progress Ind i = 0x8288 - In-band info or appropriate now available
Progress Ind i = 0x8282 - Destination address is non-ISDN
ISDN Se3:15 Q931: TX -> PROGRESS pd = 8 callref = 0x8100
Progress Ind i = 0x8A81 - Call not end-to-end ISDN, may have in-band info
ISDN Se3:15 Q931: TX -> PROGRESS pd = 8 callref = 0x8100
Cause i = 0x8091 - User busy
Progress Ind i = 0x8288 - In-band info or appropriate now available
ISDN Se3:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x8100
Cause i = 0x8290 - Normal call clearing
ISDN Se3:15 Q931: RX <- RELEASE pd = 8 callref = 0x0100
ISDN Se3:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8100

Т.е. из трассировки видно что iDCS-500 отдает номер именно типом SUBSCRIBER.

Понимаю что может и криво отдает, но все нормально работает с другим оборудованием (включены пара Panasonic-ов, Avaya IPOffice, голосовые шлюзы CISCO, несколько SAMSUNG DCS Compact II). И все это хозяйство работало как нужно со станциями операторов. Я конечно понимаю что можно ответить типа "Ну а чего тогда Меридиан поставили", но вот такая у меня задача. Можно ли сконфигурировать Меридиан что-бы он не так "въедливо" рассматривал входящие звонки?

А при SUBSCRIBER/UNKNOWN кажется только 7 цифр понимается. У тебя похоже больше.
Хоотя могу и ошибиться.

Да нет, ровно 7, в том-то и дело (3634363, 7978499), это я знаю. Меридиан не воспринимает цифры номера когда я ставлю на iDCS-500 subscriber, а вот при выставлении unknown, он их "видит" :( А Циска видит и так и так.

Я вижу у вас Самсунг отдает номер "блочным" способом, а если попробовать работать "оверлапом". В свое время когда запускал GDK по PRI через Меридиан, CLID шел "криво" при "блочном" методе и пошел после перевода в "оверлап".
Времени разбираться в этом не было, да и анализатора не было тоже, поэтому так и оставили.
Попробуйте может поможет.

Попробовал overlap-ом, но ничего не изменилось, жду ответ от поставщиков SAMSUNG-а. Пробовал на iDCS-500 прошивочки менять, не помогает :(. И у нас нет анализатора, но повторяю когда "вязали" Самсунг со станцией оператора, то прибор показывал что номер приходит с нужным типом :o . Я уже и не знаю что делать. Настроить трансляцию АОН-а нужно обязательно.

Большое спасибо всем за помощь. Ситуация была решена в положительную сторону обновлением прошивки ISDN PRI карточек на SAMSUNG iDCS-500 до версии 1.07 (ранее стояла 1.05) после этого номер стал приходить в правильном с точки зрения Меридиана формате и он его начал нормально транслировать далее к операторам.

Возможно кому-то эта информация окажется полезной

О. Сенкс за инфу. Сам когда-то долбался ,но производители тогда еще на прошивку не раздуплились.