Разбираю новогодний SMDR и встретил одну странность, объяснить которую не могу. Возможно Вы знаете.
Первая запись ____7662 DISA 004 00:00:35 02/01/10 12:49 I RING 00:10
Строк через 15 ____7662 1167 004 00:00:30 02/01/10 16:58 I RING 00:00
Записи под одним номером, но разнесены по времени на 4 часа. Что это - чудо или ошибка?

P.S. Таких задвоенных и разнесенных по времени записей за праздники набралось 106 штук

Ну и откуда мы знаем, что там у Вас в станции "накручено"??
Это Вам самому нужно смотреть ситуацию на станции...
- что назначено для СО004, как именно назначен прием вызовов и т.п.
- какие функции активированы на STA1167 (Переадресация и т п.)
- Используется ли Networking, используется ли переадресация на сетевого абонента в другой станции??

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

Меня удивило отклонение от обычных записей.
На праздники была установлена переадресация через терминальную группу по переполнению на дежурные сотовые телефоны. В терминальной группе только один номер - свободный внутренний порт.
Обычно записи при переадресации у меня выглядят так:
7646 DISA 003 00:01:03 01/01/10 20:39 I RING 00:10
7647 1167 063 00:00:58 01/01/10 20:39 О89156275959
Вызов пришел по линии 003 и переведен на линию 063 с набором сотового номера из скоростного набора. Номер 1167 во всех записях, но он не имеет отношения к терминальной группе - это номер аттенданта.
При переадресации по сети тоже похожие записи, например:
8285 1167 062 00:01:54 06/01/10 10:16 О89156029333
8286 DISA 039 00:01:59 06/01/10 10:16 I1175 RING 00:11
039- сетевая группа линий. Вызов пришел с конечной станции по линии 039 на номер 1175, на котором установлена предустановленая переадресация на терминальную группу-переполнение- ячейка скоростного набора.
Но с чем связаны те, другие записи под одним номером, но разнесенные по времени. Реально организация не работала, был только охранник.
Терминальных групп используемых при переадресации порядка 20 штук. Во всех есть схожие записи.Почему в записях всегда фигурирует телефон аттенданта также непонятно.

Станция подставляет номер ATTD во всех случаях выполнения каких-либо системных функций, и переадресация по переполнению из Hunt-группы - это как раз такой случай.

Указанные строки с одним и тем номером вызова - это скорее всего ВОЗВРАТ вызова (Recalling).

Спасибо за ответ!
К сожалению не ясна причина возврата.
Но есть одна закономерность - всегда для DISA I RING 00:10!
Т.е. в таких случаях всегда три записи, а не две:
7646 DISA 003 00:01:03 01/01/10 20:39 I RING 00:10
7647 1167 063 00:00:58 01/01/10 20:39 О89156275959
......
7646 1167 003 00:00:57 02/01/10 11:05 I RING 00:00
Причем возврат может быть через 10 минут, может через сутки
Приведен реальный пример - возврат через 15 часов.

СО 063 - какого типа линия??? Аналоговая СО/ISDN/VoIP ??
СО 003\004 - аналоговые СО??
10 сек - это время до выдачи Приветствия Группы (VMIB Announce Timer 1) или время таймера переполнения???

Все линии аналоговые и нет привязки эффекта к конкретной линии.
VMIB Announce Timer 1 -0. Таймер переполнения - 1с.
10с. в настройках групп нигде не фигурирует.

А какое значение CO Transit Timer??? Линии с импульсным набором??

Все линии с тональным набором.
Прошу прощения CO Transit Timer - какой номер пгм. (не соображу где искать)

ПГМ181/16.
Ну, раз линии тоновые, то нет смысла искать этот таймер.

- Какая версия софта??
- А не пробовали сами смоделировать такую ситуцию??

Transit Connect Timer PGM181/16

Вообще-то, использовать аналоговые линии для переадресации типа СО-СО - это в любом случае чревато подвисаниями линий. Возможно именно это у Вас и происходит.

У Вас установлены внешние детекторы отбоя ("отбойники") или нет??

3.9Ah
Раньше я не обращал внимание на такую особенность - переадресация всегда осуществляется в нерабочее время, но охранники говорят, что бывает телефон аттенданта звонит, хотя назначений на него нет. Кроме того, именно в праздники была массовая переадресация. В обычные дни переадресовываются единичные звонки и естественно ничего не заметно.
В праздники было переадресовано 375 звонков, из них с возвратом -106.
Думаю, что нужно наблюдать дальше. Проблемы нет.

P.S. Сегодня была похожая ситуация на LDK-60. Секретарь говорит, что стали срываться входящие вызовы через 10-13с. с выдачей сигнала "ошибка". Действительно, 3 из 4 входящих срывались по такой схеме.Если секретарь успевал перевести звонок до 10с., разговор продолжался дальше. У секретаря системный телефон LDP -7024. Вчера я включил её номер в терминальную группу и сделал назначения входящих вызовов на эту группу. В группе она одна, но этот номер входит и в другую терминальную группу. Проблема решилась, когда прописал назначения входящих просто на ее номер. Срывы прекратились. Интересно, что на второй нашей LDK-60 первая схема работает без всяких срывов.

