asterisk.ru

shakirov писал(а):есть мнение что надо для транков укзатаь maxchannels в реальных цифрах.

Да разобрались....
Добрые люди подсказали
http://www.freepbx.org/forum/freepbx/ge ... nk-in-list

Беда в том, что я никак не могу заставить провайдера авторизоваться по username и secret, т.е., заставить ходить входящие каждому через свой транк. Сейчас он (провайдер) видит первый попавшийся peer c его айпишником, а там insecure=invite,port, и все входящие заруливает через него. Если убирать insecure=invite,port, то не авторизуется . Таким образом, я не могу использовать ограничение по входящим в автоматически созданном контексте from-trunk-sip-тратата. Так и придется писать предложенную ded обработку, а знаний и времени пока не хватает.

Вот везде пишут, что при входящем звонке производится попытка обнаружить user и только потом peer. В моем случае при sip debug я не вижу никаких "no user тратата" in SIP user list. Такое ощущение, что книги пишутся для воображаемых миров, где пони какают радугой. Такой вот ЖЖ веду я сам с собою, да.

Да не , всё нормуль с книгами. 99% настраивают по этим книгам и спокойно себе работают . А у кого-то не выходит. ACL в таблицах пиров понятный и простой . SIp debug'а всегда хватало . чтобы понять причину той или иной проблемы с регистрациями и инвайтами. Надо просто выдохнуть , отдохнуть и снова всё проанализировать.

Все решил грязным хаком как здесь
И на что только не пойдешь, чтобы не ковырять этот ваш диалплан!

ded писал(а):Вытаскивать инфу об ответах через NoOp(${SIP_HEADER()}) и NoOp(${SIPCHANINFO})
и сделать свой макрос

От скуки воткнул NoOp($SIP_HEADER(From)}) и NoOp(S{CHANNEL(peerip)}) после DIAL в [macro-dialout-trunk], перенесенный во override_тратата....
NoOp отдает заголовки SIP внутреннего номера, а не peer провайдера. Я снова застрял.
Нет, оно конечно работает и с пропатченным chan_sip, но внутреннее чувство неправильности заставляет меня ковыряться снова и снова.

И снова здравствуйте, мои дорогие напыщенные мастера солдатского юмора и поклонники творчества Евгения Вагановича.
Opzione numero due:
Почему вы не поведали мне о волшебных свойствах переменной SIP_CAUSE? и вынудили нагенерить несколько страниц изысканий? Забыли, не знали, аль "кабута спицальна"? Но, опять-таки, мир не без добрых забугорных людей

Ладно, в конечном итоге наиболее приемлемым для меня способом проблема, обозначенная в топике решается так:
1.Копируется макрос [macro-dialout-trunk] из файла extensions_additional.conf в файл extensions_override_freepbx.conf
2. После строчки exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM},300,${DIAL_TRUNK_OPTIONS})
втыкаем наше
exten => s,n,NoOp(SIP return code : ${HASH(SIP_CAUSE,${CDR(dstchannel)})})
;"SIP 603 Out of capacity"
exten => s,n,GotoIf($["${HASH(SIP_CAUSE,${CDR(dstchannel)})}" = "SIP 603 Out of capacity"]?continue,1)
, где 603 Out of capacity - ошибка, возвращаемая провайдером в моем случае.
3. Делается dialplan reload из CLI asterisk.

Справедливости ради, отмечу, что идею обрабатывать ошибку подал-таки ded, за что ему большой респект, несмотря на мерзкие его манеры.
Фсем чмоке в этом чяте. ЛаФфКи, СиМпЫ и уСиПусЕчки по желанию.

На что только люди не идут, лишь бы не вникать в суть того что им пишут.

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

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

BorisTheBlade писал(а):На что только люди не идут, лишь бы не вникать в суть того что им пишут.
Найдите макрос macro-dialout-trunk в extensions или extensions_additional

Ненене. Это только часть решения, и как вы понимаете, не основная. Отловить ответ провайдера - вот в чем был затык. Но часть лавров законно достается и вам, извиняюсь, что забыл упомянуть. ВаМ тОжЕ сИмПа!

rusya писал(а):И снова здравствуйте, мои дорогие напыщенные мастера солдатского юмора и поклонники творчества Евгения Вагановича.
Opzione numero due:
Почему вы не поведали мне о волшебных свойствах переменной SIP_CAUSE? и вынудили нагенерить несколько страниц изысканий? Забыли, не знали, аль "кабута спицальна"? Но, опять-таки, мир не без добрых забугорных людей

Ладно, в конечном итоге наиболее приемлемым для меня способом проблема, обозначенная в топике решается так:
1.Копируется макрос [macro-dialout-trunk] из файла extensions_additional.conf в файл extensions_override_freepbx.conf
2. После строчки exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM},300,${DIAL_TRUNK_OPTIONS})
втыкаем наше
exten => s,n,NoOp(SIP return code : ${HASH(SIP_CAUSE,${CDR(dstchannel)})})
;"SIP 603 Out of capacity"
exten => s,n,GotoIf($["${HASH(SIP_CAUSE,${CDR(dstchannel)})}" = "SIP 603 Out of capacity"]?continue,1)
, где 603 Out of capacity - ошибка, возвращаемая провайдером в моем случае.
3. Делается dialplan reload из CLI asterisk.

Справедливости ради, отмечу, что идею обрабатывать ошибку подал-таки ded, за что ему большой респект, несмотря на мерзкие его манеры.
Фсем чмоке в этом чяте. ЛаФфКи, СиМпЫ и уСиПусЕчки по желанию.

Подскажите а в Freepbx 14 нынче как правильно это прописать?