Opened 4 years ago
Closed 4 years ago
#349 closed задача (fixed)
После обновления ПО платы VE-01 не проходят транзитные вызовы.
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | высокий | Milestone: | 1 очередь |
| Component: | VE-01 | Keywords: | |
| Cc: |
Description (last modified by )
После обновления ПО платы VE-01(Евпаторийские ВЭС) с ревизии 48 на ревизию 59, пользователь заметил, что "транзитные" вызовы, которые раньше проходили через плату VE-01(Евпаторийские ВЭС) теперь не проходят. Под "транзитными" понимаются вызовы к плате, от чужого пользователя, которые должны быть отправлены дальше в соответствии с Sip-маршрутом.
Нужно разобраться в чём причина изменений и помочь пользователю вернуть схему в рабочее состояние. Конфиг VE-01(Евпаторийские ВЭС) прилагаю.
Далее текст пользователя:
В эксперименте задействованы:
192.168.0.21 (плата VE-01, ревизия прошивка 48) - ЦУС
192.168.4.11 (плата VE-01, ревизия прошивка 59) - Евпаторийские ВЭС
192.168.0.31 (плата VE-01, ревизия прошивка 59) - п/с Кубанская
SIP-телефон 7544@192.168.0.29 зарегистрирован на плате VE-01 ЦУС (192.168.0.21).С этого телефона совершаем вызов на номер 5999. На плате VE-01 (192.168.0.21) нет SIP-пользователей и SIP-окончаний, способных обслужить этот вызов. В таблице маршрутизации платы VE-01 (192.168.0.21) имеется маршрут: ^sip:5999.* --> sip:5999@192.168.4.11
На плате VE-01 (192.168.4.11) также нет SIP-пользователей и SIP-окочаний, способных обслужить вызов 5999, но есть маршрут в таблице маршрутизации: ^sip:5999.* --> sip:5999@192.168.0.31
На плате VE-01 (192.168.0.31) есть SIP-окончание FXS 5999@192.168.0.31
Вызов не проходит с SIP телефона 7544@192.168.0.29 на FXS окончание 5999@192.168.0.31 через "транзитный" узел 192.168.4.11 (сопровождается сообщением "Набранный номер не существует")
Дамп получен в ОС "транзитной" платы VE-01 (192.168.4.11):
root@comcerto:~# tcpdump -v -s1514 port 5060 and host 192.168.4.11
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1514 bytes
12:03:00.742164 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 1168)
192.168.0.21.5060 > 192.168.4.11.5060: SIP, length: 1140
INVITE sip:5999@192.168.4.11 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK-524287-1---eeb2801256a91c08;rport
Via: SIP/2.0/UDP 192.168.0.29:52539;rport=52539;branch=z9hG4bKPjd194126f7e54477eabff60523bda82d1
Max-Forwards: 69
Record-Route: <sip:192.168.0.21:5060;transport=udp;lr>
Contact: <sip:7544@192.168.0.29:52539;ob>
To: <sip:5999@192.168.0.21>
From: <sip:7544@192.168.0.21>;tag=7f0a397cc2544a8d82580eaec8f589a2
Call-ID: 70cd2779001c400dbd24eed34469cb99
CSeq: 17170 INVITE
Session-Expires: 1800
Min-SE: 90
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Type: application/sdp
Date: Tue, 14 Apr 2020 11:48:35 GMT
Supported: replaces, 100rel, timer, norefersub
User-Agent: MicroSIP/3.19.28
Content-Length: 340
v=0
o=- 3795865194 3795865194 IN IP4 192.168.0.29
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4002 RTP/AVP 8 0 101
c=IN IP4 192.168.0.29
b=TIAS:64000
a=rtcp:4003 IN IP4 192.168.0.29
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:1464409486 cname:1589261a264b0376
12:03:00.770125 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 610)
192.168.4.11.5060 > 192.168.0.21.5060: SIP, length: 582
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK-524287-1---eeb2801256a91c08;rport=5060
Via: SIP/2.0/UDP 192.168.0.29:52539;rport=52539;branch=z9hG4bKPjd194126f7e54477eabff60523bda82d1
Proxy-Authenticate: Digest nonce="1586865780:e1ce292a69ec89a024cd57c247c5cfda",algorithm=MD5,realm="192.168.4.11",qop="auth,auth-int"
To: <sip:5999@192.168.0.21>;tag=d5c4e053
From: <sip:7544@192.168.0.21>;tag=7f0a397cc2544a8d82580eaec8f589a2
Call-ID: 70cd2779001c400dbd24eed34469cb99
CSeq: 17170 INVITE
Server: repro 1.10.2
Content-Length: 0
12:03:00.782067 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 357)
192.168.0.21.5060 > 192.168.4.11.5060: SIP, length: 329
ACK sip:5999@192.168.4.11 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK-524287-1---eeb2801256a91c08;rport
Max-Forwards: 70
To: <sip:5999@192.168.0.21>;tag=d5c4e053
From: <sip:7544@192.168.0.21>;tag=7f0a397cc2544a8d82580eaec8f589a2
Call-ID: 70cd2779001c400dbd24eed34469cb99
CSeq: 17170 ACK
Content-Length: 0
12:03:04.878069 IP (tos 0x0, ttl 62, id 52531, offset 0, flags [+], proto UDP (17), length 1500)
192.168.0.21.5060 > 192.168.4.11.5060: SIP, length: 1472
INVITE sip:5999@192.168.4.11 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK-524287-1---920d005e53e1d64e;rport
Via: SIP/2.0/TCP 172.18.10.225:59500;rport=59500;branch=z9hG4bKPj8fdbd56e48174b978856bc23ca61ef6c;received=192.168.0.29;alias
Max-Forwards: 69
Record-Route: <sip:192.168.0.21:5060;transport=udp;lr;drr>
Record-Route: <sip:192.168.0.21:5060;transport=tcp;lr;drr>
Contact: <sip:7544@192.168.0.29:52539;ob>
To: <sip:5999@192.168.0.21>
From: <sip:7544@192.168.0.21>;tag=7f0a397cc2544a8d82580eaec8f589a2
Call-ID: 70cd2779001c400dbd24eed34469cb99
CSeq: 17173 INVITE
Session-Expires: 1800
Min-SE: 90
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Type: application/sdp
Date: Tue, 14 Apr 2020 11:48:39 GMT
Proxy-Authorization: Digest username="7544",realm="192.168.4.11",nonce="1586865780:e1ce292a69ec89a024cd57c247c5cfda",uri="sip:5999@192.168.0.21",response="de13d176dafc5d09bb39b5e62e36ce5c",algorithm=MD5,cnonce="cc916dfd945543b9bfec2772eaa870d6",qop=auth,nc=00000001
Supported: replaces, 100rel, timer, norefersub
User-Agent: MicroSIP/3.19.28
Content-Length: 340
v=0
o=- 3795865194 3795865194 IN IP4 192.168.0.29
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4002 RTP/AVP 8 0 101
c=IN IP4 192.168.0.29
b=TIAS:64000
a=rtcp:4003 IN IP4 192.168.0.29
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00
12:03:04.893079 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 496)
192.168.4.11.5060 > 192.168.0.21.5060: SIP, length: 468
SIP/2.0 403 Authentication Failed
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK-524287-1---920d005e53e1d64e;rport=5060
Via: SIP/2.0/TCP 172.18.10.225:59500;rport=59500;branch=z9hG4bKPj8fdbd56e48174b978856bc23ca61ef6c;received=192.168.0.29;alias
To: <sip:5999@192.168.0.21>;tag=17c6bc66
From: <sip:7544@192.168.0.21>;tag=7f0a397cc2544a8d82580eaec8f589a2
Call-ID: 70cd2779001c400dbd24eed34469cb99
CSeq: 17173 INVITE
Server: repro 1.10.2
Content-Length: 0
12:03:04.912116 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 357)
192.168.0.21.5060 > 192.168.4.11.5060: SIP, length: 329
ACK sip:5999@192.168.4.11 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK-524287-1---920d005e53e1d64e;rport
Max-Forwards: 70
To: <sip:5999@192.168.0.21>;tag=17c6bc66
From: <sip:7544@192.168.0.21>;tag=7f0a397cc2544a8d82580eaec8f589a2
Call-ID: 70cd2779001c400dbd24eed34469cb99
CSeq: 17173 ACK
Content-Length: 0
7 packets captured
7 packets received by filter
0 packets dropped by kernel
Attachments (2)
Change History (13)
by , 4 years ago
| Attachment: | VEslot7.xml added |
|---|
comment:1 by , 4 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 4 years ago
comment:3 by , 4 years ago
Судя по приложенной трассировке, URI телефона все-таки 7544@192.168.0.21. Клиент, видимо, просто опечатался.
comment:4 by , 4 years ago
Насколько я вижу из приложенной трассировки, вызов заканчивается неудачей - VE-01 возвращает ответ "403 Authentication Failed".
Саша, уточни, пожалуйста, у клиента, а как было раньше (до обновления) - аутентификация проходила успешно, или она вообще не производилась?
comment:6 by , 4 years ago
7544@192.168.0.29
Видимо пользователь имел в виду адрес самого телефона, его контакт, при регистрации.
comment:7 by , 4 years ago
Replying to san:
Не производилась
В таком случае, на время разбирательства могу предложить попробовать такой workaround:
в /etc/repro.conf заменить строку
DisableAuth = false
на
DisableAuth = true
и перезагрузить плату. Правда в этом случае перестанут аутентифицироваться даже свои собственные пользователи.
follow-up: 9 comment:8 by , 4 years ago
Кстати, запроси, пожалуйста, еще и файл repro.conf - возможно, там какие-то изменения сделаны.
comment:9 by , 4 years ago
Replying to alx:
Кстати, запроси, пожалуйста, еще и файл repro.conf
Если еще не запрашивал, то и не надо уже. :)
by , 4 years ago
comment:10 by , 4 years ago
Пользователь провёл ещё аналогичный эксперимент на соседней "транзитной" плате VE-01 со старой прошивкой. Описание эксперимента и дамп приложил в файле в сообщении выше.
Это пример - аналог того, как работало на исследуемой плате до обновления.
Replying to san:
Тут какая-то путаница с организацией сети...
При создании пользователя на плате VE-01 пользователь получает домен, совпадающий с адресом IP платы. Например, при создании в плате VE-01 с адресом 192.168.0.21 пользователя с именем 7544 URI этого пользователя будет 7544@192.168.0.21. Даже если адрес платы по каким-то причинам меняется, при этом соответствующим образом меняются и домены всех SIP пользователей платы. Таким образом, домен в URI любого пользователя всегда совпадает с адресом IP.
В свете написанного выше непонятно, как телефон с URI 7544@192.168.0.29 мог быть зарегистрирован на плате VE-01 с адресом 192.168.0.21... Нет ли здесь какой-то ошибки?
Попроси, пожалуйста, разъяснений у клиента.