У Вас установлены внешние детекторы отбоя ("отбойники") или нет??

Нет. На все платах CLCOB8 (их 4) установлены CPTU. Таймер неконтролируемой конференции 5 минут. Раньше линии при переадресации зависали часто, сейчас очень редко.

В данных записях (I RING 00:10) 10 сек - это длительность входного приветствия VMIB.

Наверно так и есть, но с чем связано появление этой третьей записи в SMDR.
Кстати я не уверен, что телефон 1167 звонит на самом деле, как отмечает SMDR.

У меня не получилось смоделировать вашу ситуацию. Во всех вариантах - 1 или 2 записи.
Возможно, это баг. Но непонятно, с чем именно он связан.
Попробуйте сами поэкпериментировать на своей станции. Сделайте входящие вызовы и понаблюдайте.

Спасибо!
Буду проверять.

В очередной раз прочел сейчас всю ветку. Вспомнились праздничные попытки позвонить кому-нибудь на мобильник-то люлюканье, то "абонент не доступен", в общем, что угодно, но не посылки вызова после набора номера. Крутится мысль в голове, а с этим ваша ситуация никак не может быть связана... Праздничные дни, переадресация на мобильники, да еще, помнится, через GSM-шлюзы...Может быть бред, конечно! А может вам попробовать смоделировать подобную ситуацию, например, переадресовывать вызов на выключенный мобильник...

Трудно сказать в чем причина, но главное на работе станции не сказывается. Дело в том, что SMDR указывает на нормальную продолжительность разговора. Перед Новым годом эксперементировал с настройкой музыки при переадресации, может это повлияло, а может было уже давно было, но не замечал.
Сложность проверки в эксперементе в том, что звонок может вернуться когда угодно, даже через сутки. Буду делать тестовые звонки, а потом искать дублирующие записи (хорошо, что их ищу не в ручную, а тарификатором).

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

Удалось смоделировать ситуацию о странностях SMDR (правда на aria soho, но, думаю, принципиально одинаково).
1186 DISA 002 00:00:18 14/01/10 19:52 I RING 00:00
1187 100 001 00:00:15 14/01/10 19:52 O89109457884 ** 0 0
1186 100 002 00:00:12 14/01/10 19:53 I RING 00:11

Что делал:
Звонки по одной аналоговой линии назначил в терминальную группу, в которой один абонент, таймер по переполнению 1с, назначение на ячейку (на внешний номер). Переадресация по другой аналоговой внешней линии.
Что получилось:
Первый вызов (1,2 строчки SMDR)- все ОК.
Второй вызов (3 строчка SMDR)-звонит дежурный телефон с надписью на дисплее OVERFLOW FROM GR *622, никакой переадресации наружу нет.
Следующий вызов-все ОК, потом опять дежурный. И с этой периодичностью все повторяется.
Думается, что это НЕНОРМАЛЬНО!

Единственная оговорка, переадресация выполнялась на пустую линию, на порт, к которому фактически ничего не подключено. Городской второй линии нет аналоговой. Да и поздновато уже засиделся!

Точно. Теперь все сходится. В праздники пришлось приезжать один раз на работу. При мне зазвонил телефон аттенданта. На дисплее появилась надпись OVERFLOW FROM АЖН (АЖН-это у нас отдел такой и название группы). Только не уверен, что OVERFLOW (вроде бы просто OVER). Я снял трубку и там был живой человек.
Выходит, что третья запись только номером связана с первыми двумя - это самостоятельный входящий звонок для которого не сработала переадресация!
Кстати у меня в группе как раз и прописан свободный внутренний порт.

Когда я писал о пустом портике, я имел в виду порт аналоговой СО.
Надо будет проверить еще эту фишку без DISA. Почему то думается, что без DISA нормально будет пахать. Хотя... Проверить надо!

Проверил сегодня эту ситуацию и без DISA, и на других типах групп. Поведение совершенно одинаково! Каждый второй вызов не переадрессуется по назначению на ячейку!
Кстати, надпись DISA присутствует и с включенным и с отключенным режимом DISA.

Нет. Это не может быть самостоятельный входящий звонок... Если номер (идентификатор) вызова такой же, то значит обе записи (1-я и 3-я) относится к одному и тому же вызову.

Ситуация то такая, первый вызов в группу, сработала переадресация на внешний номер. Второй вызов в группу-звонит дежурный. Третий вызов-перадресация, четвертый-дежурный и т.д.
Ну и вот такие строчки SMDR
1186 DISA 002 00:00:18 14/01/10 19:52 I RING 00:00
1187 100 001 00:00:15 14/01/10 19:52 O89109457884 ** 0 0
1186 100 002 00:00:12 14/01/10 19:53 I RING 00:11
Проверял на совершенно неиспользуемой станции. Т.е., звонил только я!

