Dialing between web browser and soft phone

Hi
I am using PJSIP and have both type of phones i.e. Web Browsers 6003 as well as soft phones 6001 and 6002.
I am able to dial between soft phones and from web phone 6003 to soft-phones but when I call from soft phones to web browser call got hangup as we receive call on browser. Following are configurations.

[6001]
type=endpoint
context=supervisor
disallow=all
allow=ulaw
transport=transport-udp
;transport=transport-wss
auth=auth6001
aors=6001

[6003]
type=endpoint
aors=6003
auth=auth6003
;dtls_auto_generate_cert=yes
use_avpf=yes
transport=transport-wss
;transport=transport-udp
media_encryption=dtls
dtls_ca_file=/etc/asterisk/keys/ca.crt
dtls_cert_file=/etc/asterisk/keys/asterisk.pem
dtls_verify=fingerprint
dtls_setup=actpass
ice_support=yes
media_use_received_transport=yes
rtcp_mux=yes
context=supervisor
disallow=all
allow=opus
allow=ulaw

Please post the SIP trace of the erroneous call. Logging would also be useful. Here’s how to collect both at the same time if you’re not sure how: Collecting Debug Information

I analyze that when Web phone connects asterisk , asterisk sends SIP/2.0 401 Unauthorized. Following are registration logs

== WebSocket connection from ‘182.176.118.54:20867’ for protocol ‘sip’ accepted using version ‘13’
<— Received SIP request (524 bytes) from WSS:182.176.118.54:20867 —>
REGISTER sip:110.20.5.38 SIP/2.0
Via: SIP/2.0/WSS bdv55j4mqhm4.invalid;branch=z9hG4bK3347700
Max-Forwards: 70
To: sip:6004@110.20.5.38
From: sip:6004@110.20.5.38;tag=rkq5auhf4i
Call-ID: 22ung1uid9fnmpop1c0db2
CSeq: 6100 REGISTER
Contact: sip:7dinjgif@bdv55j4mqhm4.invalid;transport=ws;reg-id=1;+sip.instance=“urn:uuid:07aaf250-07e0-46ce-8a43-04971df57d1d”;expires=600
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: path, gruu, outbound
User-Agent: WebPhone/0.1.2
Content-Length: 0

<— Transmitting SIP response (464 bytes) to WSS:182.176.118.54:20867 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/WSS bdv55j4mqhm4.invalid;rport=20867;received=182.176.118.54;branch=z9hG4bK3347700
Call-ID: 22ung1uid9fnmpop1c0db2
From: sip:6004@110.20.5.38;tag=rkq5auhf4i
To: sip:6004@110.20.5.38;tag=z9hG4bK3347700
CSeq: 6100 REGISTER
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1543950476/ceadd44345aa6bb0a476478e968726e9”,opaque=“3b5fec582ce0f5aa”,algorithm=md5,qop=“auth”
Server: Asterisk PBX 13.22.0
Content-Length: 0

<— Received SIP request (788 bytes) from WSS:182.176.118.54:20867 —>
REGISTER sip:110.20.5.38 SIP/2.0
Via: SIP/2.0/WSS bdv55j4mqhm4.invalid;branch=z9hG4bK8640275
Max-Forwards: 70
To: sip:6004@110.20.5.38
From: sip:6004@110.20.5.38;tag=rkq5auhf4i
Call-ID: 22ung1uid9fnmpop1c0db2
CSeq: 6101 REGISTER
Authorization: Digest algorithm=MD5, username=“6004”, realm=“asterisk”, nonce=“1543950476/ceadd44345aa6bb0a476478e968726e9”, uri=“sip:110.20.5.38”, response=“8d87b110e5779116538ccbb8d4f12a29”, opaque=“3b5fec582ce0f5aa”, qop=auth, cnonce=“u9ibbvmt9kt9”, nc=00000001
Contact: sip:7dinjgif@bdv55j4mqhm4.invalid;transport=ws;reg-id=1;+sip.instance=“urn:uuid:07aaf250-07e0-46ce-8a43-04971df57d1d”;expires=600
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: path, gruu, outbound
User-Agent: WebPhone/0.1.2
Content-Length: 0

-- Added contact 'sip:7dinjgif@182.176.118.54:20867;transport=ws' to AOR '6004' with expiration of 600 seconds
-- Contact 6004/sip:7dinjgif@182.176.118.54:20867;transport=ws is now Unknown.

