@ded К сожалению, в данном случае у меня нет особого выбора и я вынужден выключить qualify на этом транке, хочу я этого или нет.
yannails ( 2018-09-11 15:08:37 +0400 )редактироватьДобрый день,
Хочу включить на peer параметр qualify=yes, но на мои OPTIONS запросы провайдер отвечает: SIP/2.0 403 Forbidden
Техподдержка говорит что в OPTIONS запросе в поле "To" отсутствует username:
To: <sip:xxx.xxx.xxx.xxx>
вместо To: <sip:username@xxx.xxx.xxx.xxx>
Крутил все параметры что только можно было, * не подставляет username, при этом поле "To" в запросе REGISTER содержит username, кто знает какой параметр за это отвечает?
[trunk1]
fromuser=487xxxxxx
defaultuser=487xxxxxx
secret=xxxxxxxxx
context=incoming
callbackextension=487xxxxxx
type=peer
host=yyy.yyy.yyy.yyy
fromdomain=yyy.yyy.yyy.yyy
insecure=invite,port
nat=force_rport,comedia
directmedia=no
qualify=yes
diallow=all
allow=ulaw,alaw,g729,g723
dtmfmode=rfc2833
10:43:18.383479 IP (tos 0x60, ttl 64, id 57120, offset 0, flags [none], proto UDP (17), length 566)
xxx.xxx.xxx.xxx:5060 > yyy.yyy.yyy.yyy:5060: SIP, length: 538
OPTIONS sip:yyy.yyy.yyy.yyy SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK2f3a3cfa
Max-Forwards: 70
From: "asterisk" <sip:487xxxxxx@xxx.xxx.xxx.xxx:5060>;tag=as091ea533
To: <sip:yyy.yyy.yyy.yyy>
Contact: <sip:487xxxxxx@xxx.xxx.xxx.xx:5060>
Call-ID: 481d254234f5c0b95f9fadbc3d7506fe@xxx.xxx.xxx.xxx:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk
Date: Tue, 07 Aug 2018 07:43:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
10:43:18.387661 IP (tos 0x0, ttl 59, id 20380, offset 0, flags [DF], proto UDP (17), length 387)
yyy.yyy.yyy.yyy:5060 > xxx.xxx.xxx.xxx:5060: SIP, length: 359
SIP/2.0 403 Forbidden
Call-ID: 481d254234f5c0b95f9fadbc3d7506fe@xxx.xxx.xxx.xxx:5060
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK2f3a3cfa
From: "asterisk" <sip:487xxxxxx@xxx.xxx.xxx.xxx:5060>;tag=as091ea533
To: <sip:yyy.yyy.yyy.yyy>
CSeq: 102 OPTIONS
Max-Forwards: 70
Content-Length: 0
Не используйте qualify для этого пира. Это ничего не даёт вам для функциональности, только проблемы. Если бы это был клиентский пир за НАТом, тогда qualify=yes, пакеты OPTIONS имели бы смысл, поддерживать трансляцию через верхние порты НАТообразующего устройства на стороне клиента.
В данном случае - сервер провайдера не за НАТ, его надёжность (MTBF) a priori выше, чем у вашего Астериска. Поэтому никакого смысла бомбардировать его пакетами OPTIONS нету.
Но, судя по ответам, вы не воспользуетесь этой рекомендацией.
@ded К сожалению, в данном случае у меня нет особого выбора и я вынужден выключить qualify на этом транке, хочу я этого или нет.
yannails ( 2018-09-11 15:08:37 +0400 )редактироватьЗадан: 2018-08-07 12:08:10 +0400
Просмотрен: 688 раз
Обновлен: Aug 20 '18
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
Простите, а чем вас не устраивает текущий ответ? Провайдер отвечает? Отвечает. Все. Достаточно.
meral ( 2018-08-07 12:48:13 +0400 )редактироватьУдаленное оборудование пытается аутентифицировать пакет. Пусть отключат это или не используйте qualify .
zzuz ( 2018-08-07 12:48:38 +0400 )редактировать@meral При достижении критического количества неавторизованных запросов, провайдер на время блочит IP.
yannails ( 2018-08-07 16:23:45 +0400 )редактировать@zzuz Ваша рекомендация очень похожа на: Чтобы корова меньше ела и давала больше молока, ее нужно меньше кормить и больше доить.
У меня есть несколько пиров которые подставляют username и несколько которые неподставляют, причем на одном и том же сервере и с аналогичными конфигами. Вот я и задался вопросом какой механизм этого процесса.
yannails ( 2018-08-07 17:04:37 +0400 )редактироватьПосмотрите chan_sip.c , там расскажут.
zzuz ( 2018-08-07 17:09:17 +0400 )редактироватьВы можете поставить РЕЖЕ. Или отключить вообще qualify=no. В данном случае ваш провайдер неправ, они нарушают RFC. Никто не будет под них подстраиватся если они не циско.
meral ( 2018-08-08 23:25:07 +0400 )редактироватьПакет options не должен аутентифицироватся. Точка.
meral ( 2018-08-08 23:26:10 +0400 )редактировать@meral Я RFC конечно не читал, но учитывая что у * есть опция
auth_options_requests
возможно вы не совсем правы.
yannails ( 2018-08-09 00:12:14 +0400 )редактировать;auth_options_requests = yes ; Enabling this option will authenticate OPTIONS requests just like INVITE requests are. By default this option is disabled.
@meral Что-то я затупил и вместо коммента сам себе ответ написал, а потом грохнул вместе с вашей ремаркой. По поводу Cisco. Есть у нас такая контора www.smile-soft.com их решение и стоит у провайдера, кто знает может там и Cisco где-то в связке установлено :)
yannails ( 2018-08-09 00:25:16 +0400 )редактировать