I have three Asterisk servers hosting different SIP trunks: Server A, Server B, and Server C.
The client dialer uses WebRTC with JsSIP.
The dialer runs in two environments:
Web browser (Chrome
Electron desktop application
Current Behavior:
Server A → Works perfectly on both Web and Electron.
Server B → Works perfectly on both Web and Electron.
Server C → Electron app works with proper two-way audio, but the Web browser version has no audio (cannot hear the remote party).
Important Observations:
The same JsSIP dialer codebase is used for all servers.
The same SIP endpoints can successfully register and make calls.
On Server C, the call connects but the browser client cannot hear audio.
Electron client works normally with Server C.
Also in older version of chromim ~144. , audio works. since same webrtc works for other asterisk server, I am unable to say that the issues is with chrome version.
i have this below config for the endpoint. basic_endpoint
moh_suggest=default
context=from-extensions
inband_progress=no
rtp_timeout=10
message_context=textmessages
allow_subscribe=yes
subscribe_context=subscriptions
;direct_media=no
dtmf_mode=rfc4733
device_state_busy_at=1
disallow=all
transport=system-udp
allow=alaw,ulaw
ICE is the first step of determining the path for media to flow in WebRTC, so that should be checked to see what candidates were exchanged, what was chosen. After that is DTLS-SRTP for encryption.
Candidates show up in SDP, and the actual negotiations are visible in packet captures and can be decoded there to understand what actually happened.
You also never stated what version of Asterisk is in use.
I am using asterisk 20.16.0 and jssip version 3.10.4 Audio codecs offered include Opus, G722, PCMU, and PCMA.
all are on different servers without any interconnection between them. client are using the system from public netwrok. no i can t connect to the trunk to different server as they are ip restrcited and connected from p2p connection. i can hear the audio in asterisk recording though from both the remote party and jssip webrtc endpoint
@jcolp@Pooh I can share the SDP as well if required. I can see the packets arriving with webrtc:internals in browser. Older version browser and electron have no issue with audio flow.
i had this problem too with webrtc endpoints (our softphone is based on sip.js 0.21) with asterisk 20 + PJSIP, using chrome 145 (chrome 144 + pjsip was ok and chrome 145 + chan_sip was ok)
i found a fix customizing my pjsip endpoint
remove “webrtc=yes” if needed (it includes many other options such as bundle=yes)
add “bundle=no”
Maybe it is the same issue. it seems that chrome 145 does not like rtp and rtcp on the same port. i didn‘t dig further to see why exactly
I would love to understand more about your environment. Everything you’re suggesting (turning off webrtc, turning off bundle) are the exact opposite of what should be done for WebRTC clients. And your assessment:
does not like rtp and rtcp on the same port
If true, would break virtually all WebRTC installs (rtcp-mux was the first thing that Asterisk needed to implement to get WebRTC support implemented).
so webrtc=yes could override previous parameters you set up “before” the line webrtc=yes.
My webrtc softphone endpoint in pjsip (asterisk 20) is like that and i had to set bundle=no especially for chrome 145 : type = endpoint bundle=no ;important with chrome 145 rtcp_mux=yes transport = transport-wss aors = ... auth = .. context = ... disallow = all allow = alaw,ulaw,gsm callerid = ... rtp_symmetric = yes force_rport = yes rewrite_contact = yes direct_media = no media_use_received_transport = yes dtls_auto_generate_cert = no dtls_cert_file = ... dtls_private_key = ... dtls_setup = actpass dtls_verify = no ice_support = yes use_avpf = yes media_encryption = dtls identify_by=auth_username
without bundle=no my chrome 145 didn’t receive the sound from turn server (NB : i was doing turn only, no stun)
with bundle=no, i succesfully receive the rtp from my turn server.
This is not how PJSIP configuration works. The order of the configuration options does not matter.
That’s great that it solved a problem for you. I just want OP (and any others that come here looking for help) to know that what you are saying is most likely not helpful to them.
@sarojesignature: I’m glad this workaround worked for you. I’m confident that a future Chrome update will restore normal endpoint configuration—this isn’t the first time Chrome has introduced a bug in WebRTC…
@seanbright: In the end, despite all the respect I have for your work in the Asterisk community, it’s clear that your contribution to this thread has been negative and useless.
For your information—you may be too young or simply too forgetful to remember this—the pioneers who have been working with WebRTC and chan_sip for the past 10 years know perfectly well that browsers still handle SDP with bundle=no just fine, because there simply wasn’t any other way to do it before.