== Endpoint 6004 is now Reachable


Also following are call logs
== Setting global variable ‘SIPDOMAIN’ to ‘110.20.5.38’
– Executing [6004@supervisor:1] Answer(“PJSIP/6002-0000003b”, “”) in new stack
> 0x7f75d4029390 – Strict RTP learning after remote address set to: 182.176.118.54:4000
> 0x7f75d4029390 – Strict RTP switching to RTP target address 182.176.118.54:4000 as source
– Executing [6004@supervisor:2] NoCDR(“PJSIP/6002-0000003b”, “”) in new stack
[2018-12-04 20:17:21] WARNING[16230][C-0000001d]: func_channel.c:460 func_channel_read: Unknown or unavailable item requested: ‘uri’
– Executing [6004@supervisor:3] Set(“PJSIP/6002-0000003b”, “uri=”) in new stack
– Executing [6004@supervisor:4] Verbose(“PJSIP/6002-0000003b”, “3,Unknown call from to 6004”) in new stack
– Unknown call from to 6004
– Executing [6004@supervisor:5] Dial(“PJSIP/6002-0000003b”, “PJSIP/6004”) in new stack
– Called PJSIP/6004
– PJSIP/6002-0000003b requested media update control 26, passing it to PJSIP/6004-0000003c
== DTLS ECDH initialized (automatic), faster PFS enabled
– PJSIP/6004-0000003c is ringing
– PJSIP/6004-0000003c is ringing
> 0x7f75d4029390 – Strict RTP learning complete - Locking on source address 182.176.118.54:4000
– No one is available to answer at this time (1:0/0/0)
– Executing [6004@supervisor:6] Hangup(“PJSIP/6002-0000003b”, “”) in new stack

Your SIP trace is not a call. It is part of a successful registration.

yes. I have sent these to confirm whether registration is successful or not. Following are call traces. Following are sip call logs. One need to confirm is it may be stun configuration issue?

== DTLS ECDH initialized (automatic), faster PFS enabled
<— Transmitting SIP request (1380 bytes) to WSS:110.93.245.133:23211 —>
INVITE sip:79ckept7@110.93.245.133:23211;transport=ws SIP/2.0
Via: SIP/2.0/WSS 5.9.90.38:8089;rport;branch=z9hG4bKPj309596e3-9027-45ef-98be-1c4b89fb513d;alias
From: “6002” sip:6002@ips.dev.local;tag=41695e17-f01c-4ee6-9920-f6b116e3e543
To: sip:79ckept7@110.93.245.133
Contact: sip:asterisk@ips.dev.local:5060;transport=ws
Call-ID: 8b0e8b4f-240b-4a9c-bda2-6e953fd7ffe6
CSeq: 28640 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 13.22.0
Content-Type: application/sdp
Content-Length: 678

v=0
o=- 85685478 85685478 IN IP4 5.9.90.38
s=Asterisk
c=IN IP4 5.9.90.38
t=0 0
m=audio 18064 UDP/TLS/RTP/SAVPF 107 0 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 BB:05:4F:01:66:C2:49:E3:49:5E:AA:7C:C7:F8:57:15:F7:29:83:D3:B6:79:B0:9A:17:E6:36:8A:34:83:F7:9D
a=ice-ufrag:04d1bb4c6a265f242f1d9d3a57ae32c7
a=ice-pwd:018a9fdd5ed9b52320a361ae133066ad
a=candidate:H5095a26 1 UDP 2130706431 5.9.90.38 18064 typ host
a=candidate:H5095a26 2 UDP 2130706430 5.9.90.38 18065 typ host
a=rtpmap:107 opus/48000/2
a=fmtp:107 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux

<— Received SIP response (368 bytes) from WSS:110.93.245.133:23211 —>
SIP/2.0 100 Trying
Via: SIP/2.0/WSS 5.9.90.38:8089;rport;branch=z9hG4bKPj309596e3-9027-45ef-98be-1c4b89fb513d;alias
To: sip:79ckept7@110.93.245.133
From: “6002” sip:6002@ips.dev.local;tag=41695e17-f01c-4ee6-9920-f6b116e3e543
Call-ID: 8b0e8b4f-240b-4a9c-bda2-6e953fd7ffe6
CSeq: 28640 INVITE
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Length: 0

