CPL Rules in VCS-E

[Bob Fitzgerald]

Hello!

I have been trying to help a customer implement some CPL rules to allow certain users from jabber.com accounts to call in and reject others.  I'm using the Rules from Configuration Call Policy Add Call Policy rule, and the Call Policy mode is set to Local CPL.  I think the rules are pretty straightforward, but the VCS is still allowing calls to get through.  At one point, I just had the following rule;

Source pattern - (.*)@jabber.com   Destination pattern - .*    Action - Reject

The calls from my jabber.com account were still connecting.  Am I making a mistake with the regular expressions?  Is there an issue with the CPL implementation on the VCS?  Here are the devices involved;

VCS-E running X8.2.2

Jabber for Telepresence 4.8.8 downloaded from the free Jabber site.  Registered to https://boot.ciscojabbervideo.com/endpoint/configuration

Thanks!

[Patrick Sparkman · Accepted solution]

Hello Bob -

If I'm understanding the problem correct, you're using the CPL web interface in the VCS, and not creating a CPL script yourself?  If so, the web interface only truly works for authenticated sources, not external unauthenticated sources, such as Jabber.com.  You need to create a custom CPL script to accomplish this, as the web interface uses "orgin" where it should use "unauthenticated-orgin", as origin is meant for authenticated sources.

Attached is a CPL script based on your example I threw together, it will work with VCS X8 and above.  if you're running VCS X7.x, than the language in the script will need to be changed.

[Bob Fitzgerald]

Thanks Patrick!

That was the detail I was missing in all of this.

As a side note, in discussing this with another customer they told me they had also run into this issue and their solution was to put the Default Zone in "Treat as authenticated" mode and the web interface CPL rules would apply.  I realize that this is not ideal as it could affect phone book propagation and Presence, but it is working for them.

Thanks again!

[Patrick Sparkman]

Glad it works for you.

Having the Default Zone set to "Treat as authenticated" is a very bad idea.  It could interfere with authentication allowing anyone with any password to authenticate, if search rules rely on authentication, provisioning as you mention.  Several issues might arise.

[bvanbenschoten]

Patrick, I realize this post is a few years old but wanted to comment/update.

I'm researching creating a CPL script to block SIP toll-fraud/ scanners etc..

I noticed this statement in your last post recommending to not use the web interface to create CPL rules because:

"as the web interface uses "orgin" where it should use "unauthenticated-orgin"

I was just testing this on v.8.10.3 and noticed that the web GUI does create rules using "unauthenticated-orgin" when specifying "Unauthenticated callers" in the web GUI drop-down list

The file created by the GUI and downloaded is below.

It looks like Cisco may have fixed this issue at some point in the past.  Does anyone know exactly which version this change was made ?

Another question.

In a typical "simple" modern day expressway setup with no local-registration and B2B video calls, don't all inbound B2B video calls land on the DefaultZone on the Expressway-E ?

If this is the case, is it easier to specify the source of the call as from the DefaultZone instead of trying to match the source with a RexEx ? (see my other example above where I block any numeric destination arriving on the Expressway-E from the DefaultZone)

Wondering if best practices regarding toll fraud protection with CPL has changed in the last few years

[Patrick Sparkman]

Since this thread is several years old, and often things change with software releases as they usually do. The issue with creating CPL rules using the web interface was corrected in version X8.8.2, when they added more granular control with how the rules can be created and what they can match. It was during this release that the CPL rules created using the web interface started working, where unauthenticated users would correctly be defined in the CPL as unauthenticated-origin instead of origin as in previous versions. If this was an intended fix or a side affect of the changes made in this release, I don't know.
Since X8.8.2, I've gone from maintain my toll fraud CPL script to using the web interface, unless I need something more complex that the web interface can't provide. I use a mix of source types, using both address and zone matches. If I can create a zone match that will catch most toll fraud attempts, I'll do that, but sometimes I need to specify a specific source or destination address. In the end, it simply depends on the environment and the types of toll fraud calls you're receiving that will dictate how you create your CPL rules.