Private IP in 3CX Server's SDP to Remote Extension

[dcooper]

Here is the setup:

3CX Server v14 running on AWS instance with private IP address with NAT to static public IP address.

Remote extensions running behind NATS using STUN or SIP Proxies to register with 3CX Server.

The problem:

The audio streams from the server to remote extensions is being received, but the audio stream from the extension to the server is getting lost.

After quite a bit of testing I have discovered why, but I am unable to find a solution.

What is happening is that the 3CX server is sending it's private IP in the SDP information when the call is set up, causing the remote extensions to send their RTP packet stream to that address instead of the 3CX server's public IP, resulting in those outgoing packets getting lost.

I have verified this by running tcpdump on the external interface of my firewall. I can see the incoming RTP packets from the 3CX server's public IP and the outgoing RTP packets from the extension being sent to the 3CX server's private IP instead of the server's public IP.

Looking at the SDP in the call's SIP packets shows that the 3CX server is supplying the internal interface private IP address in the call setup.

Like the following:

---BUFFER DUMP follows---
  53 49 50 2f 32 2e 30 20 32 30 30 20 4f 4b 0d 0a SIP/2.0 200 OK..
  56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 Via: SIP/2.0/UDP
  20 36 37 2e 31 38 32 2e 31 36 30 2e 31 38 3a 35  67.182.160.18:5
  30 36 30 3b 62 72 61 6e 63 68 3d 7a 39 68 47 34 060;branch=z9hG4
  62 4b 64 34 35 65 33 62 30 39 32 31 36 39 35 38 bKd45e3b09216958
  34 39 33 65 66 39 33 64 31 38 64 63 62 32 30 39 493ef93d18dcb209
  62 34 0d 0a 56 69 61 3a 20 53 49 50 2f 32 2e 30 b4..Via: SIP/2.0
  2f 55 44 50 20 31 39 32 2e 31 36 38 2e 34 39 2e /UDP 192.168.49.
  34 34 3a 35 30 36 30 3b 62 72 61 6e 63 68 3d 7a 44:5060;branch=z
  39 68 47 34 62 4b 31 30 37 39 33 39 36 39 36 38 9hG4bK1079396968
  0d 0a 43 6f 6e 74 61 63 74 3a 20 3c 73 69 70 3a ..Contact: <sip:
  39 39 39 40 35 34 2e 31 37 34 2e 31 36 36 2e 37 [email protected]
  37 3a 35 30 36 30 3e 0d 0a 54 6f 3a 20 3c 73 69 7:5060>..To: <si
  70 3a 39 39 39 40 70 68 2e 73 6d 61 72 74 65 72 p:[email protected]
  70 61 72 6b 69 6e 67 73 6f 6c 75 74 69 6f 6e 73 parkingsolutions
  2e 63 6f 6d 3a 35 30 36 30 3e 3b 74 61 67 3d 61 .com:5060>;tag=a
  65 37 34 64 64 31 35 0d 0a 46 72 6f 6d 3a 20 22 e74dd15..From: "
  44 61 6e 20 43 6f 6f 70 65 72 22 3c 73 69 70 3a Dan Cooper"<sip:
  33 39 39 40 70 68 2e 73 6d 61 72 74 65 72 70 61 [email protected]
  72 6b 69 6e 67 73 6f 6c 75 74 69 6f 6e 73 2e 63 rkingsolutions.c
  6f 6d 3a 35 30 36 30 3e 3b 74 61 67 3d 34 30 31 om:5060>;tag=401
  30 33 37 35 32 37 0d 0a 43 61 6c 6c 2d 49 44 3a 037527..Call-ID:
  20 32 5f 33 32 39 36 31 32 34 39 35 38 40 31 39  2_3296124958@19
  32 2e 31 36 38 2e 34 39 2e 34 34 0d 0a 43 53 65 2.168.49.44..CSe
  71 3a 20 32 20 49 4e 56 49 54 45 0d 0a 41 6c 6c q: 2 INVITE..All
  6f 77 3a 20 49 4e 56 49 54 45 2c 20 41 43 4b 2c ow: INVITE, ACK,
  20 43 41 4e 43 45 4c 2c 20 4f 50 54 49 4f 4e 53  CANCEL, OPTIONS
  2c 20 42 59 45 2c 20 52 45 47 49 53 54 45 52 2c , BYE, REGISTER,
  20 53 55 42 53 43 52 49 42 45 2c 20 4e 4f 54 49  SUBSCRIBE, NOTI
  46 59 2c 20 52 45 46 45 52 2c 20 49 4e 46 4f 2c FY, REFER, INFO,
  20 4d 45 53 53 41 47 45 0d 0a 43 6f 6e 74 65 6e  MESSAGE..Conten
  74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 t-Type: applicat
  69 6f 6e 2f 73 64 70 0d 0a 53 75 70 70 6f 72 74 ion/sdp..Support
  65 64 3a 20 72 65 70 6c 61 63 65 73 0d 0a 55 73 ed: replaces..Us
  65 72 2d 41 67 65 6e 74 3a 20 33 43 58 50 68 6f er-Agent: 3CXPho
  6e 65 53 79 73 74 65 6d 20 31 34 2e 30 2e 34 35 neSystem 14.0.45
  38 32 36 2e 32 32 38 20 28 34 35 30 30 38 29 0d 826.228 (45008).
  0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
  20 32 33 38 0d 0a 0d 0a 76 3d 30 0d 0a 6f 3d 33  238....v=0..o=3
  63 78 50 53 20 34 33 34 30 39 33 36 38 36 37 38 cxPS 43409368678
  34 20 31 30 38 39 36 38 30 31 37 39 32 31 20 49 4 108968017921 I
  4e 20 49 50 34 20 31 37 32 2e 33 31 2e 32 33 2e N IP4 172.31.23.
  31 35 35 0d 0a 73 3d 33 63 78 50 53 20 41 75 64 155..s=3cxPS Aud
  69 6f 20 63 61 6c 6c 0d 0a 63 3d 49 4e 20 49 50 io call..c=IN IP
  34 20 31 37 32 2e 33 31 2e 32 33 2e 31 35 35 0d 4 172.31.23.155.
  0a 74 3d 30 20 30 0d 0a 6d 3d 61 75 64 69 6f 20 .t=0 0..m=audio 
  39 30 30 30 20 52 54 50 2f 41 56 50 20 30 20 38 9000 RTP/AVP 0 8
  20 31 30 31 0d 0a 61 3d 72 74 70 6d 61 70 3a 30  101..a=rtpmap:0
  20 50 43 4d 55 2f 38 30 30 30 0d 0a 61 3d 72 74  PCMU/8000..a=rt
  70 6d 61 70 3a 38 20 50 43 4d 41 2f 38 30 30 30 pmap:8 PCMA/8000
  0d 0a 61 3d 72 74 70 6d 61 70 3a 31 30 31 20 74 ..a=rtpmap:101 t
  65 6c 65 70 68 6f 6e 65 2d 65 76 65 6e 74 2f 38 elephone-event/8
  30 30 30 0d 0a 61 3d 66 6d 74 70 3a 31 30 31 20 000..a=fmtp:101 
  30 2d 31 35 0d 0a                               0-15..          
