Users with local IP 192.168.100.0/24 disconnects on call in 30 secs

FreePBX Endpoints
1

Hi,
I know it’s been asked several times but I am still having issues with users (2 out of 50) that have a local IP 192.168.100.0/24. The call will still be connected but the audio cuts on the 30th second. Hope you can help this noob.
I already added the LAN network in SIP settings.
Restarted the firewall as well as the PBX.
No SIP/ALG on their specific routers
Windows Firewall off

PBX is on the cloud
RTP ports opened
PJSIP port is changed but opened
We are using softphone

Thank you in advance!

2

This sounds like it might be a double NAT situation, so please describe the network topology in some detail.

If things are only failing for some non-routable networks, I think I’d want to ask whether that network is also being used locally to Asterisk.

30 seconds is typically associated with a wrong Contact address resulting in ACK going to the wrong place, but that would result in the call going down on one side only rather than staying up on both sides.

Which side is initiating the failing call? Which side(s) stay up?

3

hi @david55

basically the pbx is in the cloud and users are in remote or working from home so different local IPs as well as their internet IPs are not static. so softphone -> home router -> pbx

Upon checking the PCAP, the BYE request came from the user side.

4

Not sure if this helps but i would post it as well.

Thanks,
Kim

1 0.000000 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
2 14.601477 pbxpubip userpublicip SIP 474 Request: OPTIONS sip:23xx@userpublicip:49648;ob
3 17.519189 userpublicip pbxpubip SIP 620 Request: REGISTER sip:pbxpubip:6XXX (1 binding)
4 17.519969 pbxpubip userpublicip SIP 633 Status: 401 Unauthorized
5 17.588141 userpublicip pbxpubip SIP 914 Request: REGISTER sip:pbxpubip:6XXX (1 binding)
6 17.589120 pbxpubip userpublicip SIP 581 Status: 200 OK (1 binding)
7 17.589716 pbxpubip userpublicip SIP 685 Request: NOTIFY sip:23xx@userpublicip:49648;ob
8 17.590118 pbxpubip userpublicip SIP 473 Request: OPTIONS sip:23xx@userpublicip:49648;ob
9 17.657287 userpublicip pbxpubip SIP 423 Status: 200 OK
10 17.657539 userpublicip pbxpubip SIP 825 Status: 200 OK
11 32.657493 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
12 39.919946 userpublicip pbxpubip SIP/SDP 1044 Request: INVITE sip:0066932700282@23xx
13 39.920679 pbxpubip userpublicip SIP 615 Status: 401 Unauthorized
14 39.990552 userpublicip pbxpubip SIP 432 Request: ACK sip:0066932700282@23xx
15 39.991405 userpublicip pbxpubip SIP/SDP 1337 Request: INVITE sip:0066932700282@23xx
16 39.992561 pbxpubip userpublicip SIP 417 Status: 100 Trying
17 45.075156 pbxpubip userpublicip SIP/SDP 914 Status: 183 Session Progress
18 45.773768 userpublicip pbxpubip SIP/SDP 935 Request: UPDATE sip:pbxpubip:6XXX
19 45.774501 pbxpubip userpublicip SIP/SDP 977 Status: 200 OK
20 46.977279 pbxpubip userpublicip SIP/SDP 1001 Status: 200 OK
21 47.066363 userpublicip pbxpubip SIP 428 Request: ACK sip:pbxpubip:6XXX
22 47.069264 userpublicip pbxpubip SIP/SDP 949 Request: UPDATE sip:pbxpubip:6XXX
23 47.069846 pbxpubip userpublicip SIP/SDP 977 Status: 200 OK
24 47.658707 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
25 62.660178 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
26 77.589813 pbxpubip userpublicip SIP 474 Request: OPTIONS sip:23xx@userpublicip:49648;ob
27 77.644998 userpublicip pbxpubip SIP 826 Status: 200 OK
28 77.668554 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
29 92.661310 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
30 95.164852 userpublicip pbxpubip SIP 457 Request: BYE sip:pbxpubip:6XXX
31 95.165318 pbxpubip userpublicip SIP 451 Status: 200 OK
32 107.663378 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
33 122.664692 userpublicip pbxpubip UDP 60 49648 → 6xxx Len=2
34 135.981320 pbxpubip userpublicip SIP 474 Request: OPTIONS sip:23xx@userpublicip:49648;ob
5

