Вчера занимался изменением диалплана (extensions.conf) и нарвался на проблему - вместо того, чтобы работать как задумано, стало сообщать
ERROR[16606] app_macro.c: Macro(): possible infinite loop detected. Returning early.
Вбил это сообщение в google. Ничего путного не нашел (или так мне показалось).
Вбил это сообщение в поиск по исходникам Asterisk. Нашел текст модуля app_macro.c, где и написано, что за предельно допустимую глубину вызовов макросов отвечает переменная канала MACRO_RECURSION, после чего вписал в проблемный контекст вот такое
exten => s,n,Set(MACRO_RECURSION=10)
и проблему решил. На все-про-все потратил около 60 минут.
Вопрос: сколько дней/недель/месяцев потребуется для фиксации чего-то подобного пропретарном продукте?
P.S. все потенциальные проблемы большой вложенности Macro мне известны.

Как-то это притянуто за уши.
Все равно что говорить: "У меня ВАЗ-2105, когда мне треснули лопатой по крыше, я отогнул вмятины обратно молоточком за три дня. А если бы у меня был Мерседес, в сервисе мне бы меняли крышу две недели!"

Glukinho, да нет-с. Мы можем оценить не только быстроту саморешения проблем, но и общий функционал.
Используя то же сравнение - как быстро, мягко и удобно бегает по одной и той же дороге наш ВАЗ-2105 и Мерседес.
Так вот Астериск бегает много лучше многих проприетарных продуктов, по богатству функционала и простоте настройки - сильно опережает многих.

Полностью согласен.
Лишь хочу сказать, что у * перед проприетарщиной есть еще и более весомые преимущества кроме возможности откопать недокументированную ошибку в исходном коде. Не факт, что такая ошибка на другой платформе вообще возникнет.

Mog: красивое решение :)

Не притянуто. Это вообще была не ошибка в Asteriske. Это было такая работа моего диалплана, на которую не была по умолчанию рассчитана работа интерпретатора диалплана Asteriska. И пользуясь открытостью исходного кода я узнал за 30 минут, какая опция в настройках отвечает за поведение. Продолжая аналогию. Есть мерседес, в который нужно лить 95 бензин. Открываешь капот, а там табличка понятная приделана, какую кнопку нажать, чтобы перейти на 92.
Не хотел разжевывать, но, видать, придется.
Повторяю, речь идет о том, что благодаря тому, что исходный код открыт, каждый (кто умеет читать) может понять, как работает та или иная функция в Asterisk. По сравнению с пропретарными системами, код которых закрыт, это преимущество, притом огромное.
Благодаря этому при прочих равных Asterisk надежнее, т.к. ошибки в нем ищет не 10 (20, впишите любое число) тестеров разработчика, а весь мир.
Благодаря этому при прочих равных Asterisk лучше документирован, т.к. даже при отсутствии других источников можно посмотреть исходный код.
Благодаря этому при прочих равных Asterisk быстрее развивается, т.к. даже если нужной функции нет, а она ну очень нужна, каждый её может дописать.
При желании список можно продолжить.

ух сколько пафоса :) Весь мир, какже.
Никто кроме специально обученных securitylabs и прочих в этом не копается, оно им не надо. Ошибки находят простые смертные при попытке задружить астериск со своим оборудованием например.
Обратите внимание - не ИЩУТ а НАХОДЯТ. Это суть разные вещи.
Тестирования в Астериске как такового НЕТ. Регрессия сплошь и рядом. Им ничего не стоит зарелизить версию с фиксом который разрушает старую функциональность вдоль и попререк. А все потому что у них нет стенда на котором Астериск можно поднять и запустить автоматическоее тестирование по тысяче сценариев.

А у Мерседеса такие стенды есть.

А насчет что можно если что пропатчить исходных код... Ну это кагбэ оптимистично просто сказано. Я не знаю, пробовали ли вы патчить скажем chan_sip. Это кагбэ УХ. То есть можно конечно, но много выпить надо сначала. (Разумеется если речь о каком-то серьезном изменении а не опечатку исправить)

О chan_sip.. Во FreeSWITCH взяли Sofia-SIP, стек от Нокия. А не стали с нуля RFC имплементировать. ИМХО правильный подход.

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