Phantom Calls remote phone


#1

Good afternoon.

This remote phone (GXP2170) is getting a ton of phantom rings.

Here’s the setup:
Remote phone connects to UCM 6202 w/ latest non-beta firmware.
UCM sits behind firewall that lets the remote location’s traffic through.
UCM PBX settings/SIP/NAT sets public IP and local network range, SDP is checked

On the phone, in the Account->SIP Settings->Security, I have the following set to “yes”:
Validate incoming messages
Check SIP User ID for incoming invite
Accept incoming SIP from Proxy Only
Authenticate incoming INVITE
The Extension (1102) is set to allow two simultaneous registrations - one from the on site phone and one from the remote phone.
Standard ports are forwarded to the on site UCM, and at the remote location the ports are forwarded to the phone.

I did a capture - attached. The remote phone is at 174.55.79.133. UCM is at 73.101.163.255. Local LAN scheme on site is 192.168.5.x, and the local LAN scheme at the remote location is 10.0.0.x

The phone is getting these phantom calls every few minutes. I think there is a real call captured in the pcap too - which I think my remote client rejected without looking at it. :slight_smile:

Edit: I forgot a potentially important detail. There is only one inbound route on the UCM, to .X - any number. The inbound route sends calls to an IVR outside of office time. I happened to be working on the problem when office time ended, and the phantom calls magically stopped. Might my solution be as simple as defining the DIDs to which inbound calls are allowed to go? The one fly in this ointment is that the on site phones on the same ring group (even 1102, the onsite version of the remote phone) are not receiving phantom calls.

Any help much appreciated, as always!

Mike

pcap 200806.zip (89.1 KB)


#2

You took the capture at the wrong site. If you suspect ghost calls, then you need to take the capture from the phone as the calls sre going directly to the phone without going thru the UCM. There was only one call (Invite) in the capture, not “tons”.


#3

Right. It was a very short capture. The capture was done from the phone. I think I edited my original post while you were replying. If I need to do a new capture of a true ghost call . . . perhaps what I captured was a real call and thus not helpful.


#4

also check sip alg is disabled in any router, I had a customer port forward their sip port(like 5060) to the phone, bad idea, remove the forward.
oh check to make sure all 6 sip accounts are disabled and add the only accept invites from known servers on all 6 accounts


#5

It was a real call send from the UCM.

Are you using x. as the inbound rule?


#6

The notion of port forwarding is not a bad idea at all. Unless the router is able to traverse the firewall and reach the phone, how do you propose that an incoming INVITE from a PBX or other will be seen by the phone and cause it to ring?

You can use a SIP options keep-alive to cause a pinhole in the router, but it must still be open in order for an inbound call to reach the phone.

The key is to filter the IPs allowed, if possible at the router as well as implementing the SIP security functions within the HT. Most home routers have no such ACL filter capability so the defense is the HT itself.

Additionally, many routers have issues maintaining the proper NAT/PAT tables for UDP when there is more than one device behind the NAT. So, forwarding may be required in many cases.


#7

Yes. X. is the inbound rule.

Figures we captured a real call. :frowning:

I’ll have to try again this afternoon to capture one of the phantom ones.


#8

Why are you using a wildcard? Why not use the true DID so that if there is more than one you can route on each or any as you need?

I hope you have guest calls disabled. I think you may be still running a F/W version where that function is still there.


#9

I’ll put all of the DIDs in the inbound rule and see if that helps. I used a wildcard b/c all calls go to the same place and there are about 10 DIDs (long story.)

Where is the “guest calls” setting located?


#10

In the PBX settings, but they removed it so check the firmware release notes as I do not recall which specific section it was in.


#11

you dont need to port forward to a device, they initiate all communications… forward to the ucm is a neccessary evil


#12

yes, _X. as an inbound rule will cause phantom rings(good for troubleshooting need to capture incoming format, but bad idea for production), because it says what ever digit i see in the invite follow the rule for _x., the best option is specific inbound routes, _123-456-7890 where 1234567890 is a DID on the sip trunk


#13

ACL on router so only provider can sent invite solve problem.
It is way to late to making defence on UCM (it is not dedicated system for this).


#14

Simply enable “Accept calls from SIP Proxy only” and ghost calls will stop.


#15

Sorry, but unless there is a keep-alive going, they only initiate when they originate a call.


#16

the phone initiates registrations, please dont port forward to a device, yes, you can use a keep alive option for the pin hole or you can reduce your Registration timer to 3 minutes and that will keep the phone up to date, keep the pin hole open in most instances, may need to be lower depending on router. the bonus is the phone gets updated within 3 minutes, updating its reg and the blf’s, eliminating those calls of a stuck blf light.


#17

Yes, the phone initiates registrations and then goes quite until the expiry hits and then it registers again. The typical default expiry period that many use to include GS is 3600 sec. Additionally, the UAS is not obligated to accept the registry expiry as proposed by the UAC and may instead impose its own expiry which the UAC is obligated to accept.

As you have stated, the register will cause a pinhole which still effectively opens the port, not much differently than forwarding does unless the router in question uses strict policies that will only NAT the IP seen in the outbound request back inbound.

Additionally, the UDP timeout for many routers is 30 sec which renders the register either as being too slow or possibly too fast if attempts to register every 30 seconds are attempted. This is why the SIP options keep-alive is available to keep the pinhole open. I am not aware of very many, if any, home/residential routers that allow adjusting the port closure timeout period and some providers will not allow 30 second register period and will have their UAS impose a expiry of their choosing.

The BLF updating has nothing to do with register request as this is a subscribe-notify process independent of the register request. However, if the register is not present, then it may be assumed that the subscription for events is also absent. The device subcribes to the UCM for the events it wants to monitor, There is an expiry period to the subscribe as well. In the event that a notify is sent from the UCM and the device does not receive and ack the notify, then the UCM (or other) will assume the remote device has gone off-line and will no longer send notifies to the device until such time as the subscription is renewed. The notify is not scheduled as there is the initial subscribe (BLF, Voice mail and other) with the subsequent update and then it becomes a random process depending on the changes associated to the subscription.

I am not necessarily advocating that everyone should forward every time, but rather that creating pinholes is in essence forwarding as the hole for inbound traffic must be maintained. I use forwarding or SIP options and the use of which one is dependent on the situation. I am simply saying that forwarding can be done and done safely and more reliably in many instances and that to suggest that it should never be done is, in my opinion, not necessarily warranted in all situations.

If however, what you have works for you, by all means use it.


#18

Can you tell me where to find “Accept calls from SIP Proxy only” I don’t see it under VOIP Trunks

Thank you


#19

It’s on the phone under Account -> Account # -> Security Settings


#20

It’s on the phone - GXP2170 in this case.

It’s under Account X - SIP Settings - Security on this model.