---end of BUFFER DUMP---

Which has the SDP information:

o=3cxPS 434093686784 108968017921 IN IP4 172.31.23.155
s=3cxPS Audio call
c=IN IP4 172.31.23.155
t=0 0
m=audio 9000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8
a=fmtp:101 0-15

172.31.23.155 is the private IP address of the 3CX server.

I have tried the following:

Settings->Network->STUN Server setting both STUN Server Requests On and Off with the Static Public IP filled in.

Setting the Extensions->Other->PBX Delivers Audio to On

Setting Settings->General->Global Options->Send Media to IP and port of REGISTER to On

Nothing seems to change this behavior. There must be some setting I'm missing that causes 3CX to plug in the public IP into
the SDP for calls with external extensions.

I would really appreciate any ideas or help.

Thanks!

 

[lneblett]

DO a search of the forum for Amazon as there have been some posts in the past. There had been some issues, but if memory serves some users have reported success. I cannot speak directly to it as I do not use, but it might be related to a router that has the SIP ALG enabled.

For me, I would disable the STUN and point directly to the static IP.

Did you run the firewall checker?

You can also look at the SIP provider settings in 3CX and set how or to what IP you want the SDP to have on the advanced page. I do not know if this is exclusive to only the trunks or to the extensions as well.

 

[dcooper]

Thanks for your reply.

I saw that thread you are referencing about Amazon AWS. In that case it looks like just turning off STUN Requests and setting a static public IP fixed the problem.

I've tried both the 3CX server in STUN mode and with the STUN turned off and the static public ip set. This doesn't seem to effect the SDP output as listed above.

To explain this further, I can call the 3CX voicemail from an external extension and I will hear the audio from the voice mail IVR. However, the audio stream from the extension to the 3CX server is getting lost due to the bad SDP and so no DTMF tones are getting through. Additionally the echo test doesn't work for the same reason. I tracked it down to the 3CX server using the server's private IP for it's RTP endpoint instead of it's public IP address in the SDP. I'm thinking that the 3CX server is defaulting to assuming that extensions are on it's private network.

The SIP trunks configuration looks like it has better flexibility. It has settings for explicitly specifying the IP address to use in the Contact and Connection fields, which I have done. I have not found a way to accomplish that for extensions. I've tried setting the MSEXTERNALINTERFACE to the public IP, I've tried setting up remote provisioning for the extension, so that 3CX server knows it is an external extension, but this problem persists. Is there a way of reporting an issue as a possible bug?

 

[Sopock]

Until that fix arrives, I would first try to register new softphone(3CXPhone) with built in 3CXtunnel.

Next step would be installing the 3CX SBC for Raspberry Pi :idea: