asterisk.ru

патамушта username, а не user
и при insecure=invite,port вообще авторизация не запрашивается при входящих с IP, который в host, причем не важно с какого порта
и перед permit должен быть deny, а не наоборот

Vlad1983 писал(а):патамушта username, а не user

описался, на самом деле username стоит.

Vlad1983 писал(а):и при insecure=invite,port вообще авторизация не запрашивается при входящих с IP, который в host, причем не важно с какого порта

я это понимаю, о чем вам и толкую. Убираешь invite,port должна быть попытка авторизации по username, а - нет.

Vlad1983 писал(а):и перед permit должен быть deny, а не наоборот

так стоит в веблице фрипбх, я знаю что должно быть наоборот, и оно-таки наоборот в sip_additional.conf перерисовывается как надо, deny - вверху.

> Убираешь invite,port должна быть попытка авторизации
астериск отправляет на входящий INVITE ответ SIP/401 ?
ты думаешь, что оператор будет авторизовывать свои инвайты на твоем астериске?

В субботу точно покажу. Не могу сейчас переписывать - народ работает. Кстати, нет ли способа выводить в консоль или лог сообщения только от интересующих пиров\ip?

ищем по моим сообщениям в этом форуме кучу раз уже писал как снять c помощью tcpdump
или тычем TAB после sip set debug и пытаемся догадаться по каким параметрам привязаться к IP или peer

Vlad1983 писал(а):ты думаешь, что оператор будет авторизовывать свои инвайты на твоем астериске?

Я только спросил, возможно или нет.

Вот смотри.
Есть много больше двух SIPтранков на провайдера. Секции описания транков во freepbx у всех одинаковые:

[276543]
insecure=invite,port
type=friend
permit=88.87.46.0/255.255.255.0
host=88.87.46.6
disallow=all
deny=0.0.0.0/0.0.0.0
context=from-trunk
allow=alaw

, транки различаются только заголовками ([276543]) и строкой register в области уникальный_юзернаме:уник_пароль@хост_провайдера/уник_DID

Когда приходит входящий звонок от провайдера, он цепляется к первому по списку транку с наименьшим заголовком [2711111] например, видит свой IP и в дальнейшем кидает все входящие звонки через него. Смотришь в тот же monast - видишь кучу входящих на номер 2711111 и ни одного на остальные, хотя они есть и прекрасно рулятся по did. Смотришь в cdr - видишь все звонки с одним и тем же номером CHANNEL - 2711111.
Таким образом, я нигде не могу использовать факт наличия\отсутствия входящего звонка для допустим ограничения количества звонков через транк. Как мне быть в этом случае?

Vlad1983 писал(а):ищем по моим сообщениям в этом форуме кучу раз уже писал как снять c помощью tcpdump
или тычем TAB после sip set debug и пытаемся догадаться по каким параметрам привязаться к IP или peer

Я умею читать и пользоваться табом.
И как все это выделять в каше сообщений от других звонков ?

1 Ставим будильник на 4 часа утра
2 Просыпаемся, доползаем до консоли CLI>
3 Делаем тестовый звонок
4 PROFIT!

ded писал(а):1 Ставим будильник на 4 часа утра
2 Просыпаемся, доползаем до консоли CLI>
3 Делаем тестовый звонок
4 PROFIT!

Именно похожим образом в настоящий момент все и происходит.
Учимся читать так как написано, а не так как хочется:

rusya писал(а):Кстати, нет ли способа выводить в консоль или лог сообщения только от интересующих пиров\ip?

Кстати - только вчера зарелизили эту уникальную возможность -
tcpdump -A -s0 host 88.87.46.6 and port 5060

а до вчерашнего дня ваще никак неможно было!