[qc7]

3CX states support for TLS/SRTP and also handles SIP over TCP (instead of the default UDP).

There seems to be a problem with this when used with external devices (devices not reachable on the local LAN). I'll get to the problem, but first a quick overview.

I have followed the instructions here and setup TLS/SRTP and it does indeed work great for local phones (on the LAN). SIP over TCP (unencrypted) also works fine for local devices. Neither of these work with external phones.

So out of the three ways to handle SIP signalling, only the FIRST one works for external devices:

- SIP over UDP -- port 5060 (works for internal and external)
- SIP over TCP -- port 5060 (works for internal only)
- SIP over TLS -- port 5061 (works for internal only)

Of course TLS is just a specialised case of TCP -- still a TCP connection but with the content wrapped up in encryption -- so it makes sense that the problems I'm experiencing apply equally to plain TCP or TLS. For now I have disabled TLS and am doing my testing with straight vanilla TCP on port 5060 which is something that is mature and should work great.

I should add that the other part of the equation in securing calls, SRTP, works fine for both internal and external calls. I've been able to reduce the problem down to TCP-based connections for the SIP signalling, whether they are TLS or just plain unencrypted.

Before anyone points out anything about firewalling issues, I have ports 5060, 5061, and all the other required ports for the actual audio channels all forwarded (and for TCP too in the case of 5060 and 5061). The phone system is behind a connection with a static IP and is configured to use this in SIP invites, etc (in all places where the public IP is supposed to be specified). STUN is disabled as it's not needed, but I've tried with it on and the problem still exists.

When using TCP-based SIP signalling, external phones register fine and can even place calls. But the audio doesn't work. Switching back to SIP over UDP makes everything work fine again for these external devices.

From inspecting the logs, the problem appears to be that 3CX is sending the wrong IP when setting up the RTP connection -- but ONLY when non-UDP SIP signalling is used.

The logging is set to verbose. The calls were simply an extension phone calling the voice mail system (from outside the local LAN). For a call from an external device set to use UDP SIP signalling (which works fine) part of the logs show:

01:28:16.575 [MS210003] C:7.1:Answer provided. Connection(transcoding mode[unsecure]):<PUBLIC_IP_REMOVED>:9004(9005)
01:28:16.575 [MS210001] C:7.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40622(40623)

You can see that the public IP was correctly specified by 3CX for setting up the RTP connection and consequently the call worked correctly with full audio heard both ways.

However, as soon as the phone is changed to use TCP-based SIP signalling, the same part of the logs show:

01:30:23.108 [MS210003] C:8.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.7.7:9122(9123)
01:30:23.108 [MS210001] C:8.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40624(40625)

Notice how the IP that 3CX gave out was the internal IP (192.168.7.7) of the phone system. Consequently the RTP connection can never be setup and after a timeout 3CX complains in its logs that no RTP packets were received and drops the call.

The ONLY difference between these two scenarios is whether UDP-based or TCP-based SIP signalling was used. As I said, the firewalling is definitely setup right. By switching to SIP over UDP instead of TCP, these same external devices work fine -- which proves that the firewalling is fine, since the same ports of 9000 to 9049 are used for the audio legs no matter whether the SIP signalling is UDP or TCP. And remember that the phones do register fine even when TCP or TLS SIP is used. And they even place the calls fine. It's just that the RTP connection can never be setup, as 3CX is sending the internal IP.

So it seems to be a bug in that whenever TCP SIP signalling is used, 3CX no longer uses the public IP you've specified for SIP invites, but instead reverts to using the internal IP. And of course this isn't going to work for devices located off the local LAN.

Of course it's hard for me to believe that such a bug would really exist, because then anyone using TLS would also be having this problem for external devices (and it's external devices where you normally care more about security).

So why is this happening, and has anyone else noticed this behaviour? Put another way, can anyone confirm that they have TLS or TCP SIP signalling successfully working for external phones?

I'm using the latest build of 3CX version 9, and it's a fully-licensed installation (but the same behaviour was observed when I initially was running the trial/free version). The phones I am using as external devices are the Counterpath Bria softphone app running on iPhones. This softphone supports TLS/SRTP and works great with 3CX.

