No audio when endpoint and Asterisk are both behind distinct NATs

Hello, I’m relatively new to Asterisk so please go easy :slightly_smiling_face:

The problem
In certain conditions, audio is not working when a call is established between two endpoints. For debugging purposes I’ve narrowed down the scenario to a call from a soft client to Asterisk (*60—talking clock).

The Setup
Both Asterisk and a soft client are behind two distinct NATs. Asterisk is behind my home fiber-optics router’s NAT while the soft client, on an iPhone, is on a mobile operator’s NAT network. I’ve set the pjsip port to be 5566 (to cutout annoying internet scanning of port 5060). My home router has the appropriate port-forwarding for pjsip as well as RTP.

The test
When on the same NAT (router 192.168.3.1) as Asterisk (192.168.3.44), soft client (192.168.3.34 with Domain set to a dyndns FQDN) calling *60 works great, I can hear the talking clock.

When soft client is on a distinct NAT (private IP 10.72.203.240 with public IP of 31.4.202.36) the call is established but I cannot hear a thing. Also a disconnect signaling (from the soft client) does not seem to reach Asterisk.

Analysis
Sharkwire reveals that after the call is established, Asterisk sends the RTP traffic to the soft client’s NAT address instead of sending it to its public address. (It makes sense that it is ok when the client is on the the same NAT as asterisk, but clearly it is not ok when the client is not on the same NAT)

Please checkout the call flow diagrams attached

You need to provide the PJSIP configuration (endpoint specifically) involved. You may not have it configured properly.

Below are relevant segments from various config files, I hope I covered the important areas.

**pjsip.endpoint.conf** 

[301]
type=endpoint
aors=301
auth=301-auth
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
allow=ulaw,alaw,gsm,g726,g722
context=from-internal
callerid=My Mobile Phone Extension <301>
dtmf_mode=rfc4733
aggregate_mwi=yes
use_avpf=no
rtcp_mux=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=no
timers=yes
media_encryption_optimistic=no
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en


**pjsip.aor.conf** 

[301]
type=aor
max_contacts=1
remove_existing=yes
maximum_expiration=7200
minimum_expiration=60
qualify_frequency=60


**pjsip.auth.conf**

[301-auth]
type=auth
auth_type=userpass
password=xxxxxxx
username=301


**pjsip.identify.conf**

[301-identify]
type=identify
endpoint=301


**pjsip.transports.conf**