The only problem I can see is lines like

32 	107.663378 	userpublicip 	pbxpubip 	UDP 	60 	49648 → 6xxx Len=2

They are too short for normal RTP. Conversely there is no normal RTP, but you say that you do get media for the 30 seconds.

There are no retransmissions of the OK, so the ACK is clearly getting through and this doesn’t seem to be the normal 30 second, no reply to critical request/response case.

However, for anything that involves NAT, one needs to see the full contents of the SIP and the SDP. Also one would want to know why 192.168.100/24 was special, but say 10/8 wasn’t to Asterisk. That suggest that the former is directly routable from Asterisk, but the latter isn’t.

Not having the full SIP means I also can’t see CSEQ, so have to guess which OK goes with which request.

6

Could it possibly be the dreaded SIP ALG being enabled on some router between the user and the cloud PBX?

7

Hi Greg,
No sip alg features on the users router.
Also Firewall in the machines are disabled
Thanks

8

every time ive seen this happen, its been because the call answer 200-OK has the wrong IP in the contact: header

Check a sip trace - is your freepbx resending the 200-OK or Ack repeatedly? (likely with an exponential backoff retransmission of .25, .5, 1, 2, 4, 4, 4… seconds)

9

Please provide a log of a failing call including a SIP trace. At the Asterisk command prompt, type
pjsip set logger on
make a failing test call, take the Asterisk log for the call, redacted as desired, paste it at pastebin.freepbx.org and post the link here. If you are too new to post links, just post the last 8 hex characters of the URL.

10

That was my initial thought, but although the OPs trace falls far short of what is needed to properly diagnose this, it dose confirm that there are no retransmissions.

11

depends on Where the trace is from, to be honest.
is this a trace generated from the endpoint? or a sngrep on freepbx?

12

The OKs stop after the ACK, which means the ACK must have got end to end. The ACK wouldn’t have been sent if the OKs hadn’t gone end to end.

I did think about asking how the log was obtained, but the above analysis led me to the conclusion that it didn’t really matter, even though I’d always want to see the pjsip set logger on output from Asterisk, first, as that is what I’m familiar reading.

1 Like
13

Hi All,
Thank you for all the assistance, sorry didn’t respond sooner as I am on +8 GMT.
I can give the pjsip log on Monday for that users.
I tried to replicate the issue of having a 100.0/24 IP. But I am still connected and have audios both ways after the 30th second.
Thank you

14

Hi All,

Here is the PJSIP log we have created today. As usual, after 29th seconds the audio will be gone, we ended the call in 34th seconds. I changed some details with IPs and Ports for security. Hope you can help me fix this. Thanks in advance!

test2mnlpbx*CLI> pjsip set logger host
PJSIP Logging Enabled for host:
[2021-09-01 09:00:04] WARNING[18237][C-00000db3]: chan_sip.c:8130 sip_indicate: Don’t know how to indicate condition 36
<— Received SIP request (1005 bytes) from UDP::60384 —>
INVITE sip:DIALEDNUMBER@ SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPj2e4f8e4e840e4457be319253c7a16a8f
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: <sip:@ext>
Contact: “phone.ext.name” sip:[email protected]:60384;ob
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8994 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: MicroSIP/3.20.3
Content-Type: application/sdp
Content-Length: 343

v=0
o=- 3839472017 3839472017 IN IP4 192.168.100.5
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 0 101
c=IN IP4 192.168.100.5
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.5
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:2032753028 cname:1a206355542b357a

<— Transmitting SIP response (574 bytes) to UDP::60384 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj2e4f8e4e840e4457be319253c7a16a8f
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=z9hG4bKPj2e4f8e4e840e4457be319253c7a16a8f
CSeq: 8994 INVITE
WWW-Authenticate: Digest realm=“asterisk”,nonce=“1630458017/b548c9df0e414bff59e51b75b5afd6b4”,opaque=“317d6bbc0d507290”,algorithm=md5,qop=“auth”
Server: FPBX-15.0.16.81(16.13.0)
Content-Length: 0

<— Received SIP request (389 bytes) from UDP::60384 —>
ACK sip:DIALEDNUMBER@ext SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPj2e4f8e4e840e4457be319253c7a16a8f
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=z9hG4bKPj2e4f8e4e840e4457be319253c7a16a8f
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8994 ACK
Content-Length: 0

<— Received SIP request (1298 bytes) from UDP::60384 —>
INVITE sip:DIALEDNUMBER@ext SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPj28e4825b56534c60acc7d23ef8022b1a
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext
Contact: “phone.ext.name” sip:[email protected]:60384;ob
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8995 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: MicroSIP/3.20.3
Authorization: Digest username=“ext”, realm=“asterisk”, nonce=“1630458017/b548c9df0e414bff59e51b75b5afd6b4”, uri=“sip:DIALEDNUMBER@ext”, response=“959faa6dfdd86f3da375d9066ee4e7a7”, algorithm=md5, cnonce=“e67010204bb3446d8c428462c2248adc”, opaque=“317d6bbc0d507290”, qop=auth, nc=00000001
Content-Type: application/sdp
Content-Length: 343

v=0
o=- 3839472017 3839472017 IN IP4 192.168.100.5
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 0 101
c=IN IP4 192.168.100.5
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.5
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ssrc:2032753028 cname:1a206355542b357a

<— Transmitting SIP response (376 bytes) to UDP::60384 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj28e4825b56534c60acc7d23ef8022b1a
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext
CSeq: 8995 INVITE
Server: FPBX-15.0.16.81(16.13.0)
Content-Length: 0

<— Transmitting SIP response (873 bytes) to UDP:60384 —>
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj28e4825b56534c60acc7d23ef8022b1a
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
CSeq: 8995 INVITE
Server: FPBX-15.0.16.81(16.13.0)
Contact: <sip::PORT>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Content-Type: application/sdp
Content-Length: 265

v=0
o=- 3839472017 3839472019 IN IP4
s=Asterisk
c=IN IP4
t=0 0
m=audio 13970 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
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 request (896 bytes) from UDP::60384 —>
UPDATE sip::PORT SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPj5b9710ac2d7e4bb8b3dcc27a3a88bd9c
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
Contact: “phone.ext.name” sip:[email protected]:60384;ob
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8996 UPDATE
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 319

v=0
o=- 3839472017 3839472018 IN IP4 192.168.100.5
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 101
c=IN IP4 192.168.100.5
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.5
a=ssrc:2032753028 cname:1a206355542b357a
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

<— Transmitting SIP response (936 bytes) to UDP::60384 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj5b9710ac2d7e4bb8b3dcc27a3a88bd9c
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
CSeq: 8996 UPDATE
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip::PORT>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-15.0.16.81(16.13.0)
Content-Type: application/sdp
Content-Length: 241

v=0
o=- 3839472017 3839472020 IN IP4
s=Asterisk
c=IN IP4
t=0 0
m=audio 13970 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

<— Transmitting SIP response (960 bytes) to UDP::60384 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj28e4825b56534c60acc7d23ef8022b1a
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
CSeq: 8995 INVITE
Server: FPBX-15.0.16.81(16.13.0)
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact: sip:PBXPUBLICIP:PORT
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 265

v=0
o=- 3839472017 3839472019 IN IP4
s=Asterisk
c=IN IP4
t=0 0
m=audio 13970 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
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 request (385 bytes) from UDP::60384 —>
ACK sip::PORT SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPjf78e7109e7cb490dbd041a85ced8772d
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8995 ACK
Content-Length: 0

<— Received SIP request (910 bytes) from UDP::60384 —>
UPDATE sip::PORT SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPj2a7c37c04cec4bb494fdbfc7a6f3f188
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
Contact: “phone.ext.name” sip:[email protected]:60384;ob
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8997 UPDATE
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800;refresher=uac
Min-SE: 90
Content-Type: application/sdp
Content-Length: 319

v=0
o=- 3839472017 3839472020 IN IP4 192.168.100.5
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 8 101
c=IN IP4 192.168.100.5
b=TIAS:64000
a=rtcp:4001 IN IP4 192.168.100.5
a=ssrc:2032753028 cname:1a206355542b357a
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

<— Transmitting SIP response (936 bytes) to UDP::60384 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj2a7c37c04cec4bb494fdbfc7a6f3f188
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
CSeq: 8997 UPDATE
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip::PORT>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: FPBX-15.0.16.81(16.13.0)
Content-Type: application/sdp
Content-Length: 241

v=0
o=- 3839472017 3839472021 IN IP4
s=Asterisk
c=IN IP4
t=0 0
m=audio 13970 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

[2021-09-01 09:00:41] WARNING[18493][C-00000db5]: chan_sip.c:8130 sip_indicate: Don’t know how to indicate condition 36
[2021-09-01 09:00:45] WARNING[18519][C-00000db7]: chan_sip.c:8130 sip_indicate: Don’t know how to indicate condition 36
<— Transmitting SIP request (435 bytes) to UDP::60384 —>
OPTIONS sip:ext@:60384;ob SIP/2.0
Via: SIP/2.0/UDP :PORT;rport;branch=z9hG4bKPjc497338d-3742-4f1a-a947-aee41d3f4167
From: sip:ext@PBXPRIVATEIP;tag=bf16fbc3-2135-42c9-83af-4c4cb9299e66
To: sip:ext@USERPUBLICIP;ob
Contact: sip:ext@PBXPUBLICIP:PORT
Call-ID: dcddf633-7653-4d16-89ec-92e3034ff737
CSeq: 1758 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-15.0.16.81(16.13.0)
Content-Length: 0

<— Received SIP response (785 bytes) from UDP::60384 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP :PORT;rport=PORT;received=;branch=z9hG4bKPjc497338d-3742-4f1a-a947-aee41d3f4167
Call-ID: dcddf633-7653-4d16-89ec-92e3034ff737
From: sip:ext@PBXPRIVATEIP;tag=bf16fbc3-2135-42c9-83af-4c4cb9299e66
To: sip:ext@USERPUBLICIP;ob;tag=z9hG4bKPjc497338d-3742-4f1a-a947-aee41d3f4167
CSeq: 1758 OPTIONS
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Accept: application/sdp, application/pidf+xml, application/xpidf+xml, application/simple-message-summary, message/sipfrag;version=2.0, application/im-iscomposing+xml, text/plain
Supported: replaces, 100rel, timer, norefersub
Allow-Events: presence, message-summary, refer
User-Agent: MicroSIP/3.20.3
Content-Length: 0

<— Received SIP request (414 bytes) from UDP::60384 —>
BYE sip::PORT SIP/2.0
Via: SIP/2.0/UDP 192.168.100.5:60384;rport;branch=z9hG4bKPj4ccbd4de782f40a9bffe424d02a605e8
Max-Forwards: 70
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
Call-ID: 34ee1270841e4113924ed4c96f955d8a
CSeq: 8998 BYE
User-Agent: MicroSIP/3.20.3
Content-Length: 0

<— Transmitting SIP response (410 bytes) to UDP::60384 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.5:60384;rport=60384;received=;branch=z9hG4bKPj4ccbd4de782f40a9bffe424d02a605e8
Call-ID: 34ee1270841e4113924ed4c96f955d8a
From: “phone.ext.name” sip:ext@ext;tag=7621c06b95244336889dba1999c6d646
To: sip:DIALEDNUMBER@ext;tag=b23cadbb-e62f-43d2-824e-4aad436cebd8
CSeq: 8998 BYE
Server: FPBX-15.0.16.81(16.13.0)
Content-Length: 0

