Changing device on one leg improves the audio recorded from another leg?
We had this bizarre experience today: A user on this device... Dell Latitude 5580 i7-7600U CPU Windows 10 Education OS 19042.685 ...made verto calls in which he heard clicks and pops every few 100ms from our virtual agent on another leg, and those audio defects also appear in the mp4 recording. When he then switched to this device *on the same desk* using the same network... Dell Latitude 5590 i5-8350U CPU Windows 10 Education OS 17763.1821 ...there were no audio defects. Playing audio from other sources on the problematic device revealed no problems with its speaker. At least one of the failed calls used srflx candidates, not any relaying. How could changing the device on leg A affect the audio recording that apparently comes from leg B? If it's relevant: - We use "jitterbuffer_msec=5p:100p" - xml_cdr logs for both legs show seemingly high values for some aspects like these... - <skip_packet_count>187</skip_packet_count> <jitter_packet_count>1620</jitter_packet_count>
On Friday 29 October 2021 at 02:26:15, David P wrote:
How could changing the device on leg A affect the audio recording that apparently comes from leg B?
Any chance the devices performed a codec re-negotiation when swapped over? I've seen (or heard) somethng very similar (although using Asterisk) when: - answering a call (audio is perfect) - placing the caller on hold (hold music is fine) - resuming the call (audio is essentially incomprehensible) note: no change in devices at all. It turned out that the "resume" after hold was re-negotiating the codec in the SDP. Antony. -- Python is executable pseudocode. Perl is executable line noise. Please reply to the list; please *don't* CC me.
participants (2)
-
Antony Stone
-
David P