Для индексации полезных и бесполезных разговоров

[notify_ded_bot]

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

(можно в личку если не для публичного поля)

два сервака amd 64/128, ram 2tb, карта меланокс, один как гипервизор, другой выступал в роли схд, сеть 100G через коммутаторы
так для интереса возможно ли 100G занять и потом стало аргументом в пользу 100G для cloud

[notify_ded_bot]

Fanvil его просто не успевает показать - между 180 и 183 у вас проходит 0,1 сек
Только что проверил - Fanvil 303 (301 нету) прекрасно берет имя из RPID в 180 и 200 (183 сгенерить у себя не могу).
Так что, если сможете заставить чансип отдавать RPID в 183, то будет вам счастье скорее всего.

решилось это установкой опции r в DIAL который ведет в транк. Плюс
trustrpid = yes
sendrpid = yes
rpid_update=yes
в sip_conf

[notify_ded_bot]

кстати в тему диска - а имеет ли смысл писать разговоры в память? Допустим примонтировать раздел в 30 Гб. Записи у меня сразу после окончания разговора конвертятся в mp3 и не остаются в исходном wav. Периодически по htop вижу что астер упирается во ввод/вывод. По мискмонитору около 100 каналов в момент пишется.

был проект где в очереди было 60 операторов со стратегией ring-all. Пришлось писать на SSD потому что обычный диск по IOPS не вытягивал. По факту там не больше 20 одновременных было

[notify_ded_bot]

был проект где в очереди было 60 операторов со стратегией ring-all. Пришлось писать на SSD потому что обычный диск по IOPS не вытягивал. По факту там не больше 20 одновременных было

Кстати... примерно так же

[notify_ded_bot]

еще в одном проекте в tmpfs складывал в раздел на 6 гб, на день хватало с лихвой, ночером все на диск сбрасывалось

[notify_ded_bot]

asterisk.conf
;cache_record_files = yes ; Cache recorded sound files to another
; directory during recording.
;record_cache_dir = /tmp ; Specify cache directory (used in conjunction
; with cache_record_files).

/tmp обычно и есть ram ?

[notify_ded_bot]

решилось это установкой опции r в DIAL который ведет в транк. Плюс
trustrpid = yes
sendrpid = yes
rpid_update=yes
в sip_conf

супер!

[notify_ded_bot]

Коллеги, есть FreePBX, и некоторая очередь с пятью операторами стратегия Ringall. Если в неё попадает вызов, один оператор его забирает у остальных вызов считается пропущенным. Эта статистика далее собирается всякими отчётами типа Asternic.

С одной стороны верно - не ответил на вызов, получи пропущенный, но с другой стороны вызов был отвечен и не пропал.

Можно ли как-то регулировать понятие пропущенного вызова в разрезе очереди. Что если он был отвечен любым из операторов, он не считался бы пропущенным для остальных? Или только менять стратегию дозвона, и к примеру, пропускать занятых операторов.

[notify_ded_bot]

Коллеги, есть FreePBX, и некоторая очередь с пятью операторами стратегия Ringall. Если в неё попадает вызов, один оператор его забирает у остальных вызов считается пропущенным. Эта статистика далее собирается всякими отчётами типа Asternic.

С одной стороны верно - не ответил на вызов, получи пропущенный, но с другой стороны вызов был отвечен и не пропал.

Можно ли как-то регулировать понятие пропущенного вызова в разрезе очереди. Что если он был отвечен любым из операторов, он не считался бы пропущенным для остальных? Или только менять стратегию дозвона, и к примеру, пропускать занятых операторов.

считать можно. Но что вы предлагаете, править Asternic?

[notify_ded_bot]

Коллеги, есть FreePBX, и некоторая очередь с пятью операторами стратегия Ringall. Если в неё попадает вызов, один оператор его забирает у остальных вызов считается пропущенным. Эта статистика далее собирается всякими отчётами типа Asternic.

С одной стороны верно - не ответил на вызов, получи пропущенный, но с другой стороны вызов был отвечен и не пропал.

Можно ли как-то регулировать понятие пропущенного вызова в разрезе очереди. Что если он был отвечен любым из операторов, он не считался бы пропущенным для остальных? Или только менять стратегию дозвона, и к примеру, пропускать занятых операторов.

Пишите свое.