![]() ![]() If wireshark could do stuff with SRTP packages, what could it possibly show other than that some packages either carry a damaged payload, or that the encryption keys don’t fit, which is something I already know? If the problem was with asterisk or libsrtp, the problem would be much more common. Maybe someone who is much more proficient with wireshark could find something. Hm, I tried that and wireshark doesn’t seem to like SRTP packages very much.Īpparently it doesn’t have a way to decrypt SRTP packages at all, even if IĬould get the initial keys. After learning all this, I’m sufficiently sure that the problem is on their side. So I’ve been trying to figure out what the problem might be. That defective hardware is causing the same problem at both places at the same time seems rather unlikely. Perhaps the VOIP provider is experiencing interesting NAT issues when their connection tracking is getting messed up at times when there are more connections than they can handle. My favorite theory is that I am sometimes suddenly receiving the wrong SRTP Right - or the SRTP package has been created incorrectly by their phone system because it is overloaded at busy times, or it’s buggy. Now that someone would intentionally alter the SRTP packages and re-calculate the checksums seems rather unlikely, all the more so since they would need to do that at two different places. ![]() Yes, I thought so, IIRC it’s required for routing and changing the TTL maybe. ![]() Two independent installations of asterisk at physically different locations are showing the same error messages, both connecting to the same VOIPĪs you can imagine, this is really fun to debug … The SRTP package seems to be the entire payload of the UDP package, so if the data of the SRTP package gets damaged or were to be intentionally altered, the UDP checksum would have to be intentionally re-calculated. Only when the package was thusly successfully authenticated, the RTP-payload of the package is decrypted. The receiver decrypts the authentication tag and verifies that the tag matches all the other data in the packet. The key exchange can go over SIP (using TLS) when sdes is used, which it is in this case. The authentication tag is encrpyted on the sender side after initially keys have been exchanged between sender and receiver from which new keys are being derived as needed. IIUC, authentication failures mean that libsrtp figures that the authentication tag of an SRTP package does not match the data contained otherwise within the packet. The interruption can take even minutes and the audio can continue after that, though usually I either hang up the call, or the calls ends by itself before the audio is back. The result is that the call is interrupted in that I can not hear the opposite end while the other end sometimes can still hear me, sometimes not. That can happen a couple times until asterisk reports authentication failures. The intervals appear to depend on the time of day: Such phone calls can last for a duration of about 5–25 minutes during the day to up to 1.5 hours at aroundĪsterisk says that a package is being replayed, meaning that libsrtp has already seen and processed the packet earlier. It is about VOIP calls via SRTP being interrupted at irregular intervals. “bandwidth” actually means, being involved in signal transmissions and I seem to remember that there was no checksumming involved and it had to do with identifying signals as a requirement for the very possibility to transmit something before anything could be transmitted at all. You mean layer 1 checksumming? Is there such a thing with ethernet? I think I read something about encoding, when I was trying to understand what libsrtp) finally verifies the authentication tag of an SRTP package against the authenticated part of the package - which, according to RFC 3711, seems to be the entire payload of the UPD package – do that? Why would the UDP checksums just happen to get recalculated correctly but like randomly without intent? Ok, I’ll assume I wouldn’t receive damaged packages.Īssuming that I do not receive packets with invalid UPD checksums, then the packages must be somehow altered and their UPD checksums recalculated to arrive here. But does this mean it’s on as in “rx-Ĭhecksumming: on” or off as in “tx-checksum-ipv4: off ”? Ok, I wouldn’t expect asterisk to disable checksumming by default.īoth physical interfaces show the same. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |