David P
2020-Jan-15 15:33 UTC
[asterisk-users] Call disrupted...due to registration of third server?
We use Asterisk 14 to proxy calls between two servers, 10.0.0.192 to 10.0.0.228. But sometimes another of our servers becomes listed as a SIP agent, even though the server's IP address isn't part of our sip.conf, extensions.conf, nor any other config I know of. For example in the log snippet below, the source server experienced an SDP renegotiation in the middle of a call, and seemingly as a consequence Asterisk re-locked on the source and destination servers...but also registered third server 10.0.0.125. This seems to have broken the call to the desired destination server. [2020-01-14 18:08:25] VERBOSE[29350][C-00000006] res_rtp_asterisk.c: 0x7f40240322e0 -- Strict RTP switching source address to 10.0.0.228:42150 [2020-01-14 18:08:26] VERBOSE[29324][C-00000006] res_rtp_asterisk.c: 0x7f403c00c3b0 -- Strict RTP learning complete - Locking on source address 10.0.0.192:22522 [2020-01-14 18:08:26] VERBOSE[29350][C-00000006] res_rtp_asterisk.c: 0x7f40240322e0 -- Strict RTP learning complete - Locking on source address 10.0.0.228:42150 [2020-01-14 18:09:01] VERBOSE[1389] asterisk.c: Remote UNIX connection [2020-01-14 18:09:01] VERBOSE[29363] asterisk.c: Remote UNIX connection disconnected [2020-01-14 18:09:47] VERBOSE[1429] chan_sip.c: Registered SIP '1000' at 10.0.0.125:5060 [2020-01-14 18:09:47] VERBOSE[1429] chan_sip.c: Saved useragent "FreeSWITCH-mod_sofia/1.6.20~64bit" for peer 1000 Is my description accurate for this log snippet? How can we prevent the registration of third servers? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200115/fb09983d/attachment.html>
C.Maj
2020-Jan-15 15:55 UTC
[asterisk-users] Call disrupted...due to registration of third server?
On 2020-01-15 08:33, David P wrote:> We use Asterisk 14 to proxy calls between two servers, 10.0.0.192 toAsterisk 17 is the most recent major version, but I don't know if an upgrade will solve your problem.> 10.0.0.228. But sometimes another of our servers becomes listed as a SIP > agent, even though the server's IP address isn't part of our sip.conf, > extensions.conf, nor any other config I know of. For example in the log > snippet below, the source server experienced an SDP renegotiation in the > middle of a call, and seemingly as a consequence Asterisk re-locked on the > source and destination servers...but also registered third server > 10.0.0.125. This seems to have broken the call to the desired destination > server. > > [2020-01-14 18:08:25] VERBOSE[29350][C-00000006] res_rtp_asterisk.c: > 0x7f40240322e0 -- Strict RTP switching source address to 10.0.0.228:42150 > [2020-01-14 18:08:26] VERBOSE[29324][C-00000006] res_rtp_asterisk.c: > 0x7f403c00c3b0 -- Strict RTP learning complete - Locking on source address > 10.0.0.192:22522 > [2020-01-14 18:08:26] VERBOSE[29350][C-00000006] res_rtp_asterisk.c: > 0x7f40240322e0 -- Strict RTP learning complete - Locking on source address > 10.0.0.228:42150 > [2020-01-14 18:09:01] VERBOSE[1389] asterisk.c: Remote UNIX connection > [2020-01-14 18:09:01] VERBOSE[29363] asterisk.c: Remote UNIX connection > disconnected > [2020-01-14 18:09:47] VERBOSE[1429] chan_sip.c: Registered SIP '1000' at > 10.0.0.125:5060 > [2020-01-14 18:09:47] VERBOSE[1429] chan_sip.c: Saved useragent > "FreeSWITCH-mod_sofia/1.6.20~64bit" for peer 1000 > > Is my description accurate for this log snippet?Is user/account 1000 sharing the same password across all 3 systems ?> How can we prevent the registration of third servers?After changing passwords, you might try adding some iptables rules on .228 & .192 to reject SIP traffic from .125 Regards, -- 🤠 C. Maj, Technology Captain @ Penguin PBX Solutions 📞 USA Toll Free 1-833-PNGNPBX (1-833-764-6729) 🤙 International & SMS Texting +1.720.32.42.72.9 🐧 Visit on the World Wide Web at PENGUINPBX.COM
Apparently Analagous Threads
- dev.copy(postscript,...) generates a disrupted string
- Bug#793921: tftpd-hpa: IPv6 address cannonization breaks IPv4
- [Bug 93630] New: [NVE6] disrupted display, cannot switch VT, everything else still works, E[ PDISP] link training failed
- sip error logging
- availability of snapshots functionality via Python bindings