asterisk.ru

А не мог я где-нибудь включить какое-нибудь ограничение сам? А?

ded писал(а):Да, SIP response 603 "Out of capacity" получает. Фишка в том, что код такой ошибки интерпретируется в BUSY,
Everyone is busy/congested at this time
а согласно человеческой логике - нет смысла отправлять второй вызов через альтернативный транк, если абонент занят (через первый типа транк).

Ded! Ну неужто не победить? Неужто за всю практику такого не встречалось?
С провайдером прояснять что-либо бесполезно - нет там спецов, только ТП (техподдержка). Фразы шаблонные - "на нашем оборудовании все работает". Конечно, работает- каждому FXS свой транк!

rusya писал(а):Vlad1983, у меня работают транки. каждый по отдельности. А перебор - нет. Если бы была блокировка по CID, ни один бы не работал...

Логично!
Могу посоветовать вот что:
1) разобрать SIP ответ на составляющие через переменные SIP_HEADER
для чего создать для теста кастомный контекст и отправить вызов из него через
exten => _X.,1,Dial(SIP/trunk1/${EXTEN})
exten => _X.,n,Dial(SIP/trunk2/${EXTEN})
exten => _X.,n,Dial(SIP/trunk3/${EXTEN})
exten => _X.,n,Dial(SIP/trunk4/${EXTEN})
и посмотреть как обработается вызов. Вытаскивать инфу об ответах через NoOp(${SIP_HEADER()}) и NoOp(${SIPCHANINFO})
и сделать свой макрос путём введения строк
GotoIf((${SIPCHANINFO}=фигзнает_ошибка_607):nextTrunk)
в текущий макрос macro-dialout

2) использовать GoTo или Gosub чтобы отправлять по BUSY через другой транк, но это не кажется мне изящным.

rusya писал(а):но это не кажется мне изящным.

А куча кастомных контекстов только для привязки к определенному транку кажется изящным?

rusya писал(а):Могу посоветовать вот что:

Мда... Я не настолько крут канешно. Но будем курить. Спасибо, Ded.

у меня работают транки. каждый по отдельности. А перебор - нет. Если бы была блокировка по CID, ни один бы не работал...

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

rusya,
Найдите макрос macro-dialout-trunk в extensions или extensions_additional, не помню где точно.
И перепишите его в extensions_override_freepbx, с изменениями в плане обработки hangupcause.
Я сам так боролся с левыми отбоями вполне успешно.

Думаю это самый рукопожатный способ

Мда.. А не создать ли багрепорт по этому поводу? Только где, на freepbx.org или на asterisk.org?

Какой багрепорт? Как можно учитывать поведение ВСЕХ шлюзов и софтсвичей ВСЕХ производителей?
Для тонкой обработки и придуман extensions_override_freepbx - пиши всё своё да и обрабатывай как хочешь!

А может, у меня не указано, что надо транки перебирать? Где вообще это задается и какова стратегия перебора?

Может создать багрепорт? Не знаю где задаётся у меня перебор транков! Это баг, надо поправить, чтоб я знал.