<— Transmitting SIP request (435 bytes) to UDP::60384 —>
OPTIONS sip:ext@USERPUBLICIP:60384;ob SIP/2.0
Via: SIP/2.0/UDP :PORT;rport;branch=z9hG4bKPj1d86df37-444b-4857-b1f0-1ce83b588122
From: sip:ext@PBXPRIVATEIP;tag=bf41c3dd-661a-4037-b8fe-5826e53f036b
To: sip:ext@USERPUBLICIP;ob
Contact: sip:ext@PBXPUBLICIP:PORT
Call-ID: 072ea381-7d81-4351-912b-61f60a0e56bb
CSeq: 4900 OPTIONS
Max-Forwards: 70
User-Agent: FPBX-15.0.16.81(16.13.0)
Content-Length: 0

<— Received SIP response (785 bytes) from UDP::60384 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP :PORT;rport=PORT;received=;branch=z9hG4bKPj1d86df37-444b-4857-b1f0-1ce83b588122
Call-ID: 072ea381-7d81-4351-912b-61f60a0e56bb
From: sip:ext@PBXPRIVATEIP;tag=bf41c3dd-661a-4037-b8fe-5826e53f036b
To: sip:ext@USERPUBLICIP;ob;tag=z9hG4bKPj1d86df37-444b-4857-b1f0-1ce83b588122
CSeq: 4900 OPTIONS
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Accept: application/sdp, application/pidf+xml, application/xpidf+xml, application/simple-message-summary, message/sipfrag;version=2.0, application/im-iscomposing+xml, text/plain
Supported: replaces, 100rel, timer, norefersub
Allow-Events: presence, message-summary, refer
User-Agent: MicroSIP/3.20.3
Content-Length: 0

[2021-09-01 09:01:47] WARNING[18901][C-00000dbb]: chan_sip.c:8130 sip_indicate: Don’t know how to indicate condition 36

15

Check your ports and SIP channel usage and port forwarding , you have both chan_pjsip and chan_sip apparent in your log . . .

16

hi @dicko,

I am totally noob in freepbx as this was my first experience. can you help me how to do it on detail? we are using pjsip in our extensions. i changed the pjsip port to not 5060.

17

I would start by disableing chan_sip and relying on chan_pjsip being on port 5060 so only using pjsip for trunks and extensions, if needed forward udp 5060 and 10000-19999 to your pbx at your router, (if not needed it shouldn’t do any harm)

18

thanks dicko, i will try that. how can i disable chan_sip in GUI?
also i did change the port because the pbx is in the cloud. and no port forward in azure i think?
thanks

19

the usable sip transports are defined in the advanced settings.

I can’t speak to azure but likely unnecessary to forrward anything, when everything is working on 5060 , that would be a good time to move it outside of 5000-5999, consider tcp over udp, best to use tls when possible

Any ALG on your 192.168.100.0/24 router should also be disabled

20

The log that you posted looks ‘ok’, but is so badly garbled that I can’t be sure. In an earlier post I asked:

This is important in two ways: First, the forum removes certain characters relevant to the protocol. Next, the Asterisk log (in /var/log/asterisk/full) contains, in addition to the SIP trace, events detected and actions taken by Asterisk, useful for understanding the problem. Also, when you redact information, you should use an editor to replace all occurrences of some string with another whose meaning is clear.

For example, if your PBX has public IP 1.2.3.4, you might replace 1.2.3.4 with PBXPUBLICIP everywhere. I’d expect the To header of the initial INVITE to be something like:
To: <sip:DIALEDNUMBER@PBXPUBLICIP>;tag=as12341234
but all I see in the forum is
To: <sip:@ext>
basically garbage.

So, please make another failing call with pjsip logger on and paste the complete Asterisk log for the call. Before making the call, set MicroSIP to also record a log – in Settings, check Enable Log File and click Save. After the call (assuming Windows), right-click the MicroSIP icon in the taskbar notification area and select View Log File. Redact and paste that at pastebin.freepbx.org and post the link. It’s possible that we won’t see any trouble at either end (for example if the router at the client end is terminating the RTP’s NAT association) and we’ll need to do packet captures to confirm what is happening. Unfortunately, @dicko 's suggestion of using TCP or TLS may not help, because the RTP is still being sent by UDP.