В записях SMDR указатель DISA в поле STA может обозначать не только собственно режим DISA, но и другие ситуации.
В том числе метка "DISA" обозначает, что внешний входящий вызов передресуется обратно на внешнюю сеть (Off-Net).

Я так и подумал, поэтому этим не заморачивался!

Согласно записям SMDR - так, но, фактически, вызовы разные!

Ну и что???
А куда Вы переадресуете?? Как прописана Speed-ячейка??? С указанием конкретной СО-линии/Группы линий/Loop-код (9-ка)???
Есть ли доступные линии в момент переадресации??? Если линий нет, то вызов пойдет на Attendant'a с указанием Overflow from GRP XXX.

Еще раз повторюсь

Удалось смоделировать ситуацию о странностях SMDR (правда на aria soho, но, думаю, принципиально одинаково).
1186 DISA 002 00:00:18 14/01/10 19:52 I RING 00:00
1187 100 001 00:00:15 14/01/10 19:52 O89109457884 ** 0 0
1186 100 002 00:00:12 14/01/10 19:53 I RING 00:11

Что делал:
Звонки по одной аналоговой линии назначил в терминальную группу, в которой один абонент, таймер по переполнению 1с, назначение на ячейку (на внешний номер). Переадресация по другой аналоговой внешней линии.
Что получилось:
Первый вызов (1,2 строчки SMDR)- все ОК.
Второй вызов (3 строчка SMDR)-звонит дежурный телефон с надписью на дисплее OVERFLOW FROM GR *622, никакой переадресации наружу нет.

После певого вызова все линии освобождались! Ну проверьте сами!
Ячейка прописана с системного телефона. Просто введен номер мобильного. Из всей АТС использовались 1 и 2 линии, гр.1. Остальные исключены из исходящей связи.

Я проверял на 300-ке. Там все нормально!!!
ОК. Сейчас посмотрю на ARIA SOHO. Какая у Вас версия на Сохо??

Ну если так, то АТС считает, что нет сводных линий. Но они то есть!

У автора темы эта ситуация на 300-ке.
А на ARIA SOHO у меня версия GS84P-3.7Fb SEP/08
На 300-ке у меня сейчас, к сожалению, нет возможности это проверить!

Если честно, я сам крайне удивлен! Просто не приходилось сталкиваться на практике. Нет такой массовой переадресации на внешние номера, как у автора темы. У нас, обычно, все проще. Абонент у себя поставил переадресацию безусловную на внешний номер и хватит!

Каким образом освободались???
По таймеру конференции или по сигналу CPT??

По сигналу CPT

Отключите CPT в ПГМ142 (Busy/Error CPT) и дождитесь, чтобы линии отбились по Таймеру конференции (ПГМ182/6 - Unsupervised Conference). Поставьте таймер = 1-2 мин, чтоб не слишком долго ждать.
Посмотрите, что будет в этом случае (SMDR, переадресация и т.д.)

Ок!

Дополню к теме, что у нас используется внутренний LCR. В ячейках не прописана никакая группа линий, подразумевается, что ее выберет LCR. В группе внешних линий, используемых именно при переадресации, 3 GSM-шлюза + есть альтернативное назначение с этой группы в LCR на группу из 6 городских линий. Таким образом, линии не могут быть заняты.

Проверил. В этом случае все правильно работает!

1225 DISA 002 00:01:00 15/01/10 10:46 I RING 00:00
1226 100 001 00:00:57 15/01/10 10:46 O89109457884 ** 0 0

Так выглядят строчки SMDR для каждого вызова. Таймер неконтролируемой конференции 1 мин.

Получается, неувязочка с CPTU, автор темы, кстати, на 300-ке использует CPTU.

Да, на всех платах CLCOB8 установлены CPTU. И что теперь делать? Если их отключить линии начнут зависать.

Зато мне стало понятно, почему я до сих пор не сталкивался с такой проблемой. На ipLDK-100/300 я не использовал CPTU ввиду малой эффективности, а на ARIA SOHO, не использовали такую схему переадресации. Как уже выше писал, абонент установит переадресацию безусловную на внешний номер и нормально!

1. Хорошо было бы проверить аналогичную ситуацию на ipLDK-60 с версией С.8Eg (последней). На этой версии был устранен баг в работе CPT при трансфере. Возможно, что при этом также сама собой устранилась и текущая проблемка.
Увы, я сейчас врядли смогу это проверить на 60-ке.

К сожалению, для других моделей системы ipLDK и для ARIA SOHO пока еще не появилась аналогичная версия софта.

2. СPTU в станциях ipLDK-100/300/600 реализованы хуже, чем в ARIA SOHO и в ipLDK-60.
Поэтому, ИМХО, в станциях 100/300/600 лучше, т.е. надежнее, использовать внешние отбойники и фунцию Open Loop Detect, чем встроенные CPTU !!!

К сожалению, я тоже не могу проверить это сейчас на 60-ке. Но при первом возможном случае обязательно проверю, посему как, меня в первую очередь интересует устранение бага в работе CPT при трансфере.

Могу проверить на 60. Где взять последнюю версию софта С.8Eg. На сайте нет.

Куда отправить?