Asterisk 22.2.0: first 5 seconds of call = wavy/cracking audio (jssip + Tele2, works in 3CX)

Hello everyone — I’m seeing a consistent wavy / cracking distortion in the first ~5 seconds of every call using Asterisk 22.2.0Tele2 (no OPUS)jssip-3.10.0. After ~5s the audio is perfect. The same Tele2 account connected to 3CX has no issue.

Environment:

  • Server: Intel Xeon Gold 6132, 8 cores, 32 GB RAM

  • OS: CentOS 7.9 (kernel 3.10)

  • Asterisk: 22.2.0

  • Client: jssip-3.10.0

  • Provider: Tele2 (no OPUS)

I’ll attach my settings and a short recording/pcap of the first 10s. Anyone seen this? Likely codec/jitter/negotiation issue — suggestions appreciated.

Thanks!

pjsip.conf:

[transport-udp]

type=transport

protocol=udp

bind=[my server IP]:5060



[transport-wss]

type=transport

protocol=wss

bind=0.0.0.0:8089



[auth-userpass](!)

type=auth

auth_type=userpass



[aor-single-reg](!)

type=aor

max_contacts = 1

qualify_frequency=0



[registration](!)

type=registration

expiration=120

retry_interval=60

forbidden_retry_interval=120

fatal_retry_interval=300

max_retries=0 

auth_rejection_permanent=no



[identify](!)

type=identify



[endpoint](!)

type=endpoint

disallow=all

allow=alaw,ulaw

direct_media=no



[endpoint-out](endpoint)

transport=transport-udp

force_rport=yes

trust_id_inbound = no

send_pai = yes

send_rpid = no



[endpoint-web](endpoint)

transport=transport-wss

webrtc=yes

rtp_symmetric=yes

device_state_busy_at=1

dtls_auto_generate_cert=yes

ice_support=yes

rtcp_mux=yes

use_avpf=yes

media_encryption=dtls

disallow=all

allow=alaw,ulaw

asymmetric_rtp_codec=yes

use_ptime=yes

direct_media=no

force_rport=yes

rewrite_contact=yes 

rtp_timeout=60

100rel=yes



[[VOIP username]](auth-userpass)

username=[VOIP username]

password=[VOIP password]



[[VOIP username]](aor-single-reg)

contact=sip:[VOIP username]@voip.mobilistotele.tele2.lt:5060



[[VOIP username]](registration)

outbound_auth=[VOIP username]

server_uri=sip:voip.mobilistotele.tele2.lt:5060

client_uri=sip:[VOIP username]@voip.mobilistotele.tele2.lt



[[VOIP username]](endpoint-out)

context=[VOIP username]-routine

from_domain=voip.mobilistotele.tele2.lt

aors=[VOIP username]

outbound_auth=[VOIP username]

from_user=[VOIP username]



[[VOIP username]](identify)

endpoint=[VOIP username]

match_header=To: <sip:[VOIP username]@voip.mobilistotele.tele2.lt>



[[VOIP username]-web](endpoint-web)

auth=[VOIP username]-web

aors=[VOIP username]-web

context=[VOIP username]-routine



[[VOIP username]-web](aor-single-reg)

remove_existing=yes



[[VOIP username]-web](auth-userpass)

username=[VOIP username]-web

password=[Password]

extensions.conf:

[sub-set-jb]

exten => s,1,NoOp(Setting jitterbuffer on callee (B-leg) channel)

same  => n,Set(JITTERBUFFER(adaptive)=default)

same  => n,Return()



[[VOIP username]-routine]

exten => s,1,NoOp(Inbound call.)

same => n,Progress()

same => n,Set(DEVSTATE=${DEVICE_STATE(PJSIP/[VOIP username]-web)})

same => n,GotoIf($["${DEVSTATE}" = "BUSY"]?busy,1)

same => n,Dial(PJSIP/[VOIP username]-web,60)

same => n,Hangup()

exten => _+X.,1,Set(CALLERID(num)=[Phone number])

same => n,Set(CALLERID(name)=[Phone number])

same => n,Progress()



same => n,Dial(PJSIP/${EXTEN}@[VOIP username],60)

same => n,NoOp(Dial failed with status: ${DIALSTATUS})

same => n,Hangup()

exten => busy,1,NoOp(Endpoint is busy – returning 486)