<— Received SIP response (443 bytes) from WSS:110.93.245.133:23211 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/WSS 5.9.90.38:8089;rport;branch=z9hG4bKPj309596e3-9027-45ef-98be-1c4b89fb513d;alias
To: sip:79ckept7@110.93.245.133;tag=j7p563q958
From: “6002” sip:6002@ips.dev.local;tag=41695e17-f01c-4ee6-9920-f6b116e3e543
Call-ID: 8b0e8b4f-240b-4a9c-bda2-6e953fd7ffe6
CSeq: 28640 INVITE
Contact: sip:79ckept7@fuql0v203hce.invalid;transport=ws
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Length: 0

-- PJSIP/6004-00000047 is ringing
-- PJSIP/6004-00000047 is ringing

<— Received SIP response (400 bytes) from WSS:110.93.245.133:23211 —>
SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/WSS 5.9.90.38:8089;rport;branch=z9hG4bKPj309596e3-9027-45ef-98be-1c4b89fb513d;alias
To: sip:79ckept7@110.93.245.133;tag=j7p563q958
From: “6002” sip:6002@ips.dev.local;tag=41695e17-f01c-4ee6-9920-f6b116e3e543
Call-ID: 8b0e8b4f-240b-4a9c-bda2-6e953fd7ffe6
CSeq: 28640 INVITE
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Length: 0
<— Transmitting SIP request (426 bytes) to WSS:110.93.245.133:23211 —>
ACK sip:79ckept7@110.93.245.133:23211;transport=ws SIP/2.0
Via: SIP/2.0/WSS 5.9.90.38:8089;rport;branch=z9hG4bKPj309596e3-9027-45ef-98be-1c4b89fb513d;alias
From: “6002” sip:6002@ips.dev.local;tag=41695e17-f01c-4ee6-9920-f6b116e3e543
To: sip:79ckept7@110.93.245.133;tag=j7p563q958
Call-ID: 8b0e8b4f-240b-4a9c-bda2-6e953fd7ffe6
CSeq: 28640 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 13.22.0
Content-Length: 0

-- No one is available to answer at this time (1:0/0/0)
-- Executing [6004@supervisor:6] Hangup("PJSIP/6002-00000046", "") in new stack

== Spawn extension (supervisor, 6004, 6) exited non-zero on ‘PJSIP/6002-00000046’
<— Transmitting SIP request (435 bytes) to UDP:110.93.245.133:59363 —>
BYE sip:6002@110.93.245.133:59363;ob SIP/2.0
Via: SIP/2.0/UDP 5.9.90.38:5060;rport;branch=z9hG4bKPj50922778-3b2f-4a44-821d-4cb535a3a907
From: sip:6004@5.9.90.38;tag=302c3c05-79bf-40fc-a848-23c752c5ac7b
To: “6002” sip:6002@5.9.90.38;tag=28b367ab88994d278474542957d79fbf
Call-ID: e08196cc205d466a996eee23342c7c7c
CSeq: 15978 BYE
Reason: Q.850;cause=19
Max-Forwards: 70
User-Agent: Asterisk PBX 13.22.0
Content-Length: 0

These are stun configuration in rtp.conf file

rtpstart=10000
rtpend=20000
icesupport=yes
stunaddr:19302=stun.l.google.com

The call was rejected by the destination, as user temporarily unavailable. No further information was provided.

Probably you generate certs by yourself. And when you trying to register a browser sip client it not going well because your certs are not verified this is why you are probably not available to receive phone calls

It seems extension is not properly registered. But when i show from command “pjsip show endpoints” extension shows “Not in user” means registered. Previously I was using sip protocol and found same issue in it. In sip Web extension immediately went on unreachable after registration. Is issue due to not properly STUN server ?

The WebRTC side is responding with 480 Temporarily Unavailable. You’d need to look and investigate on that side, as the problem is not in Asterisk.

This is a site from where we can get demo.

https://collecttix.github.io/ctxSip/

On it I have register with my user name , password and Server IP I am successfully able to get call. If issue is in browser then I think issue should be in this scenario.

WebRTC doesn’t define the signaling or the behavior of the client Javascript logic. It only provides a mechanism to exchange the media information between that logic and the browser itself. It is entirely possible for one implementation to work and another to fail. Why that is depends on what the client logic is doing. From the perspective of Asterisk based on what you’ve provided it is doing what it should. It is the client that is responding that it is ringing and then sending a temporarily unavailable. Asterisk doesn’t control that.

Respected members thanks for your cooperation for helping me to resolve this issue. It got fixed. Actually issue was in browser not in configuration.