BTW... the reason why it's important to be able to use TCP-based SIP signalling for external devices is because:
1) that's the only way to get SIP signalling encryption (TLS is inherently TCP-based and without that SRTP is much less effective since the keys are broadcast in plaintext)
2) UDP SIP signalling on external phones requires very regular keep-alive packets to be broadcast to reliably stay connected to the server, and this drains battery life. So even if you don't care about encryption, you probably do care about battery life.

Thanks for any insight!

[qc7]

Hmmm, by looking at the logs again, it's pretty obvious that 3CX is somehow determining the calls to be from internal phones whenever TCP SIP is used. It's not just the fact that it specifies the internal IP instead of the public one to setup the RTP connections, but it's also using a port from the pool of ones reserved for internal calls. In my first log snippet in the last post you can see that it used ports 9004/9005 for the SIP over UDP call, but for the SIP over TCP call it assigned ports 9122/9123 (I have 3CX configured to use ports 9100 to 9199 for internal RTP connections, "factory" default is 7000 to 7049).

So the question is, why does 3CX think that calls are internal when they are generated by a phone using the TCP variant of SIP, even when those phones are definitely external and not reachable on the local LAN.

Now I'm wondering if my firewall is replacing the source IP of those incoming TCP SIP registration connections to be the IP of the firewall, rather than leaving it as the external IP. This certainly doesn't happen for UDP packets that are forwarded, but could it be happening for incoming TCP connections? Firewall is a SnapGear (now owned by MacCafee) SG box.

More to investigate...

But if anyone can confirm that regular TCP-based SIP does indeed work fine for them with 3CX for external devices, that would at least be comforting.

[captivateglobal]

IIRC, I had a fairly similar issue a while back with an SG530.

Basically it had to do with session establishment for the NAT Traversal module. What was happening is when the SG device was booting, but before it had established WAN/VPN connections, it was receiving and servicing requests for packets. It would then create a TCP session with the local IP's only, attempt to route them, then tell the PBX that the destination was unreachable.

When the internet came up, the packets would then get routed to the correct interface, however the session properties for that TCP session would continually mangle the packet so that it's source was the local IP for the router (because that was the only interface it had when the session was initially created, therefore all packets in that session should use that source, something to do with packet spoofing protection?).

After a lot of work, we managed to make the internet connect directly after boot, but there is still a split-second occurance where it can re-occur. It did so a number of months later, so we ended up chucking out the SG routers and going with a DrayTek (which then had it's own issues but that was just an over-eager SIP ALG).

Not sure if it's got anything to do with your issue - but it might help!

[qc7]

Thanks captivateglobal.

This is an SG560 and the internet connection is constantly up with a static IP over regular ethernet, fed from fibre into the building.

I've confirmed that the TCP streams coming in via port forwarding are maintaining their correct source address, as you'd expect with regular DNAT. So 3CX is seeing the real address of external devices that register over TCP-based SIP, and this is confirmed in the logs. But for some reason it just insists on treating these connections as internal and publishing its internal IP to them when setting up the RTP connection. Switching the external devices back to UDP SIP makes the problem go away.

So at this stage I really am at a loss. Can anyone confirm that they're successfully running with TCP or TLS SIP from external devices? Anyone at all?

The only other thing I can think of now is to give the 3CX box a real public IP and bypass the firewall altogether. I can't really do this, other than for testing, because it will cause some other architectural issues. And it shouldn't need to be done. Unless I'm mistaken this really is starting to look like a bug. The companies who *are* successfully running TLS/TCP with 3CX may have (one of) the 3CX interface(s) directly on the internet, in which case this issue would probably not show up. If not using that kind of setup it just doesn't seem possible to get TCP/TLS SIP to work, which is a real shame because there's no technical reason why it couldn't work. Just a wrong flag being set somewhere in the 3CX code.

[archie]

Force your external phone to specify its public IP in contact when using TCP transport.

[qc7]

Force your external phone to specify its public IP in contact when using TCP transport.

Hi Archie,

Thanks for your assistance.

The external phone IS specifying its public IP. But 3CX appears to refuse to use it when TCP or TLS SIP is employed.

I'll include some complete call logs.

For security reasons, the following substitutions have been made on these logs:
{PBX_PUBLIC_IP} is the public IP of the PBX, which is static and reachable from anywhere.
{PBX_SIP_DOMAIN} is the domain (eg. sip.example.com) and it resolves to the above public IP.
{EXTERNAL_PHONE_PUBLIC_IP} is the public IP that the external phone had at the time.

The internal IP of the PBX is 192.168.7.7 and this is the only interface on that machine. STUN is off as the public IP is static and correctly specified everywhere it should be (but I've also tried with STUN on and it makes no difference).

Ports 9000-9099 are configured for external RTP, and 9100-9199 for internal.

These calls were all of extension 7111 calling voice mail (extension 9999).

In this first example, which resulted in NO audio, the phone was calling from an external IP and was set to use TCP SIP:

Code: Select all

01:30:49.172  Currently active calls [none]
01:30:28.343  [CM504002]: Ext.7111: a contact is unregistered. Contact(s): []
01:30:22.812  [MS105000] C:1.1: No RTP packets were received:remoteAddr={EXTERNAL_PHONE_PUBLIC_IP}:4000,extAddr=0.0.0.0:0,localAddr=192.168.7.7:9100
01:30:17.171  Currently active calls [none]
01:30:01.483  [CM503008]: Call(1): Call is terminated
01:30:01.483  [CM503021]: Call(1): ACK is not received
01:29:45.171  Currently active calls - 1: [1]
01:29:29.420  [CM503007]: Call(1): Device joined: sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980
01:29:29.420  [CM503007]: Call(1): Device joined: sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:49156;transport=TCP
01:29:29.420  [MS210003] C:1.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.7.7:9100(9101)
01:29:29.420  [MS210001] C:1.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40610(40611)
01:29:29.420  Remote SDP is set for legC:1.2
01:29:29.420  [CM505001]: Ext.9999: Device info: Device Identified: [Man: 3CX Ltd.;Mod: Voice Mail Menu;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Voice Mail Menu] PBX contact: [sip:9999@127.0.0.1:5060]
01:29:29.420  [CM503002]: Call(1): Alerting sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980
01:29:29.264  [CM503025]: Call(1): Calling Ext:Ext.9999@[Dev:sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980]
01:29:29.264  [MS210002] C:1.2:Offer provided. Connection(transcoding mode): 127.0.0.1:9102(9103)
01:29:29.217  [CM503004]: Call(1): Route 1: Ext:Ext.9999@[Dev:sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980]
01:29:29.217  [CM503010]: Making route(s) to <sip:9999@{PBX_SIP_DOMAIN}>
01:29:29.217  [MS210000] C:1.1:Offer received. RTP connection: {EXTERNAL_PHONE_PUBLIC_IP}:4000(4001)
01:29:29.217  Remote SDP is set for legC:1.1
01:29:29.217  [CM505001]: Ext.7111: Device info: Device Identified: [Man: Counterpath;Mod: Bria;Rev: General] Capabilities:[reinvite, no-replaces, unable-no-sdp, recvonly] UserAgent: [Bria 1.1.3] PBX contact: [sip:7111@192.168.7.7:5060;transport=TCP]
01:29:29.217  [CM503001]: Call(1): Incoming call from Ext.7111 to <sip:9999@{PBX_SIP_DOMAIN}>
01:29:29.202  [CM500002]: Info on incoming INVITE:
  INVITE sip:9999@{PBX_SIP_DOMAIN} SIP/2.0
  Via: SIP/2.0/TCP {EXTERNAL_PHONE_PUBLIC_IP}:49160;rport=49160;branch=z9hG4bKPjE4TSvsz8uNr65SRuWmyHc4q0Q5N1BVzo
  Max-Forwards: 70
  Contact: <sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:49156;transport=TCP>
  To: <sip:9999@{PBX_SIP_DOMAIN}>
  From: <sip:7111@{PBX_SIP_DOMAIN}>;tag=egwuu9HkgsPGXNe7EIDF2BmUQmj2sdth
  Call-ID: Der5t2F7vjAtnl4eVTc97m7eY6HQgXaM
  CSeq: 14128 INVITE
  Session-Expires: 1800
  Min-SE: 90
  Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
  Proxy-Authorization: Digest username="7111",realm="3CXPhoneSystem",nonce="414d535c02ab225812:694ece5e1591063cad18b09be9147ad2",uri="sip:9999@{PBX_SIP_DOMAIN}",response="36bbc063ff8b406e940222448404d0db",algorithm=MD5
  Supported: replaces, 100rel, timer, norefersub
  User-Agent: Bria 1.1.3
  Content-Length: 0
 
01:29:17.061  [CM504001]: Ext.7111: new contact is registered. Contact(s): [sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:49156;transport=TCP/7111]
01:29:13.170  Currently active calls [none]


You can see in the above logs that 3CX treated the call as an internal call, even though it clearly wasn't.

In this second example, which DID work, the only change was that the phone was set to use UDP SIP. The phone was still calling from an external IP:

Code: Select all

01:32:57.173  Currently active calls [none]
01:32:29.204  [CM504002]: Ext.7111: a contact is unregistered. Contact(s): []
01:32:25.173  Currently active calls [none]
01:32:12.704  [CM503008]: Call(2): Call is terminated
01:32:00.860  Session 168 of leg C:2.1 is confirmed
01:32:00.673  [CM503007]: Call(2): Device joined: sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980
01:32:00.673  [CM503007]: Call(2): Device joined: sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:57133
01:32:00.673  [MS210003] C:2.1:Answer provided. Connection(transcoding mode[unsecure]):{PBX_PUBLIC_IP}:9000(9001)
01:32:00.657  [MS210001] C:2.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40612(40613)
01:32:00.657  Remote SDP is set for legC:2.2
01:32:00.657  [CM505001]: Ext.9999: Device info: Device Identified: [Man: 3CX Ltd.;Mod: Voice Mail Menu;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Voice Mail Menu] PBX contact: [sip:9999@127.0.0.1:5060]
01:32:00.657  [CM503002]: Call(2): Alerting sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980
01:32:00.516  [CM503025]: Call(2): Calling Ext:Ext.9999@[Dev:sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980]
01:32:00.516  [MS210002] C:2.2:Offer provided. Connection(transcoding mode): 127.0.0.1:9104(9105)
01:32:00.469  [CM503004]: Call(2): Route 1: Ext:Ext.9999@[Dev:sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980]
01:32:00.469  [CM503010]: Making route(s) to <sip:9999@{PBX_SIP_DOMAIN}>
01:32:00.469  [MS210000] C:2.1:Offer received. RTP connection: {EXTERNAL_PHONE_PUBLIC_IP}:4002(4003)
01:32:00.469  Remote SDP is set for legC:2.1
01:32:00.469  [CM505001]: Ext.7111: Device info: Device Identified: [Man: Counterpath;Mod: Bria;Rev: General] Capabilities:[reinvite, no-replaces, unable-no-sdp, recvonly] UserAgent: [Bria 1.1.3] PBX contact: [sip:7111@{PBX_PUBLIC_IP}:5060]
01:32:00.469  [CM503001]: Call(2): Incoming call from Ext.7111 to <sip:9999@{PBX_SIP_DOMAIN}>
01:32:00.454  [CM500002]: Info on incoming INVITE:
  INVITE sip:9999@{PBX_SIP_DOMAIN} SIP/2.0
  Via: SIP/2.0/UDP {EXTERNAL_PHONE_PUBLIC_IP}:57133;rport=57133;branch=z9hG4bKPjtm7gTMheMIQK3Xs37mOVlPtK5KbOeYza
  Max-Forwards: 70
  Contact: <sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:57133>
  To: <sip:9999@{PBX_SIP_DOMAIN}>
  From: <sip:7111@{PBX_SIP_DOMAIN}>;tag=hNB8PhUIvk883kVYfZBYHTfHHZHM.F.9
  Call-ID: Bbswf7pEhPPlXLLUzO0hIwbAVdBcJWB.
  CSeq: 8434 INVITE
  Session-Expires: 1800
  Min-SE: 90
  Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
  Proxy-Authorization: Digest username="7111",realm="3CXPhoneSystem",nonce="414d535c02ab22f018:0fcd2809ad22a1a00468fcb6555b3681",uri="sip:9999@{PBX_SIP_DOMAIN}",response="470291ad1bbf54cca1b9c7c4e99de171",algorithm=MD5
  Supported: replaces, 100rel, timer, norefersub
  User-Agent: Bria 1.1.3
  Content-Length: 0
 
01:31:53.172  Currently active calls [none]
01:31:51.391  [CM504001]: Ext.7111: new contact is registered. Contact(s): [sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:57133/7111]
01:31:21.172  Currently active calls [none]


For this final example, which also worked, the phone is set back to TCP SIP, but also moved onto the local LAN. This demonstrates that TCP SIP does indeed work fine for internal calls:

Code: Select all

01:36:09.176  Currently active calls [none]
01:35:40.160  [CM504002]: Ext.7111: a contact is unregistered. Contact(s): []
01:35:37.176  Currently active calls [none]
01:35:33.488  [CM503008]: Call(3): Call is terminated
01:35:20.738  Session 235 of leg C:3.1 is confirmed
01:35:20.628  [CM503007]: Call(3): Device joined: sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980
01:35:20.628  [CM503007]: Call(3): Device joined: sip:7111@192.168.7.101:49167;transport=TCP
01:35:20.628  [MS210003] C:3.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.7.7:9106(9107)
01:35:20.628  [MS210001] C:3.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40614(40615)
01:35:20.628  Remote SDP is set for legC:3.2
01:35:20.613  [CM505001]: Ext.9999: Device info: Device Identified: [Man: 3CX Ltd.;Mod: Voice Mail Menu;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Voice Mail Menu] PBX contact: [sip:9999@127.0.0.1:5060]
01:35:20.613  [CM503002]: Call(3): Alerting sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980
01:35:20.472  [CM503025]: Call(3): Calling Ext:Ext.9999@[Dev:sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980]
01:35:20.472  [MS210002] C:3.2:Offer provided. Connection(transcoding mode): 127.0.0.1:9108(9109)
01:35:20.425  [CM503004]: Call(3): Route 1: Ext:Ext.9999@[Dev:sip:9999@127.0.0.1:40600;rinstance=9708491b34a52980]
01:35:20.425  [CM503010]: Making route(s) to <sip:9999@{PBX_SIP_DOMAIN}>
01:35:20.425  [MS210000] C:3.1:Offer received. RTP connection: 192.168.7.101:4000(4001)
01:35:20.425  Remote SDP is set for legC:3.1
01:35:20.425  [CM505001]: Ext.7111: Device info: Device Identified: [Man: Counterpath;Mod: Bria;Rev: General] Capabilities:[reinvite, no-replaces, unable-no-sdp, recvonly] UserAgent: [Bria 1.1.3] PBX contact: [sip:7111@192.168.7.7:5060;transport=TCP]
01:35:20.425  [CM503001]: Call(3): Incoming call from Ext.7111 to <sip:9999@{PBX_SIP_DOMAIN}>
01:35:20.410  [CM500002]: Info on incoming INVITE:
  INVITE sip:9999@{PBX_SIP_DOMAIN} SIP/2.0
  Via: SIP/2.0/TCP 192.168.7.101:49168;rport=49168;branch=z9hG4bKPjnTyh6Jx7kond0LnbJ-pY2ysorgjthd0r;received=192.168.7.1
  Max-Forwards: 70
  Contact: <sip:7111@192.168.7.101:49167;transport=TCP>
  To: <sip:9999@{PBX_SIP_DOMAIN}>
  From: <sip:7111@{PBX_SIP_DOMAIN}>;tag=xtgajfIHgFQh1D5.0dovgXKmEYipjPYK
  Call-ID: 9Tn4xRp6P2R-MPCq4FUllvIpOWBGtQ0P
  CSeq: 20535 INVITE
  Session-Expires: 1800
  Min-SE: 90
  Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
  Proxy-Authorization: Digest username="7111",realm="3CXPhoneSystem",nonce="414d535c02ab23b886:671cd370f585b825145805490ec7110b",uri="sip:9999@{PBX_SIP_DOMAIN}",response="701337eafd43ed9e61cafc51de5855fd",algorithm=MD5
  Supported: replaces, 100rel, timer, norefersub
  User-Agent: Bria 1.1.3
  Content-Length: 0
 
01:35:14.269  [CM504001]: Ext.7111: new contact is registered. Contact(s): [sip:7111@192.168.7.101:49167;transport=TCP/7111]
01:35:05.175  Currently active calls [none]


You can see in the above logs that the phone is clearly registering with its public IP (when not on the local LAN), and that everything does indeed work fine with UDP SIP. But for some strange reason, as soon as TCP SIP is enabled, 3CX treats the registrations/calls as internal even though they are not and despite the fact that the phone has correctly registered with its public IP. The same happens if TLS is enabled on the phone.

Firewalling is fine, otherwise the successful calls wouldn't have audio, and/or registration wouldn't work, which they do in all cases.

I'm truly baffled by this. Any help is greatly appreciated. I'm using a licensed version of the latest build of version 9.

Regards.

[archie]

I need to see trace log of 3CXPhoneSystem in verbose mode for external IP TCP registration and call.
arthur at 3cx,com

[swanny]

I am having Similar Issues.

I am using the Free Edition for Testing at the Moment.

I am just trying to use the TCP Tunnel for Extensions and also trying to use the TCP Tunnel with the Bride between 2 test Servers (One is my XP Laptop at Home)

I have put the Test Servers both in the DMZ on the Broadband Devices i am using, 1 is a BT Box, the other is my LinkSys at home.

All Registrations are failing for Extensions and the Bridges when trying to use TCP, they work ok on UDP inside or outside the LAN.

[captivateglobal]

The crux of the issue is below. As you can see, TCP calls are answered on the internal ports. Basically it looks like when it's using TCP as a transport, it picks the internal ports regardless of the location of the contact.

The UDP Call from external IP:
[CM503007]: Call(2): Device joined: sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:57133
[MS210003] C:2.1:Answer provided. Connection(transcoding mode[unsecure]):{PBX_PUBLIC_IP}:9000(9001)

The TCP Call from external IP:
[CM503007]: Call(1): Device joined: sip:7111@{EXTERNAL_PHONE_PUBLIC_IP}:49156;transport=TCP
[MS210003] C:1.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.7.7:9100(9101)

The TCP Call from internal IP:
[CM503007]: Call(3): Device joined: sip:7111@192.168.7.101:49167;transport=TCP
[MS210003] C:3.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.7.7:9106(9107)

[archie]

Looks like a bug in SIP server. I will investigate more. Thanks for info.

[qc7]

Yes, I sent Archie a full trace log (more comprehensive than what I posted above) about 24 hours ago. I assume you got that OK, Archie? Thanks heaps for taking a look at this issue.

Regards.

[archie]

I assume you got that OK, Archie?

Yes, I've got it. I see the problem and think how to fix it in the way to not break anything else.

[himanshus]

Thank you for posting this thread.

We have been experiencing this issue since version 6.x of 3CX and always thought it was something by design and never thought of it as a possible bug.

[archie]

The bug is fixed and the fix is being tested in our test lab. Should be available with next update.

One comment about the fix, though.
The fix doesn't change IP in PBX's Contact (it is still local IP, but who cares since TCP or TLS connection is already established). The fix just makes PBX to use external range of media ports in SDP.

[qc7]

That's great news Archie! Is there an approximate time of when this update would be available?

Thanks a lot for your attention to this.

Regards.