1
votes

I have two ways audio when calling from a WebRTC client connected to Asterisk to my mobile phone, but when I call from the mobile phone to the WebRTC client the call is established and there is only one way audio: from the WebRTC client to the mobile phone.

I'm using Asterisk 15.6.1 installed on a VPS with static IP, the WebRTC client is a browser softphone using the SIP.js library, and I have a local phone number from Localphone.

My "pjsip.conf" relevant settings are:

[localphone]
type=registration
transport=transport-udp
outbound_auth=localphone
client_uri = sip:[email protected]:5060
server_uri = sip:localphone.com:5060
auth_rejection_permanent=no
contact_user=12345678

[localphone]
type=auth
auth_type=userpass
username=12345678
password=mypassword

[localphone]
type=aor
max_contacts=100
contact=sip:[email protected]

[localphone]
type=endpoint
transport=transport-udp
context=localphone-inc
disallow = all
allow = ulaw
allow = alaw
rtcp_mux=yes
ice_support=yes
direct_media=no
from_user=12345678
from_domain=localphone.com
outbound_auth=localphone
aors=localphone

[localphone]
type = identify
endpoint = localphone
match = 140.153.72.56


; This is the WebRTC client

[1652]
type=aor
max_contacts=100

[auth1652]
type=auth
auth_type=userpass
username=1652
password=complicatedpassword

[1652]
type=endpoint
context=localphone-pjsip
aors=1652
auth=auth1652
transport=transport-wss
webrtc=yes
disallow=all
allow=ulaw
allow=alaw
dtls_cert_file=/etc/asterisk/key/asterisk.pem
dtls_private_key=/etc/asterisk/key/asterisk.key

[1652]
type = identify
endpoint = 1652
match = 123.123.123.123  ; the public IP of the VPS

The Asterisk debug log doesn’t show errors. The SIP session looks like this:

<--- Received SIP request (1175 bytes) from UDP:140.153.72.56:5060 --->
INVITE sip:136.46.324.75:5060 SIP/2.0
Record-Route: <sip:140.153.72.56;lr=on;ftag=gK086bb5a7>
Record-Route: <sip:126.219.52.41;lr;ftag=gK086bb5a7>
Via: SIP/2.0/UDP 140.153.72.56;branch=z9hG4bK356c.5360dbb7.0
Via: SIP/2.0/UDP 126.219.52.41:5060;rport=5060;branch=z9hG4bK356c.10463da.0
From: <sip:[email protected]>;tag=gK086bb5a7
To: <sip:[email protected]>;tag=514dc3ba-68ed-42ff-9733-bd65b8ebb7c7
Call-ID: [email protected]
CSeq: 63984 INVITE
Max-Forwards: 12
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,  multipart/mixed
Contact: <sip:126.219.52.41;vbdid=941.29056c13>
Supported: timer
Session-Expires: 1800;refresher=uac
Min-SE: 90
Content-Length:   239
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 13229 650067 IN IP4 199.199.12.56
s=SIP Media Capabilities
c=IN IP4 199.199.12.54
t=0 0
m=audio 40808 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:20

       > 0x7fddf001b170 -- Strict RTP learning after remote address set to: 199.199.12.54:40808
<--- Transmitting SIP response (1062 bytes) to UDP:140.153.72.56:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 140.153.72.56;rport=5060;received=140.153.72.56;branch=z9hG4bK356c.5360dbb7.0
Via: SIP/2.0/UDP 126.219.52.41:5060;rport=5060;branch=z9hG4bK356c.10463da.0
Record-Route: <sip:140.153.72.56;lr;ftag=gK086bb5a7>
Record-Route: <sip:126.219.52.41;lr;ftag=gK086bb5a7>
Call-ID: [email protected]
From: <sip:[email protected]>;tag=gK086bb5a7
To: <sip:[email protected]>;tag=514dc3ba-68ed-42ff-9733-bd65b8ebb7c7
CSeq: 63984 INVITE
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip:136.46.324.75:5060>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
Server: Asterisk PBX 15.6.1
Content-Type: application/sdp
Content-Length:   234

v=0
o=- 13229 650069 IN IP4 136.46.324.75
s=Asterisk
c=IN IP4 136.46.324.75
t=0 0
m=audio 10010 RTP/AVP 0 100
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

       > 0x7fddf001b170 -- Strict RTP switching to RTP target address 199.199.12.54:40808 as source
<--- Received SIP request (411 bytes) from UDP:140.153.72.56:5060 --->
ACK sip:136.46.324.75:5060 SIP/2.0
Via: SIP/2.0/UDP 140.153.72.56;branch=z9hG4bK356c.5360dbb7.2
Via: SIP/2.0/UDP 126.219.52.41:5060;rport=5060;branch=z9hG4bK356c.10463da.2
From: <sip:[email protected]>;tag=gK086bb5a7
To: <sip:[email protected]>;tag=514dc3ba-68ed-42ff-9733-bd65b8ebb7c7
Call-ID: [email protected]
CSeq: 63984 ACK
Max-Forwards: 12
Content-Length: 0


