Есть некий [Фрукт]. Есть *.
Задача: При нажатии пимпочки на вэб-лице заставить * регистрироваться на [Фрукте] под username\password, в добавок к уже имеющимся регистрациям.

Как я понял, сейчас реалтаймовый механизм позволяет выносить из sip.conf в базу только описание пиров, но не строки register. Потому пока вижу только вариант с инклюдом файла содержащего эти строки, в который, при "нажатии пимпочки" будет добавляться новая строка. После чего делать reload chan_sip.

Оччень не хочется использовать этот вариант! Жду от вас альтернативных предложений.

мне, ктати, тоже интересно, как это сделать...

Дополнение: Какой максимальный размер файла sip.conf переварит *? Не то, чтобы он у меня в перспективе измерялся в сотнях\тышах метробайтов, но хотелось бы знать порядок цифИрок=)

Можно кстати попробовать сделать static realtime на инклюженный файл с регистрациями. А динамиком похоже никак, без правки кода (

Астериск переварит значительно больше чем имеет смысл писать в sip.conf'ах:

23:11 [1] ws# tail -n 11 sip.conf
[tt](!)
type=friend
host=dynamic
disallow=all
allow=alaw,ulaw,g729
canreinvite=no
nat=no
context=test

#include sip_gm.conf
#include sip_test.conf

i=1; while test $i -le 100000 ; do printf "[sip"$i"](tt)\nsecret=123\n\n" ; i=$(($i+1)); done > sip_test.conf

Вот результат загрузки:
89206 root 29 70 0 579M 385M select 1 16:52 91.65% asterisk

Это fbsd/amd64 @ E6550

Оно таки живет, показывает все 100к пиров в sip show peers, но практического смысла в этом...

-rw-r--r-- 1 root wheel 2,6M 22 май 23:12 sip_test.conf
Если без template'ов, то будет раза в 3 больше, но на скорость обработки это вряд ли повлияет, разве что в сторону уменьшения

Спасибо bird_of_Luck, такой порядок меня очень устраивает!
При работе с файлом не устраивает только невозможность позиционирования на определенную запись.

по моим тестам большое кол-во учеток в sip.conf особо не влияет на загрузку (я, конечно, не 100000 учеток делал, всего 3000). В процессе обработки звонков сильно влияет наличие qualify и время регистрации. Так 1000 зарегеных учеток с интервалом 600 секунд дают LA до 70 на 120 одновременных звонков. а без qualify и временем 3600 секунд - LA всего 4..10.

вот на этом графике время регистрации 600 секунд:

а на этом, увеличена до 3600


значения на графиках с учетом коэффициентов, чтоб влезли на один график
curr_calls - всего звонков (show channels)
sip_calls/10 - sip транзакций (sip show channels)
cpu_idle/2
load_avg*10
snd_err - субъективная оценка качества звука, от 10 до 50, чем больше - тем хуже
mem_t_free/10000
mem_t_used/10000
swap_free/10000
swap_used/10000
между отсчетами - 5 секунд.

машинка:
- CPU Intel Pentium 4 2.4 GHz
- Chipset Intel 845GV ICH4
- Front Side Bus 533 MHz
- DDR-SDRAM 400 MHz 512 Mb
- 2хOpenvox D210P


развернутый отчет готовлю...

от 200 пиров с sip_ping(quality) стоит ставить kamailio/openser как регистратор.
исходяшие регистрации в большом количестве * тоже не тянет. sipUA тянет. а астериск удобен имеено как pbx. и в этом качестве зависит от количества одновремменных каналов, количество юзеров побоку(если регистрация на proxy(kamailio) ).
имхо вы поторатите меньше времени на изучение kamailio, чем на перписание астериска под эту задачу;)
зы. респект switch за графики

У меня стояла задача: обеспечить преобразование 120 каналов из sip в tdm, вот и решил потестить. 120 каналов - это примерно 1000...1500 абонентов. в общем считаю, что моя машинка с этой задачей справилась.
kamailio/openser надо изучать, несомненно.

switch, а версия-то какая?
а то там народ в шестой ветке последовательно кучу структур под ast_obj2 переделал и стал хранить пиры в хэщ-таблицах вместо связанных списков. На большом числе пиров это может существенную роль сыграть...

версия 1.4.21-2