Handsets Calling Themselves

[Michael Greco]

We have noticed that all our systems have these phantom calls originating from an extension back to itself.

Example, extension 1012 will place a call to 1012-lri1f131k7rf1
User Agent on the invite shows its the 3CXPhoneSYstem 16.x.x.xxx

This happens on all handsets, doesn't matter brand. (We are a Polycom and Snom shop)

This invite, originating from the pbx, is sent at exactly 5 minute intervals.
Almost like some type of keep alive.

Anyone seen this behavior?

 

[leejor]

Have you looked over the 3CX Activity Log, for one of these calls, to see what is actually happening within 3CX?

 

[JohnS_3CX]

Hi Michael,

We need to know your PBX version, specific models that face the issue, the firmware version they use, and whether you provisioned them using a 3CX supported method following our guides and with no custom templates in the mix.

If something is off track, or there have been unforseen modifications, its quite possible that phones ring when receiving invites from the PBX that are not meant for calls but rather for other functions such as CSTA.

Inspecting one of those invites via packet capture, should reveal exactly what the content type is and where it originated from.

 

[Michael Greco]

Did some research on this and it appears this is related to CSTA. We use Snom handsets which are on the supported list for this feature in 3CX.

The problem isn't that the phones ring, in fact they do not ring.

The problem is this call is placed and never dropped. You can see the invite go out, the ack and ok going on and on, never is there a bye to close out the call. This is what we are fighting. Our SBC sees this call that is never dropping and in turn our cdr collection for billing shows these long standing calls.

Of course a non 3CX sbc is not supported so we get told the standard response (just like above) "modifications" and we wont help. SIP is a standard, you establish a call and never tear it down then you get what we are seeing.

Disabling CSTA for the Snom handsets, per the Settings - Parameters - CSTA_USER_AGENTS is where we are heading. And heading there alone as "not standard"

 

[JohnS_3CX]

You already understand then that it is out of the scope of your PBX.

Check if your SBC can differentiate between content types. For example

Content-Type: application/csta+xml
Content-Type: application/dialog-info+xml
Content-Type: application/sdp

If it does, maybe you can set it to ignore certain types of SIP sessions in case this helps you.

 

[Michael Greco]

Yes, this is confirmed resolved.

I have modified the realm for the handsets to PBX traffic to not perform accounting.