Description
NethVoice should update the bundled Janus Gateway component to a version that includes the fix from upstream PR:
meetecho/janus-gateway#3640
The PR fixes a one-way audio issue in the Janus SIP plugin that can occur after a call has been placed on hold for a long time, approximately 11+ minutes.
After the call is resumed, the remote party can still hear the Janus/WebRTC side, but the browser side no longer receives audio from the SIP peer. RTP packets still arrive at Janus, but they are discarded before reaching the WebRTC PeerConnection because srtp_protect rejects them with srtp_err_status_replay_old.
The upstream fix resets the RTP switching context sequence when media reception resumes after hold/unhold, preventing sequence number regression and avoiding SRTP replay protection errors.
Expected behavior
NethVoice should ship a Janus version that contains this upstream fix, so that calls resumed after long hold periods continue to have bidirectional audio.
Actual behavior
With the current Janus version, calls involving the SIP plugin may experience one-way audio after long hold periods.
Why this is needed
This issue affects real NethVoice usage scenarios involving:
- WebRTC clients using Janus
- SIP calls placed on hold for extended periods
- Calls resumed after RTP sequence number wrap or sequence regression conditions
Updating Janus to a version containing the upstream fix should prevent these one-way audio cases.
References
Acceptance criteria
- The Janus component used by NethVoice is updated to a version containing PR
meetecho/janus-gateway#3640.
- The updated package is available in the NethVoice build/repository.
- A WebRTC/SIP call placed on hold for more than 11 minutes and then resumed keeps bidirectional audio.
- No
srtp_err_status_replay_old errors are produced for the resumed SIP audio stream.
Components
NethVoice.
Description
NethVoice should update the bundled Janus Gateway component to a version that includes the fix from upstream PR:
meetecho/janus-gateway#3640
The PR fixes a one-way audio issue in the Janus SIP plugin that can occur after a call has been placed on hold for a long time, approximately 11+ minutes.
After the call is resumed, the remote party can still hear the Janus/WebRTC side, but the browser side no longer receives audio from the SIP peer. RTP packets still arrive at Janus, but they are discarded before reaching the WebRTC PeerConnection because
srtp_protectrejects them withsrtp_err_status_replay_old.The upstream fix resets the RTP switching context sequence when media reception resumes after hold/unhold, preventing sequence number regression and avoiding SRTP replay protection errors.
Expected behavior
NethVoice should ship a Janus version that contains this upstream fix, so that calls resumed after long hold periods continue to have bidirectional audio.
Actual behavior
With the current Janus version, calls involving the SIP plugin may experience one-way audio after long hold periods.
Why this is needed
This issue affects real NethVoice usage scenarios involving:
Updating Janus to a version containing the upstream fix should prevent these one-way audio cases.
References
fix(sip): fix one-way audio after long holdAcceptance criteria
meetecho/janus-gateway#3640.srtp_err_status_replay_olderrors are produced for the resumed SIP audio stream.Components
NethVoice.