CPL Call Process Language on VCS, Examples?

[Georg Kehrer]

Dear All

Does anybody have a collection of CPL Example for Cisco Telepresence Video Communication Server VCS, or have anybody a tipp for a good Graph/Generation  tool to crate in a easy way CPL scripts.

I know that we have some Examples in the Admin Guide.

Thanks in advanced for any Input/Feedback.

Best Regards

Georg

[Tomonori Taniguchi]

If you are looking for CPL for simple call controlling (allow or reject) based on source and destination alias, you may use Call Policy Rules configuration tool on VCS Web GUI (under VCS configuration > Call Policy > Rules).

Any configuration from this will apply as Local CPL on VCS and you may review CPL from Web GUI (click “Show Call Policy file” icon on Call Policy configuration page, VCS configuration > Call Policy > Configuration).

Here is same example.

1) CPL to control call allowing only same group call each other (may apply for company level if VCS shared with multiple companies).

==========================================================================================

http://www.tandberg.net/cpl-extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">

==========================================================================================

2) CPL to redirect the call to specific destination if original call does not answer within specific time frame.

==========================================================================================

http://www.tandberg.net/cpl-extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">

sales@customer.com">

        reception@customer.com" clear="yes">

==========================================================================================

3) CPL to redirect the call to specific destination based time of day.

==========================================================================================

http://www.tandberg.net/cpl-extensions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">

support@customer.com">

        callcenter@customer.com" clear="yes">

         supportcenter@customer.com" clear="yes">

==========================================================================================

You may find other scenario base CPL from http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_ISDN_Overflow_Using_CPL_Script_Application_Note.pdf.

Hope this help you.

Best regards,

Tomonori Taniguchi

[heathrw]

Hi Tomonori,

That's a good little run down. Is there a more comprehensive VCS CPL programming document that provides all the available syntax to write policies?

Thanks

Heath

[Tomonori Taniguchi]

Hi Heath,

You can find more information in VCS Administrator guide in “CPL reference” section.

Best regards,

Tomonori Taniguchi

[tleliard]

Hi All,

Seen recent acitivty on this thread so though I would give it a try.   Does anyone have an example of trying to change the origin, something analgous to source NAT, when a call is made through the VCS-X.

For example, internally all the vc endpoints are in the format @vc.company.com

We have three VCS-X regionally located, say APAC, EMEA and AMER.  What I would like is when an internal endpoint makes a call to an external endpoint the origin is changed depending on which VCS-X it exited from.  So, say the call goes out via the APAC VCS-X, the it will change from room1@vc.company.com to room1@apac-vc.company.com,  it it were to go out via the emea VCS-X it would be changed to room1@emea-vc.company.com etc,

Too long a story to explain why I am trying to do this but just wondering if anyone with a lot more CPL experience had any ideas.

[awinter2]

Tieliard,

it is not possible to rewrite the source alias of a call/request using CPL, the only way to achieve this on the VCS is by using the source rewrite functionality of FindMe.

For your deployment, the ideal solution would be to deploy a fourth VCS at the top of your hierarchy, to function as a directory VCS, which receives all incoming call requests from external parties. The directory VCS would then query each theater-specific VCS for the called alias, and if found, the directory VCS would remove itself from the signaling path (Note that the Directory VCS will not always be able to remove itself from the signaling path if FindMe is hosted on this VCS) and the call would then go from the remote party to the relevant theater VCS-E.

You could then proceed with setting up FindMe on either each regional VCS or the Directory VCS, setting up FindMe accounts for your users and rooms as needed, where the FindMe ID for room1 would be 'room1@company.com' which would be the callable alias for remote parties. For that FindMe account you would create a device with address 'room1@vc.company.com', so that whenever a remote party calls 'room1@company.com', the call would be sent to your Directory VCS (With the help of DNS SRV records for company.com pointing to your Directory VCS), hit the FindMe account and get redirected to 'room1@vc.company.com'.

Optionally you could have a different subdomain for each theater, for example 'room1@apac-vc.company.com' instead of 'room1@vc.company.com' which would enable you to do more specific pattern matching on the Directory VCS, so that searches for aliases within each theater domain would only be sent to the relevant VCS-E rather than all three VCS-E's.

With FindMe source rewrites enabled on the Directory VCS or a regional VCS, a call placed from 'room1@apac-vc.company.com' would go out via the regional VCS-E (and possibly to the Directory VCS, depending on how you configure your zones) and the calling alias would get rewritten to 'room1@company.com', so that the callee will see the incoming call as coming from this alias rather than the theater-specific domain, which both looks cleaner and makes it easier to handle return calls from this remote party.

Hope this helps,

Andreas

[heathrw]

Hi Your examples were very useful.

I have multiple ISDN gateways with GW1 having two registration prefixes of 00 (video) and 01 (audio) while GW2 uses 04 (audio) and 05 (video)

Looking at the ISDN example which section do I have to duplicate so I can use the multiple prefixes

xmlns:taa="http://www.tandberg.net/cpl-extensions"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">

** Additional Section Here? **

Thanks

[Paulo Souza]

Georg Kehrer,

What is your purpose to use CPL?

Because if you just want to block or permit certain calls by analysing source and destination, it's better you create rules by the web interface.

If you need some advanced things, I can tell you, the most easy way to reach this is by doing what Tomonori said, go to "CPL references" in administrator guide and study it. Beacuse CPL scripts is not a recources used for many people, almost nobody use that stuff.

Regards,

Paulo Souza

[Tomonori Taniguchi]

Hi Heathrw,

If these two GW deployed in same location, is there any reason that you are using different prefix for two GWs?

Multiple ISDN GWs may register to VCS using same gateway prefix that provide load balance and redundancy (if one of GW in maintenance, out of network, fully utilized call license with other active call, etc.).

If these two GW deployed in different location, then please ignore above question (many customer does deploy multiple GWs in different location for saving ISDN line/call cost and location redundancy).

Based on your CPL, seem you are trying to redirect call from GW-1 to GW-2, if GW-1 is out of reach.

You may configure this using two search rules instead of using CPL.

Example for audio primary search and failover search:

Rule Name: GW-1 Audio

   Priority: 40

   Mode: Alias pattern match

   Pattern type: Regex

   Pattern string: 00(.+)

   Pattern behavior: Leave

   On successful match: Continue

Rule Name: GW-2 Audio

   Priority: 40

   Mode: Alias pattern match

   Pattern type: Regex

   Pattern string: 04(.+)

   Pattern behavior: Leave

    On successful match: Continue

Rule Name: GW-1 Audio Failover

   Priority: 45

   Mode: Alias pattern match

   Pattern type: Regex

   Pattern string: 00(.+)

   Pattern behavior: Replace

   Replace string: 04\1

   On successful match: Stop

Rule Name: GW-2 Audio Failover

   Priority: 45

   Mode: Alias pattern match

   Pattern type: Regex

   Pattern string: 04(.+)

   Pattern behavior: Replace

   Replace string: 00\1

   On successful match: Stop

We recommend using search rule for this type of configuration which gives more clear visibility.

CPL become useful if you want to configure failure notice to Endpoint (Endpoint must support this to display back on screen), redirect call to duty operator switching time of day, etc.

Hope this answer your question.

Best regards,

Tomonori Taniguchi

[heathrw]

Hi Tomonori,

The ISDN GWs are in different physical locations for redundancy.

Where the ISDN is down search rules work becuase the GW de-registers when the ISDN is down. But if the ISDN gateway is full on the next call VCS recieves call fail reason 'undefined' and does not use the next search rule. This is the reason for looking into CPL.

Regards

Heath