Expressway show using license type telepresence without reason

[AlonArusi92944]

Expressway show using license type telepresence without reason

[b.winter]

A little more information would be helpful^^

Which Expressway? Exp-C or -E?

Is it an alarm or what?

Could you post a screenshot?

[AlonArusi92944]

Hi Winter 

see the attached screenshot

this is expr-E and there is an alarm the scream for license out of compliance

thanks from advanced

[Jonathan Schulenberg]

Set the registration policy to ‘Allow list’ (Configuration > Registration > Configuration) and do not add anything under Configuration > Registration > Allow List to create an implicit deny behavior. Also set the Default Subzone (Configuration > Local Zone) Registration Policy to Deny. If you do not see this menu option, re-run the service setup wizard and add device registration as an option. That wizard only displays/hides menu options in the UI; it doesn’t actually disable functionality if an option is unchecked.

[AlonArusi92944]

Hו Jonathan 

thanks for the info and sorry for the late response, I will check this and get back with the results  

[AlonArusi92944]

Hi Jonathan 

I just captured the issue online, we have 3 nodes of C and E in a cluster(3 servers for each server C\E)

we are seeing the only active scenario at this moment is 3 records on "call status" for the same extension and the license out of compliance uppers only on one peer of Expr-E

after a few seconds after the conference ended the alarm about the license vanished.

Is there any reason why the conference on the expressway will use this license?

I attached screenshot

thanks from advance 

[Jonathan Schulenberg]

The first example you provided was likely a malicious SIP REGISTER; this is likely a malicious SIP INVITE. Assuming that source/destination URI is not valid in your environment, CPL rules on Expressway-E should block it. Think of Expressway CPL as a firewall access list: only valid URI patterns should be allowed past CPL to the Search Rules.

At a high level, here is the type and order of rules I create when deploying Expressway:

1. Block From address, Unauthenticated callers for URIs you should never see arriving from the public internet. For example, Expressway-E should never receive a SIP INVITE from the public internet using your own domain(s), any subdomain of your own domain(s), the external IPv4 address(es) of Expressway-E itself, or a reserved IPv4 address prefix. I also start out blocking RFC1918 but a legitimate misconfigured far-end endpoint that sends it's internal IP instead of a public address may force you to remove those rules if the business partner can't/won't fix their side.
2. If you're using Webex Hybrid Calling, and using the Webex zone (or the older approach of a DNS zone with "TLS verify inbound mapping" enabled), block From address, Unauthenticated callers for that domain. These calls should match the Webex zone and use MTLS to be authenticated, thus skipping this rule.
3. Allow Zone, DefaultZone where the destination is the narrowest, most specific, pattern that you can reasonably maintain. These rules need to permit what external users would actually call, such as:
   1. CUCM Directory URIs
   2. Enterprise Significant Number (ESN) ranges, in URI format
   3. Your +E.164 telephone number inventory, in URI format. Reminder to be exceedingly careful that the Incoming CSS on CUCM from Expressway does not allow off-net dialing.
4. Finally, and most importantly, create a "deny by default" rule to block Zone, DefaultZone to any destination pattern.