-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interoperability: Snom #10
Comments
Snom fixed that issue just days after my report: 8.9.3.59… However, I cannot close this issue yet, because This does not happen, when you use |
I have to correct myself because those are not about sending but just asking the remote party what to send.
When you specify
When you specify just |
Snom added the Opus Codec for their Desk Phones in the year 2014. At that time RFC 7587 was not final and the Snom implementation based on a draft from 2012. Therefore, the
rtpmap
was notopus/48000/2
but without the channel:opus/48000
. Furthermore in the year 2012, thefmtp
parameter for the bandwidth was calledmaxcodedaudiobandwidth
and notmaxplaybackrate
.Recently, those issues got fixed. However, Snom Desk Phones still play choppy audio when the Opus Codec is negotiated and Asterisk transcodes from another audio format to Opus.
Snom uses
opus-wb
to send wideband audio (16000 kHz) andopus-nb
to send narrowband audio (8000 kHz). RFC 7587 Table 2 states that for 20 ms the RTP timestamp should be increased by 960 samples, always. However, Snom increases the timestamp byopus-nb
andopus-wb
.Snom does not only send but expects to receive such timestamps as well. Otherwise the audio is choppy. Asterisk increases by 960. In Asterisk, you can hot fix this by changing
res/res_rtp_asterisk.c:ast_rtp_raw_write
fromto
for
opus-wb
. Foropus-nb
, instead of 16, you go for 8. That gives clean audio with Snom Desk Phones and proves the correctness of this approach. In the year 2014, a similar mistake was done by CSipSimple.Currently, these software branches and head versions are affected:
Because Snom has to solve this software bug and I see no way to solve it from within Asterisk, I reported this to Snom. Here, I leave this issue report open until this interoperability issue is fixed by Snom.
The text was updated successfully, but these errors were encountered: