Тема: voipdp-server автостарт
В настройках устройства посмотрите настройки реле и сравните их со старым сервером. В web интерфейсе сравните отображаемое значение кода открывания, может быть оно не равно 66. Также нужно обратить внимание на то, есть ли какие-то звуки при попытке набора одной, нескольких цифр. И дальше мы можем посмотреть процесс открывания по логу wireshark, что приходит на asterisk, что приходи с asterisk на voip-dp server и что уходит на домофон.
если имеется ввиду
DTMF во время разговора (SIP Info) - галка не стоит в обоих серверах
сервер asterisk один и тот же
dtmfmode=rfc2833 в астериске
на обоих переделать в info?
Вряд ли поможет, раз на старом сервере работает. Нужно проверить, есть ли звук при разговоре в сторону домофона, rfc2833 использует порт звука. Если звука нет, проблема маршрутизации в сети от asterisk к voip-dp серверу по портам 40000-41000. Если звук в сторону домофона есть, то проблема в где-то еще.
из того, что заметил
на новом сервере SIP статус
“Режим: VoIP-DP Шлюз.
Состояние: Ожидание.
UDP asterisk.loc(10.0.0.36):5060”
а на старом
”Состояние: Подключен.”
при этом SIP регистрация обоих домофонов в астериске есть.
к чему этот статус относится - так и не понял.
в сервере voipdp включил sip debug - там иногда пролетает unauthorized
INVITE sip:21@asterisk.loc SIP/2.0
Via: SIP/2.0/UDP 10.0.0.155;rport;branch=z9hG4bK9928adf713f3208d3ac40c2a588e39f8
From: “domofon1” <sip:6040@asterisk.loc>;tag=259e032e8e6e38b7a552bf9f6022eaef
To: <sip:21@asterisk.loc>
Call-ID: 0336a1efa027d6742ffd2a497e42a86e
CSeq: 50 INVITE
Contact: “domofon1” <sip:6040@10.0.0.155>
Max-Forwards: 70
Allow: REGISTER, MESSAGE, INVITE, ACK, CANCEL, BYE, INFO, REFER
Content-Type: application/sdp
Content-Length: 289v=0
o=- 0 0 IN IP4 10.0.0.155
s=session
c=IN IP4 10.0.0.155
t=0 0
m=audio 10000 RTP/AVP 8 0 3 9 101
a=rtcp:10001 IN IP4 10.0.0.155
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv[23.08.23 19:21:17.695] [IPDP]: <- UDP 0.0.0.0:5757 send datagram to 10.0.0.250:5757
01030c0100000000000000000000000000000000000f000404040105010f
[23.08.23 19:21:17.695] [IPDP]: Device ‘0’ change state OutgoingCallRequire (Check an outgoing call)
[23.08.23 19:21:17.696] [IPDP]: Device ‘0’ is busy
[23.08.23 19:21:17.696] [SIP]: -> UDP 10.0.0.155:5060 recive datagram from 10.0.0.36:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.0.155;branch=z9hG4bK9928adf713f3208d3ac40c2a588e39f8;received=10.0.0.155;rport=5060
From: “domofon1” <sip:6040@asterisk.loc>;tag=259e032e8e6e38b7a552bf9f6022eaef
To: <sip:21@asterisk.loc>;tag=as5fc42bab
Call-ID: 0336a1efa027d6742ffd2a497e42a86e
CSeq: 50 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“58d99b20”
Content-Length: 0
для голоса по умолчанию 10000-20000 порты же?
во всяком случае на обоих серверах voipdp они стоят. астериск один и тот же
все устройства (сервера и домофоны) в одном сегменте сети. те работает без маршрутизации
Для голоса порт 5060 (Bind Port) или какой укажите, должен везде совпадать
10000-20000 это порты RTP, должны совпадать
Время регистрации у “клиента” должно быть меньше чем у “сервера”, и само время регистрации большое не ставьте.
на старом сервере порт стоит 5061 тк они живут вместе с asterisk
на новом 5060.
но bind port насколько я понимаю не важен. регистрацию просит клиент астериска, в данном случае voipdp сервер и он сообщает свой порт, на который asterisk потом шлет пакеты
время регистрации это Таймаут авторизации (сек.) 60 сек?
на астере не задавал - дефолт
всетаки, что означает на новом сервере
Режим: VoIP-DP Шлюз.
Состояние: Ожидание.
может в этом какая то причина?
В современной версии сервера в SIP должно быть ожидание, а в оборудовании подключен, возможно вы там это видели. Для дальнейшего решения вопроса в идеале нужен лог wireshаrk со стороны VoIP-DP сервера содержащий весь вызов и попытку открывания. Куски текстовых логов VoIP-DP сервера ни о чем не скажут. Предварительно может внести ясность ответ на вопрос, есть ли звук в обе стороны при разговоре.
Для Астера (например):
Registration Minimum Expiry = 30 # если у клиента меньше то будет это
Registration Maximum Expiry = 60 # если у клиента больше то будет это
дефолты могут сильно отличаться
У вас voip-dp server является клиентом для Астера, должен быть строго указа порт Астера по которому он обращается. Да, клиент сообщает свой порт, но чтоб ему это сделать надо сначала пройти регистрацию по установленному на Астере порту, который и требуется указать на клиенте.
Также у клиента требуется указать время регистрации укладывающееся в рамки установленные у Астера.
судя по диагностике обмен есть в обе стороны
но голоса не слышно
не понятно откуда вдруг 401 Unauthorized
оба сервера в одной сети
в шаблоне сеть разрешена
[domofon](!)
type=friend
host=dynamic
context=domofon
;qualify=yes
dtmfmode=rfc2833
hassip = yes
force_rport = no
nat = no
directmedia = nonat
disallow = all
allow = alaw
deny = 0.0.0.0/0
permit = 10.0.0.0/24,10.9.0.0/24,10.11.0.0/24,127.0.0.1
могу только текст обмена приложить. файлы прикреплять не дает
|INVITE sip:21@asterisk.loc SIP/2.0
10.0.0.155 10.0.0.36 |Via: SIP/2.0/UDP 10.0.0.155;rport;branch=z9hG4bKdf10
-+- -+-|9088e94a793389f49dd9cb34af72896633bc213d1180d59c359f26954f7
| INV (10.0.0.155) | |From: “domofon1” <sip:6040@asterisk.loc>;tag=5896633
16:01:47.638385 | audio 10000 (g711a) | |bc213d1180d59c359f26954f7
+0.000946 | -> | |To: <sip:21@asterisk.loc>
16:01:47.639331 | 401 Unauthorized | |Call-ID: 0ee7933ba49422f49c5b3409c064509d
+0.002889 | <- | |CSeq: 34 INVITE
16:01:47.642220 | ACK | |Contact: “domofon1” <sip:6040@10.0.0.155>
| -> |sdp |Max-Forwards: 70
+0.001193 | INV (10.0.0.155) | |Allow: REGISTER, MESSAGE, INVITE, ACK, CANCEL, BYE,
16:01:47.643413 | audio 10000 (g711a) | |INFO, REFER
+0.002131 | -> | |Content-Type: application/sdp
16:01:47.645544 | 100 Trying | |Content-Length: 289
| <- | |
+0.002238 | 200 (10.0.0.36) | |v=0
16:01:47.647782 | audio 28878 (g711a) | |o=- 0 0 IN IP4 10.0.0.155
+0.002506 | <- |3 9 101 |s=session
16:01:47.650288 | ACK |5 |c=IN IP4 10.0.0.155
| -> | |t=0 0
| RTP (g711a) 502 | |m=audio 10000 RTP/AVP 8 0 3 9 101
16:01:47.685027 |10000 -> 28878| |a=rtcp:10001 IN IP4 10.0.0.155
| RTP (g711a) 456 | |a=rtpmap:8 PCMA/8000
16:01:48.396997 |10000 <- 28878| |a=rtpmap:0 PCMU/8000
|RTP (telephone-event/8000) 15| |a=rtpmap:3 GSM/8000
+10.058560 |10000 <- 28878| |a=rtpmap:9 G722/8000
16:01:57.708848 | BYE | |a=rtpmap:101 telephone-event/8000
+0.254520 | -> | |a=fmtp:101 0-16
16:01:57.963368 | 200 OK | |a=sendrecv
| <- | |
Возможно ситуацию прояснит лог Ваершарка.
а куда его приложить?
может есть старая версия сервера? 3.5.24.25 под deb ?
Лог можно выслать нам на почту в контактах с указанием ссылки на эту тему и пояснениями (кто есть кто). В логе должен быть зафиксирован вызов который требуется проанализировать.
Касательно доставания из архивов старых версий, то дело это не благодарное, т.к. там будут какие-то ошибки, или недоработки, или еще что-то в этом духе, которые в будущем закрыли, но тут они будут, а значит будут и пляски с бубном уже из-за них, и вот это уже совсем плохо.
не понятно откуда вдруг 401 Unauthorized
Это обычный элемент в диалогах SIP. При запросах клиента Register или Invite сервер отвечает сначала 401 Unauthorized и с этим ответом присылает данные для авторизации. После чего клиент еще раз делает запрос с учетом присланных данных. В ответ получает 200OK в удачном случае или причину отказа.
По логам Wireshark. Идет двухсторонний обмен аудио RTP PCMA, порты и протокол соответствуют заявленным в SIP SDP. Попыток управления по DTMF нет, т.е. астериск их не отправлял по своей внутренней причине или их не отправлял клиент астериску.
Судя по тому, что не видно обмена с вызываемым клиентом, лог сделан со стороны Voip-DP сервера. Имеет смысл сделать такой же лог с другой стороны, чтобы сравнить. Возможно звук не доходит до астериск. Порты 5060 на обеих сторонах нормально функционируют, точно так же нужно обеспечить работу диапазона портов RTP.
В данном конкретном случае переключение на SIP info даст возможность открыть дверь, т.к. работает не портам RTP, а по SIP.
