No audio on PJSIP channels

ghanou895 · October 18, 2021, 11:32am

Hello,
I don’t understand why I have no audio on my endpoints, When I log my softphones from a local address, everything works fine, but if I log from outside my network I have no audio.

I don’t understand how Astertisk can match the local IP address of my client, since In my softphone code I use my public IP address to log to asterisk

I’m using WebRTC for my sofphones

Here is my config

;======================  registration   =======

[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0
;local_net=172.16.1.0/32
;local_net=127.0.0.1/32
;external_media_address=41.111.136.198
;external_signaling_address=41.111.136.198

 
[icosnet]
type=registration
transport=transport-udp-nat
outbound_auth=icosnet
server_uri=sip:196.41.228.32
client_uri=sip:username@196.41.228.32
contact_user=username
retry_interval=60
;from_user=213982420090
;from_domain=196.41.228.32

 
[icosnet]
type=auth
auth_type=userpass
password=password
username=username

[icosnet]
type=endpoint
context=inbound-calls
disallow=all
allow=ulaw
outbound_auth=icosnet
aors=icosnet
direct_media=no

;======================= Clients =======
[transport-wss]
type=transport
protocol=wss
bind=172.16.1.12



;=================    5099   ===========================================================

[5099]
type=aor
max_contacts=2
remove_existing=yes

  
[5099]
type=auth
auth_type=userpass
username=5099
password=password 
 
[5099]
type=endpoint
aors=5099
auth=5099
dtls_auto_generate_cert=yes
webrtc=yes
context=default
disallow=all
allow=ulaw
direct_media=no

and this is the Log

<--- Transmitting SIP request (410 bytes) to UDP:196.41.228.32:5060 --->
ACK sip:0667121507@196.41.228.32 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.12:5060;rport;branch=z9hG4bKPjbd88f4fe-256d-4de4-802a-a37563205ca6
From: <sip:5099@172.16.1.12>;tag=248fc000-90b7-4830-83b7-12e2587b525b
To: <sip:0667121507@196.41.228.32>;tag=SIX3Q5Y7TWLSVZDY6EGA____.i
Call-ID: 0f2054e3-6b2c-4999-8d46-1f3aef1bb350
CSeq: 1856 ACK
Max-Forwards: 70
User-Agent: Asterisk PBX 18.4.0
Content-Length:  0


<--- Transmitting SIP request (1107 bytes) to UDP:196.41.228.32:5060 --->
INVITE sip:0667121507@196.41.228.32 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.12:5060;rport;branch=z9hG4bKPjf91e6807-fe96-481b-977c-af42457a0402
From: <sip:5099@172.16.1.12>;tag=248fc000-90b7-4830-83b7-12e2587b525b
To: <sip:0667121507@196.41.228.32>
Contact: <sip:asterisk@172.16.1.12:5060>
Call-ID: 0f2054e3-6b2c-4999-8d46-1f3aef1bb350
CSeq: 1857 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: Asterisk PBX 18.4.0
Authorization: Digest username="213982420090", realm="sip-1.pb", nonce="1634556467:bbcf374c59d08f2a1c888587e07e44482274ee47", uri="sip:0667121507@196.41.228.32", response="3a5f96f03ae2c4938adf2013915e3105"
Content-Type: application/sdp
Content-Length:   235

v=0
o=- 1707974439 1707974439 IN IP4 172.16.1.12
s=Asterisk
c=IN IP4 172.16.1.12
t=0 0
m=audio 11828 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Received SIP response (521 bytes) from UDP:196.41.228.32:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.1.12:5060;rport=65476;branch=z9hG4bKPjf91e6807-fe96-481b-977c-af42457a0402;received=41.111.136.198
Record-Route: <sip:196.41.228.32;lr;ep;pinhole=UDP:41.111.136.198:65476>
To: <sip:0667121507@196.41.228.32>
From: <sip:5099@172.16.1.12>;tag=248fc000-90b7-4830-83b7-12e2587b525b
Call-ID: 0f2054e3-6b2c-4999-8d46-1f3aef1bb350
CSeq: 1857 INVITE
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Server: PortaSIP
Content-Length: 0


<--- Received SIP response (714 bytes) from UDP:196.41.228.32:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.1.12:5060;rport=65476;branch=z9hG4bKPjf91e6807-fe96-481b-977c-af42457a0402;received=41.111.136.198
Record-Route: <sip:196.41.228.32;lr;ep;pinhole=UDP:41.111.136.198:65476>
Contact: sip:196.41.228.115:5070
To: <sip:0667121507@196.41.228.32>;tag=SIX3Q5Y7TWLSVZDY6PFQ____.i
From: <sip:5099@172.16.1.12>;tag=248fc000-90b7-4830-83b7-12e2587b525b
Call-ID: 0f2054e3-6b2c-4999-8d46-1f3aef1bb350
CSeq: 1857 INVITE
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Server: PortaSIP
Portasip-cps-limit: max=1;method=normal;aggregation-id=i_account:1431877;matched-by=digest_username;matched-value=213982420090
Content-Length: 0


<--- Received SIP response (993 bytes) from UDP:196.41.228.32:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.12:5060;rport=65476;branch=z9hG4bKPjf91e6807-fe96-481b-977c-af42457a0402;received=41.111.136.198
Record-Route: <sip:196.41.228.32;lr;ep;pinhole=UDP:41.111.136.198:65476>
Contact: sip:196.41.228.115:5070
To: <sip:0667121507@196.41.228.32>;tag=SIX3Q5Y7TWLSVZDY6PFQ____.i
From: <sip:5099@172.16.1.12>;tag=248fc000-90b7-4830-83b7-12e2587b525b
Call-ID: 0f2054e3-6b2c-4999-8d46-1f3aef1bb350
CSeq: 1857 INVITE
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Type: application/sdp
Server: PortaSIP
Portasip-cps-limit: max=1;method=normal;aggregation-id=i_account:1431877;matched-by=digest_username;matched-value=213982420090
Content-Length: 250

v=0
o=PortaSIP 3075015875196607957 1 IN IP4 196.41.228.115
s=-
t=0 0
m=audio 56002 RTP/AVP 0 101
c=IN IP4 196.41.228.115
b=AS:128
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:40
a=sendrecv

       > 0x7fb6d8031960 -- Strict RTP learning after remote address set to: 196.41.228.115:56002
<--- Transmitting SIP request (472 bytes) to UDP:196.41.228.32:5060 --->
ACK sip:196.41.228.115:5070 SIP/2.0
Via: SIP/2.0/UDP 172.16.1.12:5060;rport;branch=z9hG4bKPj9b6abdd4-7be6-43f7-aaee-57fa0603736d
From: <sip:5099@172.16.1.12>;tag=248fc000-90b7-4830-83b7-12e2587b525b
To: <sip:0667121507@196.41.228.32>;tag=SIX3Q5Y7TWLSVZDY6PFQ____.i
Call-ID: 0f2054e3-6b2c-4999-8d46-1f3aef1bb350
CSeq: 1857 ACK
Route: <sip:196.41.228.32;lr;ep;pinhole=UDP:41.111.136.198:65476>
Max-Forwards: 70
User-Agent: Asterisk PBX 18.4.0
Content-Length:  0


    -- PJSIP/icosnet-00000001 answered PJSIP/5099-00000000
       > 0x7fb6d8052150 -- Strict RTP learning after remote address set to: 192.168.163.245:62400
<--- Transmitting SIP response (1553 bytes) to WSS:105.235.129.145:25030 --->
SIP/2.0 200 OK
Via: SIP/2.0/WSS l9oh3rb05iga.invalid;rport=25030;received=105.235.129.145;branch=z9hG4bK7137964
Call-ID: drd9g7t6hd1hdtl8gs9h
From: <sip:5099@41.111.136.198>;tag=q2nvc83tg0
To: <sip:0667121507@41.111.136.198>;tag=5bb30772-4faa-4b86-be01-81c8e063d5eb
CSeq: 9480 INVITE
Server: Asterisk PBX 18.4.0
Contact: <sip:172.16.1.12:1983;transport=ws>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 90;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length:   922

v=0
o=- 897551239 2 IN IP4 172.16.1.12
s=Asterisk
c=IN IP4 172.16.1.12
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0
m=audio 16760 UDP/TLS/RTP/SAVPF 0 101
a=connection:new
a=setup:active
a=fingerprint:SHA-256 1F:3D:07:84:51:7B:93:80:9B:C8:3B:95:8C:09:51:98:43:22:EA:47:52:0C:65:32:71:95:D7:26:A5:21:31:C3
a=ice-ufrag:5e4fbc172d1a49524aa0b5192ad4827b
a=ice-pwd:019e8ed864764ea37134d924337b4b7b
a=candidate:Hac10010c 1 UDP 2130706431 172.16.1.12 16760 typ host
a=candidate:Hac110001 1 UDP 2130706431 172.17.0.1 16760 typ host
a=candidate:Hc824934 1 UDP 2130706431 fe80::e12e:53dc:1cf7:e6ff 16760 typ host
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:271470930 cname:15993d2a-f0be-486f-a2f5-42ac64b552d0
a=msid:54008c26-3c41-4efa-84da-d12d9d449229 c677551e-024c-4adb-897b-412e220acf6a
a=rtcp-fb:* transport-cc
a=mid:0

    -- Channel PJSIP/icosnet-00000001 joined 'simple_bridge' basic-bridge <a9cb77b7-301a-4348-bf5a-15ed933e4318>
    -- Channel PJSIP/5099-00000000 joined 'simple_bridge' basic-bridge <a9cb77b7-301a-4348-bf5a-15ed933e4318>
<--- Received SIP request (437 bytes) from WSS:105.235.129.145:25030 --->
ACK sip:172.16.1.12:1983;transport=ws SIP/2.0
Via: SIP/2.0/WSS l9oh3rb05iga.invalid;branch=z9hG4bK7384895
Max-Forwards: 69
To: <sip:0667121507@41.111.136.198>;tag=5bb30772-4faa-4b86-be01-81c8e063d5eb
From: <sip:5099@41.111.136.198>;tag=q2nvc83tg0
Call-ID: drd9g7t6hd1hdtl8gs9h
CSeq: 9480 ACK
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: outbound
User-Agent: JsSIP 3.8.0
Content-Length: 0


       > 0x7fb6d8052150 -- Strict RTP learning after ICE completion
<--- Received SIP request (481 bytes) from WSS:105.235.129.145:25030 --->
BYE sip:172.16.1.12:1983;transport=ws SIP/2.0
Via: SIP/2.0/WSS l9oh3rb05iga.invalid;branch=z9hG4bK5415583
Max-Forwards: 69
To: <sip:0667121507@41.111.136.198>;tag=5bb30772-4faa-4b86-be01-81c8e063d5eb
From: <sip:5099@41.111.136.198>;tag=q2nvc83tg0
Call-ID: drd9g7t6hd1hdtl8gs9h
CSeq: 9481 BYE
Reason: SIP ;cause=408; text="RTP Timeout"
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: outbound
User-Agent: JsSIP 3.8.0
Content-Length: 0


<--- Transmitting SIP response (338 bytes) to WSS:105.235.129.145:25030 --->
SIP/2.0 200 OK
Via: SIP/2.0/WSS l9oh3rb05iga.invalid;rport=25030;received=105.235.129.145;branch=z9hG4bK5415583
Call-ID: drd9g7t6hd1hdtl8gs9h
From: <sip:5099@41.111.136.198>;tag=q2nvc83tg0
To: <sip:0667121507@41.111.136.198>;tag=5bb30772-4faa-4b86-be01-81c8e063d5eb
CSeq: 9481 BYE
Server: Asterisk PBX 18.4.0
Content-Length:  0

jcolp · October 18, 2021, 11:50am

If Asterisk is behind NAT and you are using ICE, then you have to configure the ice_host_candidates portion of rtp.conf with a mapping for external IP address or enable STUN so Asterisk can discover its external IP address otherwise ICE negotiation will fail, and the call will have no media provided the client is external.

ghanou895 · October 18, 2021, 1:41pm

I’m a bit newbie, tried to read docs and mimic conf, can you please tell if this is correct

[general]
rtpstart=10002
rtpend=20000
rtcpinterval=9998
rtpchecksums=no
strictrtp=no
icesupport=yes
stunaddr=stun.l.google.com:19302


[ice_host_candidates]
interface 172.16.1.12 => 41.111.136.198

where [41.111.136.198] is my public IP address, and [172.16.1.12 ] is my asterisk server local address

jcolp · October 18, 2021, 1:43pm

It’s

[ice_host_candidates]
172.16.1.12 => 41.111.136.198

But yes, that would substitute 172.16.1.12 in ICE candidates for 41.111.136.198. If you have local clients you’d likely want to also set include_local_address. You also need to ensure that ports are forwarded.

ghanou895 · October 18, 2021, 1:46pm

Port forwarding is setup for HTTP and HTTPS requests so I can connect through WebSockets and ARI,
what port forwarding should be setup also

jcolp · October 18, 2021, 1:47pm

RTP has to also be forwarded. The ports are in the configuration you provided.

ghanou895 · October 18, 2021, 1:55pm

The thing I don’t understand is why there is no issue if the softphone is connected to the same network that asterisk, also how is asterisk able to link its local address.

jcolp · October 18, 2021, 1:56pm

If it’s on the same network then the local IP address in the SDP would allow ICE negotiation to occur and media to flow.

jcolp · October 18, 2021, 1:57pm

I should also throw in that if you are deploying WebRTC, you need to learn about the foundations of it because it WILL go wrong - like in this case - and you need an understanding of them. WebRTC is not something that works 100% of the time.

ghanou895 · October 18, 2021, 2:12pm

How is RTP received from Provider forwarded in this case while no forwarding is setup for RTP ports (when the softphone is in local network)

jcolp · October 18, 2021, 2:13pm

That depends on your NAT situation. The provider would provide a public IP address and port for media, Asterisk would send to that IP address and port. The device doing NAT would PROBABLY establish a bidirectional mapping such that traffic from the provider would then be sent to Asterisk even without explicit port forwarding.

If both parties are behind a NAT, then it is unlikely that would happen unless the use of STUN caused the NAT device to have a mapping as well.

system · November 17, 2021, 2:14pm

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