You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I am not misinformed, DECT is limited to only some audio codecs like G.722 for wideband and G.726-32 for narrowband, which means the DECT base always transcodes when it uses the Opus Codec. This has unexpected results:
Yealink
(tested 85.0.20) The decoder in the Yealink supported all my tested bandwidths. Incoming calls can trigger wideband or narrowband through their SDP offer; to be more exact: the SDP format parameter (fmtp) maxplaybackrate=8000. Outgoing calls/audio are always wideband (SiLK-only Wideband; ToC 0x48) as the SDP answer from the remote party gets ignored. This behavior is in line with the RFC. Therefore, I did not report it. However, I did not even need to measure the latency; a great difference thanks to the Opus Codec was hearable!
Panasonic
(tested 01.002) The decoder in the Panasonic supported all my tested bandwidths. Incoming calls can trigger wideband or narrowband through their SDP offer; to be more exact: the SDP format parameter (fmtp) maxplaybackrate=8000. Outgoing calls/audio were CELT-only; probably not OPUS_APPLICATION_VOIP but OPUS_APPLICATION_RESTRICTED_LOWDELAY is configured as application, which is wrong. Although Opus is visible as enabled in the Web interface, it is not offered. Instead, via a configuration file, you have to set OPUS_BAND_TYPE_x="0" (for narrowband) or WIDEBAND_AUDIO_ENABLE="Y" (for wideband): Maintenance → Provisioning → File URL. If configured for narrowband, every SDP offer with maxplaybackrate higher than 8000 gets rejected with SIP status 488, which is wrong. On default, the Opus encoder stops to work with the second received call. In other words, the other party does no hear anything. In my Panasonic, I went for the ‘multi-number mode’ and this software bug was not heard again.
Snom
(tested 05.30) The decoder and encoder in the RTX8663 work for me only with ToC 0x48 (SiLK-only Wideband). With ToC 0xb8 (CELT-only Wideband), I got a buzzing noise in the background. With other configurations like Medium- and Narrowband, I got no audio at all. This behavior was reported …
Grandstream
(tested 1.0.15.6) The decoder shows limitations …
Conclusions
The following patch always produces SiLK-only WB, ensuring an RTX DECT base handles the received Opus Codec stream: rtx.patch. Looking at the number of issues (and I did not test Poly yet), I recommend limiting the audio codecs of such a DECT base to its native audio codecs (G.722 and G.726-32) and instead let a media-plane back-to-back user agent (B2BUA) in your network do the transcoding.
The text was updated successfully, but these errors were encountered:
traud
changed the title
Interoperability: RTX
Interoperability: DECT
Aug 17, 2021
Several SIP ↔︎ DECT bases exist on the market, and the latest ones allow the Opus Codec:
If I am not misinformed, DECT is limited to only some audio codecs like G.722 for wideband and G.726-32 for narrowband, which means the DECT base always transcodes when it uses the Opus Codec. This has unexpected results:
Yealink
(tested 85.0.20) The decoder in the Yealink supported all my tested bandwidths. Incoming calls can trigger wideband or narrowband through their SDP offer; to be more exact: the SDP format parameter (fmtp)
maxplaybackrate=8000
. Outgoing calls/audio are always wideband (SiLK-only Wideband; ToC 0x48) as the SDP answer from the remote party gets ignored. This behavior is in line with the RFC. Therefore, I did not report it. However, I did not even need to measure the latency; a great difference thanks to the Opus Codec was hearable!Panasonic
(tested 01.002) The decoder in the Panasonic supported all my tested bandwidths. Incoming calls can trigger wideband or narrowband through their SDP offer; to be more exact: the SDP format parameter (fmtp)
maxplaybackrate=8000
. Outgoing calls/audio were CELT-only; probably notOPUS_APPLICATION_VOIP
butOPUS_APPLICATION_RESTRICTED_LOWDELAY
is configured as application, which is wrong. Although Opus is visible as enabled in the Web interface, it is not offered. Instead, via a configuration file, you have to setOPUS_BAND_TYPE_x="0"
(for narrowband) orWIDEBAND_AUDIO_ENABLE="Y"
(for wideband): Maintenance → Provisioning → File URL. If configured for narrowband, every SDP offer withmaxplaybackrate
higher than 8000 gets rejected with SIP status 488, which is wrong. On default, the Opus encoder stops to work with the second received call. In other words, the other party does no hear anything. In my Panasonic, I went for the ‘multi-number mode’ and this software bug was not heard again.Snom
(tested 05.30) The decoder and encoder in the RTX8663 work for me only with ToC 0x48 (SiLK-only Wideband). With ToC 0xb8 (CELT-only Wideband), I got a buzzing noise in the background. With other configurations like Medium- and Narrowband, I got no audio at all. This behavior was reported …
Grandstream
(tested 1.0.15.6) The decoder shows limitations …
Conclusions
The following patch always produces SiLK-only WB, ensuring an RTX DECT base handles the received Opus Codec stream: rtx.patch. Looking at the number of issues (and I did not test Poly yet), I recommend limiting the audio codecs of such a DECT base to its native audio codecs (G.722 and G.726-32) and instead let a media-plane back-to-back user agent (B2BUA) in your network do the transcoding.
The text was updated successfully, but these errors were encountered: