[SR-Users] Re: [EXTERNAL] Fwd: rtpengine timestamp jumps
On 24/05/2024 15.34, Jeff Brower wrote: Hi Richard- Thanks very much for your reply. Please allow me to answer in reverse order - first in the Wireshark screencap (see link below) the two red arrows are pointing at media packets, not SID. The sequence number advances by 1 but the RTP timestamp advances 640 (should be 320 for AMR-WB). Second, the stream is not transcoded, but I'm trying to narrow down whether there may be "rate correction" happening, and if so where it's occurring. The carrier says they are not sending media packets with non-matching sequence number and RTP timestamp increments, at least not on a regular basis (i.e. 10 to 15% of a 2 hour call). If there's no transcoding then it's certainly not rtpengine manipulating either sequence numbers or timestamps. Both of these values are passthrough in non-transcoding cases. Your assumption that RTP timestamp advances must match sequence number advances might be flawed. Sequence numbers should match the sequence of packets, and timestamps should match the times. DTX in particular allows for "gaps" in the timestamp series while not having gaps in the sequencing (as the packets are still in order). AMR is a codec which explicitly allows and supports DTX as a feature. Under DTX it is perfectly allowable to have the sequence number increase by 1 while the timestamp increases by 640 or 960 or 1280 or 2560 or any other non-ptime amount, as long as the actual real timing of the packets (roughly) lines up with the timestamps. Generally the RTP marker bit should be set after one such event to signify that the RTP clock should be resynchronised, and this is what your pcap shows. But again this is not something that rtpengine has anything to do with. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Fwd: rtpengine timestamp jumps
I don't know if my original reply to this went through to the list or not, so I'm sending it again: Is this stream actually produced by rtpengine (i.e. from transcoding) or just a relay? Because this looks like just regular DTX behaviour from a normal AMR sender, i.e. send a SID frame and then not transmit anything for up to 200 ms or so. Rtpengine itself doesn't produce DTX streams. Cheers On 21/05/2024 12.45, Jeff Brower via sr-users wrote: Rtpengine support- I am re-posting again, as I noticed on the SR-USERs web page no HTML or inline images are showing (https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/latest?count=200). The Wireshark screencap that demonstrates the issue is uploaded at: https://www.signalogic.com/images/rtpengine_wireshark_capture_timestamp_jump.png all other info remains the same. Thanks, Jeff - Forwarded message from Jeff Brower - Date: Fri, 17 May 2024 17:10:10 + From: Jeff Brower Subject: Fwd: [SR-Users] rtpengine timestamp jumps To: sr-users@lists.kamailio.org Reposting this. If there is an issue with HTML format and/or wireshark screen cap and I need to upload that separately somewhere else, please let me know. Thanks. -Jeff - Forwarded message from Jeff Brower - Date: Thu, 09 May 2024 05:32:27 + From: Jeff Brower Subject: [SR-Users] rtpengine timestamp jumps To: sr-users@lists.kamailio.org Hi rtpengine experts, We have some customers processing long multi-party call pcaps using mediaMin who are reporting large amounts of packets with timestamp jumps but no packet loss (for instance 10% of packets over a 1 hr 45 min call). For example, in the Wireshark excerpt shown below, packets 6 and 8 sent by rtpengine show a timestamp increment of 640, but sequence number increment of 1: [screencap link at https://www.signalogic.com/images/wireshark_capture_timestamp_jump.png] In the mediaMin output packet log we typically see sections similar to: : : Seq num 98584 timestamp = 3902252372, rtp pyld len = 33 media-R Seq num 98585 timestamp = 3902252692, rtp pyld len = 33 media Seq num 98586 timestamp = 3902253012, rtp pyld len = 33 media-R Seq num 98587 timestamp = 3902253332, rtp pyld len = 33 media Seq num 98588 timestamp = 3902253652, rtp pyld len = 33 media-R Seq num 98589 timestamp = 3902253972, rtp pyld len = 33 media Seq num 98590 timestamp = 3902254292, rtp pyld len = 33 media Seq num 98591 timestamp = 3902254612, rtp pyld len = 33 media-R Seq num 98592 timestamp = 3902254932, rtp pyld len = 33 media Seq num 98593 timestamp = 3902255252, rtp pyld len = 33 media Seq num 98594 timestamp = 3902255572, rtp pyld len = 33 media-R Seq num 98595 timestamp = 3902255892, rtp pyld len = 33 media Seq num 98596 timestamp = 3902256212, rtp pyld len = 33 media Seq num 98597 timestamp = 3902256532, rtp pyld len = 33 media Seq num 98598 timestamp = 3902256852, rtp pyld len = 33 media-R Seq num 98599 timestamp = 3902257172, rtp pyld len = 33 media Seq num 98600 timestamp = 3902257492, rtp pyld len = 33 media-R Seq num 98601 timestamp = 3902257812, rtp pyld len = 33 media Seq num 98602 timestamp = 3902258132, rtp pyld len = 33 media Seq num 98603 timestamp = 3902258452, rtp pyld len = 33 media Seq num 98604 timestamp = 3902258772, rtp pyld len = 33 media-R Seq num 98605 timestamp = 3902259092, rtp pyld len = 33 media : : where media-R packets are timestamp gap repairs (i.e. frame loss concealment). The behavior tends to be bursty, but once it gets going it goes for a while and seems relatively consistent. Is this expected behavior for rtpengine ? If so is rptengine in turn dealing with some type of "slow packet rate" issue from a remote sender ? Thanks, Jeff - End forwarded message - - End forwarded message - __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio and RTPengine and no voice on calls
On 10/05/2024 04.49, palany wrote: Thank you Richard. I have changed my rtpengine.conf as per your instruction and now sdp m is now showing the correct ip but the o is still showing the private ip as below. The o= line is not relevant for the media flow, but you can add `replace-origin` to your signalling flags to also replace it. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio and RTPengine and no voice on calls
On 09/05/2024 10.16, palany via sr-users wrote: I have an AWS ec2 instance with Kamailio and rtpengine configured. I am having a challenge of no voice on calls. I have sip client on my mobile phone and soft phone on my laptop and the two are on different networks behind nat. Signaling is working fine but there is no media and when I check on on the SDP the call logs are showing private ips instead of public ips : o=- 3 2 IN IP4 192.168.1.33 and c=IN IP4 172.31.36.50. I understand this is a NAT issue but I am failing to see where is the challenge. My rtpengine seems to be working fine . Most likely you need to use the "advertised address" notation in your interface config as on AWS generally you don't have the public IP address bound on a local interface. So something like interface = external/172.31.36.50!13.246.88.123;internal/172.31.36.50 Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
On 10/04/2024 17.46, David Cunningham wrote: I was asking whether OpenSSL was used because of a question we had about FIPS validation. FIPS requires that all cryptography components go through a validation process, which some versions of OpenSSL (but not all) have done. My understanding is that RTPengine uses OpenSSL for the AES, but not for all of the key functions. Is that right? If so then even if we're using a FIPS validated version of OpenSSL, not all of the cryptography components of RTPengine would be using it, so we wouldn't be fully FIPS validated. DTLS is entirely provided by OpenSSL, except for the raw network I/O. Once the DTLS handshake completes, the SRTP keys are extracted out of OpenSSL. The cipher implementation (AES) as well as the digest implementation (SHA-1) are provided by OpenSSL. For AEAD-GCM, the entire encryption, decryption, and authentication process is handled by OpenSSL. For the other cipher suites (AES-CM, AES-F8), OpenSSL is used to create the block key via AES, and then rtpengine has its own implementation of the counter-mode cipher to apply the AES key to the SRTP payload. This is because SRTP uses a peculiar version of AES-CM that OpenSSL doesn't directly support. (This really isn't much more than XOR'ing the AES key onto the SRTP payload and so isn't really doing much cryptography.) For SRTP in the kernel module, it's more or less exactly the same, except that the kernel's crypto API is used instead of OpenSSL. (DTLS is done in userspace only.) Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
On 09/04/2024 23.14, Alex Balashov via sr-users wrote: Exchanging keys directly in the SDP body is rather suboptimal from a security standpoint, even if the signalling is encrypted, but it's certainly simpler. I suppose that makes DTLS "more secure", but in every other sense, I'm not sure DTLS is "better". W3C WebRTC standards mandate DTLS-SRTP, as far as I know, so I suppose it's more fit for that purpose. To add to that, one benefit DTLS has over SDES is that key exchange can happen as soon as media can flow, which theoretically can be immediately after the initial offer (invite), especially if ICE is also in use, as is the case with WebRTC. Whereas with SDES, since key exchange happens in-line with the signalling, key exchange can only be completed once an answer to the initial offer has been received. Which means that at least in theory DTLS is faster to establish media than SDES is. (Caveat: Not all DTLS clients actually allow this.) As for security: The most commonly used SRTP key types that can be exchanged are the same between SDES and DTLS, so in this aspect neither is more secure than the other. As for key exchange itself, DTLS is more sophisticated as it uses a peer-to-peer (with rtpengine being one of the peers in your case) public-key exchange to set up SRTP, whereas SDES relies on the signalling transport to be encrypted, which almost certainly isn't the case peer-to-peer (i.e. any involved signalling gateway or proxy can inspect or possibly modify the keys). In theory DTLS also allows extra trust to be established via verification of the DTLS certificates, but in practice this isn't usually done as the certificates are often self-signed. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: [EXTERNAL] Kamailio with rtpengine for RTP encryption/decryption
On 09/04/2024 17.40, David Cunningham via sr-users wrote: How does rtpengine get the TLS certificates, and what crypto library does it use (openssl?). SRTP itself doesn't use any certificates, and is not TLS. The underlying cipher (AES) is provided by OpenSSL, while the SRTP implementation itself is its own. TLS and certificates are relevant when it comes to the key exchange. With SDES, keys are exchanged in-line and nothing else is needed. The other option is DTLS: Here a self-signed certificate is used (generated at startup), and keys are exchanged using the DTLS implementation provided by OpenSSL. The certificate's fingerprint is exchanged in-line and that's how the peer's certificate is verified. After the key exchange completes, the SRTP keys are extracted from the handshake, DTLS is done, and the rest is just regular SRTP. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Standard on RTP ports
On 15/12/2023 14.04, [EXT] Calvin E. via sr-users wrote: Probably this: https://github.com/sipwise/rtpengine/blob/master/debian/changelog ngcp-rtpengine (12.1.0.0+0~mr12.1.0.0) unstable; urgency=medium * [2fa121c] MT#54294 add GPU support * [b3544be] MT#54294 packaging for rtpengine-gpu * [079bfac] MT#55283 fix up pkg generator for -gpu packages I'm guessing this uses underlying FFmpeg CUDA support. It's a bit more complicated than this as ffmpeg doesn't have GPU support for audio processing. So we took the Opus codec, ported it to CUDA, heavily modified it for parallel execution, and combined it with some other codecs (G.711 for now) to be able to do transcoding on a GPU. This isn't relevant for the regular media proxy (RTP passthrough) use case though. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Sharing load between rtpengine servers
On 08/11/2023 15.33, [EXT] David Cunningham via sr-users wrote: Hello, We have a Kamailio configuration with the following, however all the load is going to the server at 22.22.22.22 (hiding the real IP obviously) instead of being shared evenly between 22.22.22.22 and 33.33.33.33. Can anyone please tell me why? The rtpengine server at 11.11.11.11 is intended to only receive calls if the other two are offline. Thank you very much. #!define RTPENGINE_ADDR "udp:11.11.11.11:7724=1 udp:22.22.22.22:7724= udp:33.33.33.33:7724=" modparam( "rtpengine", "rtpengine_sock", RTPENGINE_ADDR ) I recall this was discussed on the mailing list before, but of course I can't find the relevant thread. What happens is that for legacy reasons (read: I don't really know why), if the default hashing algorithm (simple hash over call ID) is used, then the resulting weight is capped at 255. That means that no proxies beyond an accumulated weight of 255 will ever be used. So either keep the sum of your weights below that, or use a different hashing algorithm (CRC or SHA-1). Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: UDP Fragmentation webRTC/UDP Call
On 14/10/2023 02.46, [EXT] Karsten Horsmann via sr-users wrote: Hi, did you pass over the ice stuff from webrtc to the udp side? You could strip that of with rtpengine options. With recent versions we even have explicit SDP manipulations options, so you can use rtpengine to strip attributes that it itself doesn't understand or process. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Wrong RTP endpoint announced by Kamailio when forwarding calls, but looks correct from RTPEngine
On 12/10/2023 09.02, [EXT] Leonardo Arena via sr-users wrote: I've opened the captured traffic with Wireshark and I've found out that Kamailio is actually forwarding the call with a double SDP header. ngrep was showing only a partial header. I think this happens because when forwarding the call I use rtpengine_offer() and not rtpengine_manage(). I've tried using rtpengine_manage() and I get only one SDP header but with the (wrong) private IP address. I've tried also rtpengine_delete() before rtpengine_offer() but there's always a double header. Ideas? Still digging.. Duplicated SDPs in combination with rtpengine are usually the result of manipulating the SDP multiple times, e.g. using sdpops first and then passing the SDP to rtpengine (or the other way around) without msg_apply_changes() in between, or perhaps invoking the rtpengine methods multiple times within the same script run. Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
[SR-Users] Re: Choose RTP port in routing script
On 26/09/2023 08.10, [EXT] Duarte Rocha via sr-users wrote: Hello all, I have my rtpengine configured to use ports 2 - 5 for RTP in rtpengine.conf. Now i want to able to select the port or the port range in a call by call basis. Is that possible? Not currently possible with rtpengine. There's only a single port range and it's not possible to choose a particular port. Why do you want to choose a particular port? Cheers __ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
