PJSIP calls are not working on WIFI network

I have configured the PJSIP extensions with webrtc and calls are working fine on all the cellular networks without problem and but Its been disconnecting on WIFI network.

I have check the console log but did not getting any errors!!!.

What does disconnecting actually mean? You’re going to need to provide more information.

Getting just below Notice and after this call has been disconnected.

res_pjsip_sdp_rtp.c:148 rtp_check_timeout: Disconnecting channel PJSIP for lack of audio RTP activity in 30 seconds

[7002]
type=endpoint
aors=7002
auth=7002-auth
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
disallow=all
allow=ulaw,h264
context=internal
callerid=7002 <7002>
webrtc=yes
dtmf_mode=rfc4733
direct_media=yes
aggregate_mwi=yes
use_avpf=yes
rtcp_mux=yes
max_audio_streams=1
max_video_streams=1
bundle=yes
ice_support=yes
media_use_received_transport=yes
trust_id_inbound=yes
user_eq_phone=no
send_connected_line=yes
media_encryption=dtls
timers=yes
timers_min_se=90
media_encryption_optimistic=no
refer_blind_progress=yes
refer_blind_progress=yes
rtp_timeout=30
rtp_timeout_hold=300
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
media_encryption=dtls
dtls_verify=fingerprint
dtls_setup=actpass
dtls_rekey=0
dtls_auto_generate_cert=yes

[7001]
type=endpoint
aors=7001
auth=7001-auth
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
disallow=all
allow=ulaw,h264
context=internal
callerid=7001 <7001>
webrtc=yes
dtmf_mode=rfc4733
direct_media=yes
aggregate_mwi=yes
use_avpf=yes
rtcp_mux=yes
max_audio_streams=1
max_video_streams=1
bundle=yes
ice_support=yes
media_use_received_transport=yes
trust_id_inbound=yes
user_eq_phone=no
send_connected_line=yes
media_encryption=dtls
timers=yes
timers_min_se=90
media_encryption_optimistic=no
refer_blind_progress=yes
refer_blind_progress=yes
rtp_timeout=30
rtp_timeout_hold=300
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
media_encryption=dtls
dtls_verify=fingerprint
dtls_setup=actpass
dtls_rekey=0
dtls_auto_generate_cert=yes

these are the configuration of extensions

You will need to examine the ICE negotiation then to see what candidates are exchanged, what IP addresses and ports are being tried, and confirm that there should be a viable path - and if not determine why not.

If you don’t have experience with ICE then you’re going to need to investigate and learn, because it is a foundational aspect of WebRTC and something you have to investigate when stuff like this goes wrong (which it will).

I wrote a blog post on the list of things to generally check when WebRTC goes wrong[1]. However you do need understanding of things to dig into it.

[1] https://www.asterisk.org/webrtc-asterisk-goes-wrong/

Okay will check it.

Am I need to update any parameter in the configuration or any settings for extensions?

If you needed to update any configuration for extensions to make this work, then it would need to be done to make it work in all cases.

I can’t comment on any other configuration.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.