Dmytro Bogovych
03c58c4572
G722Codec::info() reported an 8 kHz sample rate for its 16 kHz output (640 bytes of PCM per 20 ms frame, read as 40 ms at 8 kHz). AudioReceiver therefore fetched packets at half the rate they arrived, and the high-water trim discarded about 44% of every G.722 stream: 109 of 250 packets per 5 s, with the buffer at 360 ms instead of 100 ms. The 8 kHz figure is right for one thing: RFC 3551 keeps G.722's RTP clock at 8000. Codec::Info already had mTimestampUnit for that. G.722 now reports mSamplerate 16000 and mTimestampUnit 1/8000, and Codec::rtpClockRate() gives the clock rate. The uses of samplerate() that mean RTP time now use it: - the jitter statistics in AudioReceiver::add; - the timestamp-gap-to-milliseconds conversion in AudioReceiver; - AudioStream's transmit timestamp unit and increment (numerically unchanged for every codec, including G.722). PCM uses stay on samplerate(), so AudioStream now also feeds the G.722 encoder 16 kHz audio instead of 8 kHz. The factory still advertises G722/8000 in SDP, as it must; only its backwards comment is fixed. AudioReceiver::infoFor() also applied a "G729A silence" rule to payload type 9, which is G.722; G.729 is 18. It now applies to PT 18. Other fixed-frame payloads are timed proportionally, as AudioReceiver::add already does, so a 10 ms G.722 packet (half a 160-byte frame) counts as 10 ms, not 20. Measured in vq-core with 16 replayed calls (NISQA speech; G.722 from ffmpeg and pjmedia, G.711 controls of the same speech; 3 runs each, all identical): - G.722 packet drops: 44% -> 0; buffer 100 ms like G.711; no underruns; - Sevana MOS of every G.722 call now equals its G.711 control, normal and loud (with the previous code three calls read 4.45 against 4.25); - DeadAir-01 0.68-0.89 -> 0.01-0.27 (G.711: 0.00-0.14); SilentCall within 0.01 of G.711 for the ffmpeg-encoded calls (was 0.15-0.17 higher); - AmpClipping on loud calls 0.004/0.001, as G.711; the 0.02-0.03 seen after the codec swap alone came from the dropped packets; - G.711 results, packet counts, loss, jitter and audio durations unchanged. The transmit path (AudioStream) builds but was not exercised; vq-core only receives. Needs the vq_net change that computes jitter with rtpClockRate(). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RTPhone Platform
RTPhone is a comprehensive real-time communication (RTC) platform that provides a complete software stack for building VoIP/SIP-based communication applications. Developed by VoIP Objects (Sevana), RTPhone delivers production-ready voice communication capabilities with extensive codec support and cross-platform compatibility.
Overview
RTPhone serves as a static library (librtphone.a) that can be integrated into larger telephony and communication systems. It provides a JSON-based command interface for easy integration and control, making it suitable for building softphones, PBX systems, WebRTC gateways, and carrier-grade voice solutions.
Key Features
Audio Codec Support
RTPhone supports an extensive range of audio codecs:
Standard Codecs:
- G.711 (A-law/¼-law)
- G.722 (16kHz wideband)
- G.729
- GSM (Full Rate, Half Rate, Enhanced Full Rate)
- iLBC (20ms/30ms)
- ISAC (16kHz/32kHz)
Advanced Codecs:
- AMR-NB/AMR-WB (Adaptive Multi-Rate Narrowband/Wideband) - please be aware - there is no patents for AMR codecs usage included ! You should acquire them on your own.
- EVS (Enhanced Voice Services) - 3GPP's latest codec. Again - please be aware - there is no patents for EVS codec usage included ! You should acquire them on your own.
- Opus - Modern low-latency codec
- Speex (with acoustic echo cancellation)
Codec Features:
- Bandwidth-efficient and octet-aligned modes
- IuUP (Iu User Plane) protocol support for 3G networks
- Dynamic codec switching
- Packet loss concealment (PLC)
- Comfort noise generation (CNG)
Network & Protocol Support
SIP Features:
- Full SIP 2.0 implementation via reSIProcate
- Multiple transport protocols (UDP, TCP, TLS)
- Registration, authentication, and session management
- SIP MESSAGE, presence, and REFER support
Media Transport:
- RTP/RTCP for media streaming
- SRTP for secure media
- ICE for NAT traversal with STUN/TURN support
- WebRTC integration components
- IPv4 and IPv6 support
Cross-Platform Audio Support
- DirectSound/WMME (Windows)
- Core Audio (macOS/iOS)
- ALSA/PulseAudio (Linux)
- Oboe (Android) for low-latency audio
- PortAudio fallback support
Audio Quality Features
- 48kHz sample rate support
- Acoustic Echo Cancellation (AEC)
- Audio resampling and format conversion
- Multi-channel audio mixing
- Perceptual Voice Quality Assessment (PVQA)
Architecture
The platform is organized into several core modules:
- Engine/Agent: JSON-based command interface
- Engine/Endpoint: SIP user agent implementation
- Engine/Media: Audio codec management and processing
- Engine/Audio: Cross-platform audio I/O handling
- Engine/Helper: Utility functions (networking, logging, threading)
Supported Platforms
- Linux (x64, ARM/Raspberry Pi)
- Windows (32/64-bit)
- macOS
- Android (with Oboe integration)
- iOS
Building
RTPhone uses a CMake-based build system with cross-compilation support:
Linux
python3 build_linux.py
Android
python3 build_android.py
# or
./build_android.sh
Dependencies
- CMake 3.10+
- OpenSSL 1.1+
- Boost libraries
- Platform-specific audio libraries
Recent Updates
Recent development has focused on:
- AMR codec parsing and decoding improvements
- Octet-aligned mode fixes for AMR-WB
- RTP SSRC handling enhancements
- Build system optimizations
- Code modernization to C++20
Use Cases
RTPhone is good for building:
- VoIP softphones and mobile applications
- PBX and telephony server systems
- RTP proxies
- Carrier-grade voice communication platforms
- 3GPP/IMS-compliant systems
Security
RTPhone includes comprehensive security features:
- OpenSSL 1.1 integration for encryption
- TLS transport layer security
- SRTP media encryption
- Certificate management support
Integration
The platform provides a developer-friendly interface with:
- Event-driven architecture
- Comprehensive logging system
- Modern C++20 codebase
For detailed integration instructions and API documentation, please refer to the source code and header files in the /src/engine/ directory.
License
Our source code is licensed under the MPL license. Naturally, any third-party components we use are subject to their respective licenses.