SIP/2.0 401 Unauthorized

[valmon]

Коллеги, есть пачка аккаунтов, одни работают прекрасно в одной сети с asterisk, другие отказываются регистрироваться, разница, они ходят по ipsec.

Код: выделить все

[2017-02-08 11:00:20] VERBOSE[444] chan_sip.c: Scheduling destruction of SIP dialog '2058791893-5060-2@BA.HH.BI.CA' in 32000 ms (Method: REGISTER)
[2017-02-08 11:00:22] VERBOSE[444] chan_sip.c:
<--- SIP read from UDP:10.77.18.20:5060 --->
REGISTER sip:10.0.15.2:5160 SIP/2.0
Via: SIP/2.0/UDP 10.77.18.20:5060;branch=z9hG4bK1888020423;rport
From: <sip:7157@10.0.15.2:5160>;tag=2063889987
To: <sip:7157@10.0.15.2:5160>
Call-ID: 2058791893-5060-2@BA.HH.BI.CA
CSeq: 3095 REGISTER
Contact: <sip:7157@10.77.18.20:5060>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B8296655C>"
Max-Forwards: 70
User-Agent: Grandstream GXP1610 1.0.2.27
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0

<------------->
[2017-02-08 11:00:22] VERBOSE[444] chan_sip.c: --- (13 headers 0 lines) ---
[2017-02-08 11:00:22] VERBOSE[444] chan_sip.c: Sending to 10.77.18.20:5060 (no NAT)
[2017-02-08 11:00:22] VERBOSE[444] chan_sip.c:
<--- Transmitting (no NAT) to 10.77.18.20:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.77.18.20:5060;branch=z9hG4bK1888020423;received=10.77.18.20;rport=5060
From: <sip:7157@10.0.15.2:5160>;tag=2063889987
To: <sip:7157@10.0.15.2:5160>;tag=as130a1868
Call-ID: 2058791893-5060-2@BA.HH.BI.CA
CSeq: 3095 REGISTER
Server: FPBX-13.0.190.11(13.11.2)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3fef4932"
Content-Length: 0

[april22]

LocalNet - ?

[ded]

Localnet определяет адресацию RTP - голоса, при установлении соединения, а тут - REGISTER.

Что происходит? Телефон 7157 с адреса 10.77.18.20 запрашивает на Астериск 10.0.15.2 регистрацию, Астериск отвечает - SIP/2.0 401 Unauthorized, регистрируйся, говорит, используя WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3fef4932"

Вот тут телефон 7157 должен посылать ещё один REGISTER с аутентификацией - дайджестом. Но - не посылает. Подозреваю, потому что до него не добегает пакет SIP/2.0 401 Unauthorized, потому что там стоит у вас no NAT:
Sending to 10.77.18.20:5060 (no NAT)
А скорее всего туннель криво настроен, там может быть и NAT. То есть между 10.0.15.2 и 10.77.18.20 должно быть два скачка, и на телефоне должен быть точно адрес 10.77.18.20, есть такое?

[valmon]

LocalNet - ?

LocalNet 10.0.15.0, но это уже другая история, сигналка ходит норм.

[valmon]

Вот и я про это, они без конца шлют REGISTER и SIP/2.0 401 Unauthorized, ната там нет, все маршрутизируется прозрачно, все ip реальные

[ded]

http://forums.grandstream.com/forums/in ... ic=31446.0

[virus_net]

Надо просто сдампать что получает и получает ли 10.77.18.20. Зеркало порта или тупо ноут с Zoiper и tcpdump/windump.
И многое сразу станет понятным.

[ded]

Я без дампа скажу: когда Астериск отвечает - SIP/2.0 401 Unauthorized, регистрируйся, говорит, используя WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3fef4932"
то он отвечает не с source IP addr 10.0.15.2 (или не с порта 5160), поэтому телефон этот пакет игнорирует.

[valmon]

Надо просто сдампать что получает и получает ли 10.77.18.20. Зеркало порта или тупо ноут с Zoiper и tcpdump/windump.
И многое сразу станет понятным.

Из железа, там только домашний роутер и аппарат.
Самое интересное, что до этого был другой asterisk и находился в другой сети и на другом порту, стандартном, все работало, само собой мы поменяли настройки ipsec. Нечего кардинально не менялось, может сам asterisk трафик не отправляет.

[valmon]

Я без дампа скажу: когда Астериск отвечает - SIP/2.0 401 Unauthorized, регистрируйся, говорит, используя WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3fef4932"
то он отвечает не с source IP addr 10.0.15.2 (или не с порта 5160), поэтому телефон этот пакет игнорирует.

Ну судя по tcpdump он отвечает с 5060, но в этом ли причина, все тоже самое работает внутри.