Expressway Search Rules, Fraud Attempts, and License Consumption

[RockVoiper]

Hi All,

I am the administrator for my organization's voice environment, which presently consists of clusters of CUCM 10.5, CUC 10.5, IM&P 10.5, PLM 10.5, Expressway-E and Expressway-C 8.11.3, and UCCX 10.6.

We are currently piloting Cisco Jabber with MRA (internal and external use MRA due to a single DNS). Everything has been working fine. However, I regular receive alerts from Expressway-E stating that license limits are being approached. This led to an extensive search into the event log for calls that could be consuming said licenses. I am aware of the thousands of fraudulent call attempts we receive each day, but it also appears to be the case that some instances are granted licenses (traversal licenses), even if the call is rejected. Am I interpreting the logs incorrectly, or is it possible for a rejected call to utilized licenses before the call fails?

I also noticed that legitimate inbound calls that reach a user's desktop Jabber client show a "dst-alias" consisting of a string of gibberish @ the PC IP address, which makes it difficult for me to apply search rules without rejecting calls such as this. I was expecting to see the extensions we use or the SIP URI, but that does not appear to be the case. Is this normal behavior? Is there a way in which calls should be sanitized/handled using inbound search rules?

[PJMack]

Although not a guru, I do have some experience with this. What I believe is likely happening is if that rogue call is "getting in" - then the expressway is trying to find a path for the call, and during that time a license is getting used. That license will free once the call drops, but in the meantime it is used for how ever many seconds it takes before failing. Be very specific on any search rule that has a source of "any" - which is the route any outside calls, legit or not, come in. Most companies have fairly generic rules on the outside boxes, perhaps they have a search rule or a transform that takes @ip and turns it to @company (whatever their company domain is) - do you have that? IMHO you should not, your legitimate calls should in this day and age be coming in with @ your domain, not @ip. In addition, on the left of the @ you probably have some policy dictating the URI - yes? At my company, our SIP URI's in the US are the eleven digits that is the phone number @company.com. We also have personalized URI's for all users that use video - first.last@domain. Our only search rules on our public side  with the source of any are ones that would match up to these policies, so if any calls come in with a phone number @ IP (which is the way most of these fraud attempts come in from what I've seen), it will never get past the outside server. 

Just some ideas for you - hope this helps

[RockVoiper]

Thanks for the input. We do have a standard number of digits and a username@domain.com that I could use as a search rule. However, when I view the search history on the Expressway-E, the destination devices are not displaying either of those identities when called.

For instance, I placed a test call from a cell phone to my work number and watched the search history. The external, or source, number looks normal, but the destination alias shoes as a string of numbers and letters, followed by "@" and the IP address of my PC (on which the Jabber client is installed). Because of this, I believe a search rule specifying our SIP URI structure would reject these legitimate calls. 

[PJMack · Accepted solution]

I was referring to the search rules specifically on the Expressway/Edge that are set "Any" for source zones, which is how your legitimate inbound calls get in. Make those very specific. Right now you likely have search rules with source zones of "any" that are not specific, so the box is trying to find the far end via it's neighbor zones, and that's what is taking up your traversal licenses. 

Your inbound cellphone call is not coming through expressway, it's from a known internal zone (CUCM or similar), so the restrictive inbound search rules on the Expressway would not affect that. 

[RockVoiper]

Ahh yes, that makes sense. I didn't realize that the legitimate calls that are detected by the Expressway-E but are not technically using it, would not be impacted by those search rules. In that respect, any legitimate inbound calls that are going through expressway should show up with the, and expected, destination URI. Otherwise, the call could be safely rejected, correct?

[PJMack]

correct!

[RockVoiper]

Great. Thanks for the help!

[Nikhil Jayan Kandampully]

I believe your system is receiving the anonymous calls from internet. we can stop or control this by uploading the CPL file to your Expressway edge. unwanted calls will never consume your license because those calls will get reject by CPL rule before even it hit's any rules that created.

Please refer the Expressway Admin Guide session Session CPL Reference in page no 328.

Refer another discussion about CPL Rules in VCS-E: https://community.cisco.com/t5/telepresence-and-video/cpl-rules-in-vcs-e/td-p/2596019

Refer Unwanted Automatic Call hitting on my Expressway E: https://community.cisco.com/t5/telepresence-and-video/unwanted-automatic-call-hitting-on-my-expressway-e/td-p/28800

if this helps, please rate