same => n,Busy()

same => n,Hangup()

jssip connection:

var socket = new JsSIP.WebSocketInterface('wss://[Server address]:8089/ws');

var configuration = {

'uri'       : "sip:[VOIP username]-web@[Server address]",

'authorization_user': "[VOIP username]-web",

'password'  : '[VOIP password]',

'contact_uri'  : "sip:[VOIP username]-web@[Server address]",

'sockets'   : [ socket ],

'pcConfig': {

'iceServers': [

                        { 'urls': 'stun:stun.l.google.com:19302' },

                        { 'urls': 'stun:stun.stunprotocol.org:3478' },

                        { 'urls': 'stun:stun.nextcloud.com:3478' },

                        { 'urls': 'stun:stun.relay.metered.ca:80' },

                        {

urls: "turn:global.relay.metered.ca:80",

username: "[username]",

credential: "[password]",

                        },

                        {

urls: "turn:global.relay.metered.ca:80?transport=tcp",

username: "[username]",

credential: "[password]",

                        },

                        {

urls: "turn:global.relay.metered.ca:443",

username: "[username]",

credential: "[password]",

                        },

                        {

urls: "turns:global.relay.metered.ca:443?transport=tcp",

username: "[username]",

credential: "[password]",

                        },

                    ]

            }

        };



var remoteAudio = document.getElementById("remoteAudio");

var ringtoneAudio = document.getElementById("ringtone");

remoteAudio.autoplay = true;



var callOptions = {

mediaConstraints: {audio: true, video: false},

mediaConstraints: {

audio: {

autoGainControl: false,

echoCancellation: true,

noiseSuppression: true

                },

video: false

            },

rtcOfferConstraints: {

offerToReceiveAudio: true,

offerToReceiveVideo: false

            }

        };



var phone;



if(configuration.uri && configuration.password){



JsSIP.debug.enable('JsSIP:*');



phone = new JsSIP.UA(configuration);

call_records.zip (19.8 KB)

Does it work correctly on another version of Asterisk?

I think you need to capture the RTP, with tcpdump, and analyze it with wireshark. You haven’t provided much information about the RTP, but this sounds like an RTP issue.

Please confirm that sub-set-jb is not used (I wouldn’t expect a jitter buffer to be needed for SIP to SIP).

Have you tried it without early media?

In which direction is the audio bad?

To expand on this I would narrow down the issue itself. If the Tele2 leg, for example, is perfectly fine then you’ve isolated it to the WebRTC component.

Hello everyone, thank you for the guidance. I have captured the RTP streams and PJSIP logs for the problematic calls.

  1. RTP Analysis (Wireshark)

    I see significant timing issues on the leg between Asterisk and the Provider. Specifically, Max Delta spikes to over 115ms during the initial seconds.

    Stream Direction Payload Max Delta Max Jitter
    [CLIENT] → Asterisk Opus (111) 52.6ms 409824 (Skewed)
    Asterisk → [PROV] PCMA (8) 115.6ms 12.8ms
  2. Asterisk Logs
    During the first 5 seconds (specifically during the 183 Session Progress phase), the console reports repeated timing resets:

    [2026-01-29 11:27:38] VERBOSE[8430][C-00000196] res_rtp_asterisk.c: Got RTP packet from [CLIENT_IP] (type 111, seq 009944, ts 1510536523)
    [2026-01-29 11:27:38] VERBOSE[8430][C-00000196] res_rtp_asterisk.c: Sent RTP packet to [PROV_IP] (type 08, seq 017306, ts 000848)
    [2026-01-29 11:27:38] VERBOSE[8430][C-00000196] res_rtp_asterisk.c: Got RTP packet from [PROV_IP] (type 08, seq 042363, ts 000960)
    [2026-01-29 11:27:38] VERBOSE[8430][C-00000196] res_rtp_asterisk.c: (0x7f62c81a5730) RTP audio difference is 1616 set mark

It appears Asterisk is transcoding between Opus (48kHz) on the WebRTC side and PCMA (8kHz) on the Tele2 side.

Client Leg SDP (WebRTC): m=audio 12602 UDP/TLS/RTP/SAVPF 111 8 0 a=rtpmap:111 opus/48000/2

Provider Leg SDP (Tele2): m=audio 32582 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000