[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5566
external_media_address=79.154.247.180
external_signaling_address=79.154.247.180
allow_reload=no
tos=cs3
cos=3
local_net=192.168.3.0/24


**sip_general_additional.conf**

vmexten=*97
useragent=FPBX-14.0.3.13(13.20.0)
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=g726
allow=g722
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
limitonpeers=yes
rtpend=11999
context=from-sip-external
callerid=Unknown
rtpstart=11000
tcpenable=no
callevents=no
bindport=5160
jbenable=no
checkmwi=10
maxexpiry=3600
minexpiry=60
srvlookup=no
tlsenable=no
allowguest=no
notifyhold=yes
rtptimeout=30
canreinvite=no
tlsbindaddr=[::]:5161
rtpkeepalive=0
videosupport=no
defaultexpiry=120
notifyringing=yes
maxcallbitrate=384
rtpholdtimeout=300
g726nonstandard=no
registertimeout=20
tlsclientmethod=tlsv1
registerattempts=0
nat=force_rport,comedia
externhost=something.dynu.net
externrefresh=120
ALLOW_SIP_ANON=no
tlscafile=/etc/ssl/certs/ca-certificates.crt
localnet=192.168.3.0/24
language=en

I’d also suggest providing a log from “pjsip set logger on” of a call attempt. The configuration appears to be correct in Asterisk, and that would confirm it.

Below is a capture of pjsip logger. Keep in mind that this capture below may not match the call flow attached at the top of this thread (because was done at different instances).


raspbx3*CLI> 
<--- Received SIP request (561 bytes) from UDP:31.4.202.36:15440 --->
REGISTER sip:sanjalon.dynu.net:5566 SIP/2.0
Via: SIP/2.0/UDP 10.72.203.240:33435;branch=z9hG4bK-524287-1---4b247d1dd5df267a;rport
Max-Forwards: 70
Contact: <sip:301@10.72.203.240:33435;rinstance=d87d018d1fba325e;transport=UDP>
To: <sip:301@sanjalon.dynu.net:5566>
From: <sip:301@sanjalon.dynu.net:5566>;tag=fdfbc845
Call-ID: m-f1zWRgE8M0OfZ5N6ApsA..
CSeq: 1 REGISTER
Expires: 600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 0


<--- Transmitting SIP response (516 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---4b247d1dd5df267a
Call-ID: m-f1zWRgE8M0OfZ5N6ApsA..
From: <sip:301@sanjalon.dynu.net>;tag=fdfbc845
To: <sip:301@sanjalon.dynu.net>;tag=z9hG4bK-524287-1---4b247d1dd5df267a
CSeq: 1 REGISTER
WWW-Authenticate: Digest  realm="asterisk",nonce="1535378252/d542d69206e095243a844288c5936176",opaque="1fa9595c23490476",algorithm=md5,qop="auth"
Server: FPBX-14.0.3.13(13.20.0)
Content-Length:  0


<--- Received SIP request (848 bytes) from UDP:31.4.202.36:15440 --->
REGISTER sip:sanjalon.dynu.net:5566 SIP/2.0
Via: SIP/2.0/UDP 10.72.203.240:33435;branch=z9hG4bK-524287-1---07cb386bf4213d3f;rport
Max-Forwards: 70
Contact: <sip:301@10.72.203.240:33435;rinstance=d87d018d1fba325e;transport=UDP>
To: <sip:301@sanjalon.dynu.net:5566>
From: <sip:301@sanjalon.dynu.net:5566>;tag=fdfbc845
Call-ID: m-f1zWRgE8M0OfZ5N6ApsA..
CSeq: 2 REGISTER
Expires: 600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Authorization: Digest username="301",realm="asterisk",nonce="1535378252/d542d69206e095243a844288c5936176",uri="sip:sanjalon.dynu.net:5566",response="713d6608afe1f03ea7b32c7171260ad9",cnonce="661048d63a872b4a5f885fcf31d63756",nc=00000001,qop=auth,algorithm=md5,opaque="1fa9595c23490476"
Content-Length: 0


<--- Transmitting SIP response (489 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---07cb386bf4213d3f
Call-ID: m-f1zWRgE8M0OfZ5N6ApsA..
From: <sip:301@sanjalon.dynu.net>;tag=fdfbc845
To: <sip:301@sanjalon.dynu.net>;tag=z9hG4bK-524287-1---07cb386bf4213d3f
CSeq: 2 REGISTER
Date: Mon, 27 Aug 2018 13:57:32 GMT
Contact: <sip:301@79.154.246.27:15440;rinstance=d87d018d1fba325e>;expires=599
Expires: 600
Server: FPBX-14.0.3.13(13.20.0)
Content-Length:  0


<--- Transmitting SIP request (475 bytes) to UDP:31.4.202.36:15440 --->
OPTIONS sip:301@31.4.202.36:15440;rinstance=d87d018d1fba325e SIP/2.0
Via: SIP/2.0/UDP 79.154.246.27:5566;rport;branch=z9hG4bKPja0967174-8ace-4be1-84c9-9437d4eab02b
From: <sip:301@192.168.3.44>;tag=aaf43c1a-fac9-409b-b428-4cf30736c3fc
To: <sip:301@31.4.202.36;rinstance=d87d018d1fba325e>
Contact: <sip:301@79.154.246.27:5566>
Call-ID: 4c418479-08d9-4154-96c5-54e2335b5570
CSeq: 38069 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-14.0.3.13(13.20.0)
Content-Length:  0


<--- Received SIP response (918 bytes) from UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 79.154.246.27:5566;rport=5566;branch=z9hG4bKPja0967174-8ace-4be1-84c9-9437d4eab02b;received=79.154.247.180
Contact: <sip:10.72.203.240:33435>
To: <sip:301@31.4.202.36;rinstance=d87d018d1fba325e>;tag=6397e02f
From: <sip:301@192.168.3.44>;tag=aaf43c1a-fac9-409b-b428-4cf30736c3fc
Call-ID: 4c418479-08d9-4154-96c5-54e2335b5570
CSeq: 38069 OPTIONS
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Content-Type: application/sdp
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 305

v=0
o=- 0 1 IN IP4 192.168.0.250
s=-
c=IN IP4 192.168.0.250
t=0 0
m=audio 15000 RTP/AVP 3 102 0 8 9 101
a=rtpmap:3 GSM/8000
a=rtpmap:102 iLBC/8000
a=fmtp:102 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

<--- Received SIP request (857 bytes) from UDP:31.4.202.36:15440 --->
INVITE sip:*60@sanjalon.dynu.net:5566 SIP/2.0
Via: SIP/2.0/UDP 10.72.203.240:33435;branch=z9hG4bK-524287-1---95fcf96c59291416;rport
Max-Forwards: 70
Contact: <sip:301@10.72.203.240:33435;transport=UDP>
To: <sip:*60@sanjalon.dynu.net:5566>
From: <sip:301@sanjalon.dynu.net:5566>;tag=e5b6a61b
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Content-Type: application/sdp
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 304

v=0
o=- 0 1 IN IP4 192.168.0.250
s=-
c=IN IP4 10.72.203.240
t=0 0
m=audio 4000 RTP/AVP 3 102 0 8 9 101
a=rtpmap:3 GSM/8000
a=rtpmap:102 iLBC/8000
a=fmtp:102 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

<--- Transmitting SIP response (514 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---95fcf96c59291416
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=z9hG4bK-524287-1---95fcf96c59291416
CSeq: 1 INVITE
WWW-Authenticate: Digest  realm="asterisk",nonce="1535378258/0dadba5e811f7ca178725b70a5e9efe5",opaque="6606b8636979820e",algorithm=md5,qop="auth"
Server: FPBX-14.0.3.13(13.20.0)
Content-Length:  0


<--- Received SIP request (344 bytes) from UDP:31.4.202.36:15440 --->
ACK sip:*60@sanjalon.dynu.net:5566 SIP/2.0
Via: SIP/2.0/UDP 10.72.203.240:33435;branch=z9hG4bK-524287-1---95fcf96c59291416;rport
Max-Forwards: 70
To: <sip:*60@sanjalon.dynu.net>;tag=z9hG4bK-524287-1---95fcf96c59291416
From: <sip:301@sanjalon.dynu.net:5566>;tag=e5b6a61b
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
CSeq: 1 ACK
Content-Length: 0


<--- Received SIP request (1148 bytes) from UDP:31.4.202.36:15440 --->
INVITE sip:*60@sanjalon.dynu.net:5566 SIP/2.0
Via: SIP/2.0/UDP 10.72.203.240:33435;branch=z9hG4bK-524287-1---75d4a63a5849db2c;rport
Max-Forwards: 70
Contact: <sip:301@10.72.203.240:33435;transport=UDP>
To: <sip:*60@sanjalon.dynu.net:5566>
From: <sip:301@sanjalon.dynu.net:5566>;tag=e5b6a61b
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Content-Type: application/sdp
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Authorization: Digest username="301",realm="asterisk",nonce="1535378258/0dadba5e811f7ca178725b70a5e9efe5",uri="sip:*60@sanjalon.dynu.net:5566",response="870a697eac9a3e2822a7827604ffc8a7",cnonce="c913ca409e94d8b1924499fe54314884",nc=00000001,qop=auth,algorithm=md5,opaque="6606b8636979820e"
Content-Length: 304

v=0
o=- 0 1 IN IP4 192.168.0.250
s=-
c=IN IP4 10.72.203.240
t=0 0
m=audio 4000 RTP/AVP 3 102 0 8 9 101
a=rtpmap:3 GSM/8000
a=rtpmap:102 iLBC/8000
a=fmtp:102 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

<--- Transmitting SIP response (321 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Content-Length:  0


<--- Transmitting SIP response (946 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=ff488360-4efc-48c7-afac-9b20d4032bce
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@sanjalon.dynu.net>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11078 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Transmitting SIP response (946 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=ff488360-4efc-48c7-afac-9b20d4032bce
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@sanjalon.dynu.net>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11078 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Transmitting SIP response (946 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=ff488360-4efc-48c7-afac-9b20d4032bce
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@sanjalon.dynu.net>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11078 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Transmitting SIP response (946 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=ff488360-4efc-48c7-afac-9b20d4032bce
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@sanjalon.dynu.net>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11078 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Transmitting SIP response (946 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=ff488360-4efc-48c7-afac-9b20d4032bce
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@sanjalon.dynu.net>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11078 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<--- Transmitting SIP response (946 bytes) to UDP:31.4.202.36:15440 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.72.203.240:33435;rport=15440;received=31.4.202.36;branch=z9hG4bK-524287-1---75d4a63a5849db2c
Call-ID: pyWfL3VLGHz8RGn4nRw-2w..
From: <sip:301@sanjalon.dynu.net>;tag=e5b6a61b
To: <sip:*60@sanjalon.dynu.net>;tag=ff488360-4efc-48c7-afac-9b20d4032bce
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@sanjalon.dynu.net>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11078 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

raspbx3*CLI>

It does not appear as though the remote endpoint is sending the ACK to the given Contact address in the 200 OK, or the 200 OK never reaches it. From an Asterisk side everything is configured correctly.

jcolp, can you please rephrase your response. It was not clear to me if a ACK is missing or not, and from who to who? Also, what in the soft phone may be badly configured to cause this issue?

Asterisk is sending a 200 OK to your phone to tell it that the call has been answered. It is the responsibility of the phone to send an ACK back, so Asterisk knows the 200 OK was received. This is never received and Asterisk attempts to send the 200 OK over and over.

jcolp, thanks to your insights, I’ve shifted my focus to the iPhone soft client logs (attached below). I noticed that at some point the public IP address of Asterisk (79.154.247.180) changes to an address I am not familiar with (79.154.246.27). This change starts when the client sends its first ACK message. Clearly Asterisk does not receive these ACK messages nor the final BYE message.
Do you have any clues as to what might be going on?

20180828-110027.317 SessionTalk iPhone 0x1701e7000 | SEND: 

REGISTER sip:79.154.247.180:5566 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:44637;branch=z9hG4bK-524287-1---02191d3d12002035;rport
Max-Forwards: 70
Contact: <sip:301@192.168.3.1:44637;rinstance=c781c7ae48c10b1d;transport=UDP>;expires=0
To: <sip:301@79.154.247.180:5566>
From: <sip:301@79.154.247.180:5566>;tag=d208070e
Call-ID: u3mPBbALJ99wOaO6hcgI_w..
CSeq: 3 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110027.668 SessionTalk iPhone 0x1701e7000 | SEND: 

REGISTER sip:79.154.247.180:5566 SIP/2.0
Via: SIP/2.0/UDP 192.168.3.1:44637;branch=z9hG4bK-524287-1---8d790234c338f402;rport
Max-Forwards: 70
Contact: <sip:301@192.168.3.1:44637;rinstance=c781c7ae48c10b1d;transport=UDP>;expires=0
To: <sip:301@79.154.247.180:5566>
From: <sip:301@79.154.247.180:5566>;tag=d208070e
Call-ID: u3mPBbALJ99wOaO6hcgI_w..
CSeq: 4 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110027.968 SessionTalk iPhone 0x1701e7000 | SEND: 

REGISTER sip:79.154.247.180:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---a52b9b3c62dcb91e;rport
Max-Forwards: 70
Contact: <sip:301@10.163.229.86:44637;rinstance=189173ff0f5f19e6;transport=UDP>
To: <sip:301@79.154.247.180:5566>
From: <sip:301@79.154.247.180:5566>;tag=6c8dbf7c
Call-ID: QZM4T4jH-YYIur3luPHFrQ..
CSeq: 1 REGISTER
Expires: 600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110028.068 SessionTalk iPhone 0x1701e7000 | SEND: 

REGISTER sip:79.154.247.180:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---19bb3b7346281b2e;rport
Max-Forwards: 70
Contact: <sip:301@10.163.229.86:44637;rinstance=189173ff0f5f19e6;transport=UDP>
To: <sip:301@79.154.247.180:5566>
From: <sip:301@79.154.247.180:5566>;tag=6c8dbf7c
Call-ID: QZM4T4jH-YYIur3luPHFrQ..
CSeq: 2 REGISTER
Expires: 600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110036.760 SessionTalk iPhone 0x1701e7000 | SEND: 

INVITE sip:*60@79.154.247.180:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---3ba7112868929752;rport
Max-Forwards: 70
Contact: <sip:301@10.163.229.86:44637;transport=UDP>
To: <sip:*60@79.154.247.180:5566>
From: <sip:301@79.154.247.180:5566>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Content-Type: application/sdp
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 304

v=0
o=- 0 1 IN IP4 192.168.0.250
s=-
c=IN IP4 10.163.229.86
t=0 0
m=audio 4000 RTP/AVP 3 102 0 8 9 101
a=rtpmap:3 GSM/8000
a=rtpmap:102 iLBC/8000
a=fmtp:102 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

20180828-110036.918 SessionTalk iPhone 0x1701e7000 | SEND: 

INVITE sip:*60@79.154.247.180:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---17359f18fed64b63;rport
Max-Forwards: 70
Contact: <sip:301@10.163.229.86:44637;transport=UDP>
To: <sip:*60@79.154.247.180:5566>
From: <sip:301@79.154.247.180:5566>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Content-Type: application/sdp
Supported: path, replaces, norefersub
User-Agent: SessionTalk 6.0
Content-Length: 304

v=0
o=- 0 1 IN IP4 192.168.0.250
s=-
c=IN IP4 10.163.229.86
t=0 0
m=audio 4000 RTP/AVP 3 102 0 8 9 101
a=rtpmap:3 GSM/8000
a=rtpmap:102 iLBC/8000
a=fmtp:102 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

20180828-110037.127 SessionTalk iPhone 0x1701e7000 | SEND: 

ACK sip:79.154.246.27:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---6babb40f2935bf4d;rport
Max-Forwards: 70
To: <sip:*60@79.154.247.180>;tag=7d89f3db-ba80-452c-9349-4ee9cd9c7bbc
From: <sip:301@79.154.247.180>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 2 ACK
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110037.768 SessionTalk iPhone 0x1701e7000 | SEND: 

ACK sip:79.154.246.27:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---6babb40f2935bf4d;rport
Max-Forwards: 70
To: <sip:*60@79.154.247.180>;tag=7d89f3db-ba80-452c-9349-4ee9cd9c7bbc
From: <sip:301@79.154.247.180>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 2 ACK
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110038.567 SessionTalk iPhone 0x1701e7000 | SEND: 

ACK sip:79.154.246.27:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---6babb40f2935bf4d;rport
Max-Forwards: 70
To: <sip:*60@79.154.247.180>;tag=7d89f3db-ba80-452c-9349-4ee9cd9c7bbc
From: <sip:301@79.154.247.180>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 2 ACK
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110040.568 SessionTalk iPhone 0x1701e7000 | SEND: 

ACK sip:79.154.246.27:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---6babb40f2935bf4d;rport
Max-Forwards: 70
To: <sip:*60@79.154.247.180>;tag=7d89f3db-ba80-452c-9349-4ee9cd9c7bbc
From: <sip:301@79.154.247.180>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 2 ACK
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110044.364 SessionTalk iPhone 0x1701e7000 | SEND: 

BYE sip:79.154.246.27:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---95c27e4afc48af11;rport
Max-Forwards: 70
Contact: <sip:301@10.163.229.86:44637;transport=UDP>
To: <sip:*60@79.154.247.180>;tag=7d89f3db-ba80-452c-9349-4ee9cd9c7bbc
From: <sip:301@79.154.247.180>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 3 BYE
User-Agent: SessionTalk 6.0
Content-Length: 0


20180828-110044.567 SessionTalk iPhone 0x1701e7000 | SEND: 

ACK sip:79.154.246.27:5566 SIP/2.0
Via: SIP/2.0/UDP 10.163.229.86:44637;branch=z9hG4bK-524287-1---6babb40f2935bf4d;rport
Max-Forwards: 70
To: <sip:*60@79.154.247.180>;tag=7d89f3db-ba80-452c-9349-4ee9cd9c7bbc
From: <sip:301@79.154.247.180>;tag=269cc978
Call-ID: 7dFPdi5VhnZBWs2naAOkUg..
CSeq: 2 ACK
User-Agent: SessionTalk 6.0
Content-Length: 0

Not really, but things don’t just change randomly. Something is causing it to happen.

@jcolp, I continued to examine traffic on both networks (the Asterisk NAT network and the iPhone’s GSM NAT network). I found that on its first OK message back to the mobile client, Asterisk stuffs in the Contact field an unidentified IP address (79.154.246.27 which I pointed out earlier) instead of its true public IP address (79.154.247.180)—see packet below. From that point, the mobile client starts sending RTP packets to the erroneous IP address while the mobile client continues to receive OK messages from Asterisk with the wrong IP address in the Contact field.
Any idea where Asterisk gets the IP address it stuffs in the Contact field?

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.164.219.54:15668;rport=28796;received=31.4.188.38;branch=z9hG4bK-524287-1---7c88f2736fbd8452
Call-ID: JaMh676HBB-ee5D1LetViA..
From: <sip:301@79.154.247.180>;tag=6aa51501
To: <sip:*60@79.154.247.180>;tag=a6caf319-defb-43ea-8d3b-72852eff19ee
CSeq: 2 INVITE
Server: FPBX-14.0.3.13(13.20.0)
Contact: <sip:79.154.246.27:5566>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub
P-Asserted-Identity: "Speaking Clock" <sip:*60@79.154.247.180>
Content-Type: application/sdp
Content-Length:   293

v=0
o=- 0 3 IN IP4 79.154.247.180
s=Asterisk
c=IN IP4 79.154.246.27
t=0 0
m=audio 11884 RTP/AVP 0 8 3 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

It is either learned based on what interface the message is going out on, or it is explicitly configured as a signaling and media address in the PJSIP configuration for NAT purposes.

Asterisk runs on a system with only one interface. The signaling and media addresses are configured to the correct public IP address as seen in the pjsip.transports_custom.conf file below.
Anywhere else I can look for? I am lost here.

[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5566
external_media_address=79.154.247.180
external_signaling_address=79.154.247.180
allow_reload=no
tos=cs3
cos=3
local_net=192.168.3.0/24

Are you sure it’s not configured elsewhere? Are you using FreePBX and it’s actually configured elsewhere? Have you done a grep in /etc/asterisk/ to see if that IP is mentioned anywhere?

jcolp, I am using FreePBX, correct. I’ve run a search on all the conf files in /etc/asterisk and could not find any reference to the erroneous IP address. Could there be other locations where it may appear?

It could also come from a dynamic DNS hostname. You can use the “pjsip show transport” CLI command to examine the transport and look at the configuration. Otherwise I don’t know, as Asterisk won’t just put a random IP address in like that.

In FreePBX look under Settings, Asterisk SIP Settings.

I finally decided to start from scratch (re-flash raspbx on a SD card) and after minimal configuration, the issue is gone and all is working well.
My guess is that while messing around with FreePBX I might have put the system in a state that caused the problem, yet I was not able to visibly see any bad configuration, not in FreePBS GUI nor in Asterisk config files. I guess I’ll never know if I missed something or perhaps there is a bug somewhere in Asterisk, FreePBS or a combination of them both.
In any event, thank you @jcolp for your input.