<--- Received SIP request (428 bytes) from WSS:152.231.162.25:53283 --->
BYE sip:[email protected]:5060;transport=ws SIP/2.0
Via: SIP/2.0/WSS qae9g3ug98cm.invalid;branch=z9hG4bK8418203
Max-Forwards: 70
To: <sip:[email protected]>;tag=46b408fd-815a-49c1-b337-74ee894d6e44
From: "Grant Brandon" <sip:[email protected]>;tag=1l7sldm3o2
Call-ID: 4b8d773b-243b-4e97-9962-efc4d55eb0de
CSeq: 27946 BYE
Supported: outbound
User-Agent: SIP.js/0.7.8
Content-Length: 0


<--- Transmitting SIP response (376 bytes) to WSS:152.231.162.25:53283 --->
SIP/2.0 200 OK
Via: SIP/2.0/WSS qae9g3ug98cm.invalid;rport=53283;received=152.231.162.25;branch=z9hG4bK8418203
Call-ID: 4b8d773b-243b-4e97-9962-efc4d55eb0de
From: "Grant Brandon" <sip:[email protected]>;tag=1l7sldm3o2
To: <sip:[email protected]>;tag=46b408fd-815a-49c1-b337-74ee894d6e44
CSeq: 27946 BYE
Server: Asterisk PBX 15.6.1
Content-Length:  0


    -- Channel PJSIP/601-00000003 left 'simple_bridge' basic-bridge <f59afd46-1e16-4f47-9a9d-59c11987cc77>
    -- Channel PJSIP/localphone-00000002 left 'simple_bridge' basic-bridge <f59afd46-1e16-4f47-9a9d-59c11987cc77>
  == Spawn extension (localphone-pjsip, 601, 1) exited non-zero on 'PJSIP/localphone-00000002'
<--- Transmitting SIP request (487 bytes) to UDP:140.153.72.56:5060 --->
BYE sip:126.219.52.41;vbdid=941.29056c13 SIP/2.0
Via: SIP/2.0/UDP 136.46.324.75:5060;rport;branch=z9hG4bKPjf05b6f33-c9d2-4606-80d5-1e54fc110d40
From: <sip:[email protected]>;tag=514dc3ba-68ed-42ff-9733-bd65b8ebb7c7
To: <sip:[email protected]>;tag=gK086bb5a7
Call-ID: [email protected]
CSeq: 13266 BYE
Route: <sip:140.153.72.56;lr;ftag=gK086bb5a7>
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: Asterisk PBX 15.6.1
Content-Length:  0


<--- Received SIP response (335 bytes) from UDP:140.153.72.56:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 136.46.324.75:5060;rport=5060;branch=z9hG4bKPjf05b6f33-c9d2-4606-80d5-1e54fc110d40
From: <sip:[email protected]>;tag=514dc3ba-68ed-42ff-9733-bd65b8ebb7c7
To: <sip:[email protected]>;tag=gK086bb5a7
Call-ID: [email protected]
CSeq: 13266 BYE
Content-Length: 0

Your help will be appreciated !

1
One-way audio sounds like NAT or firewall. Normally ICE connectivity checks would validate that but VoIP doesn't always use ICE. Can you post the SDP messages?Josh Mackey
Sonus is telling asterisk to use ip 199.199.12.54 for voice communications, but the sip messages are coming from 126.219.52.41. Does the machine have two different ip addresses?Josh Mackey
The machine has only one IP address: 136.46.324.75. The IP that you noticed, namely 199.199.12.56 is not my IP and it doesn't seem to be Localphone's IP either. Localphone appears in the above lines with the IP's: 126.219.52.41 and 140.153.72.56. The IP that you noticed, 199.199.12.56 seems to be located in the US and associated with the local phone number rented from Localphone (+13051079265) which is also located in the US.D. Verner
199.199.12.56 also appears in the Call ID (Call-ID: [email protected]). My guess is that it's an American IP associated with the call when it's received by Localphone. Thank you for this interesting catch. I haven't noticed it at all. What do you think is happening ?D. Verner
Sonus is telling asterisk to send the voice data to 199.199.12.56. If you dont know where that IP is coming from, that’s probably your one-way audio issue. I’m not familiar with sonus devices so I don’t know how it discovers ip addresses, but it looks like it’s using the wrong one. You’ll need to check it’s logs and config files to find out.Josh Mackey

1 Answers

0
votes

https://bugs.chromium.org/p/chromium/issues/detail?id=752458

That might be your issue. Basically apple says they will do things different, i think. I am looking into this issue on Iphones too.