cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
761
Views
0
Helpful
3
Replies

Problem witz CPL Script

JensLantermann
Level 1
Level 1

Hi everybody,

I have written a script to allow some special calls and reject all other calls.

It looks like,

<?xml version="1.0" encoding="UTF-8" ?>

<cpl xmlns="urn:ietf:params:xml:ns:cpl" 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">

<taa:routed><taa:rule-switch>

  <taa:rule authenticated-origin="(12345|23456)(@.*)?(:.*)?)" destination=".*">

    <!-- Accept Calls from internal specific Administrativ Units to external-->

    <proxy/>

  </taa:rule>

  <taa:rule unauthenticated-origin="(12345|23456)(@.*)?(:.*)?)" destination=".*">

    <!-- Accept Calls from internal specific Administrativ Units to external-->

    <proxy/>

  </taa:rule>

....................

  <taa:rule origin="" destination=".*">

    <!--Reject all other Units from external-->

    <reject status="403" reason="Denied by VCX policiy"/>

  </taa:rule>

  <taa:rule origin=".*" destination=".*">

    <!--Reject all other Units from Internal-->

    <reject status="403" reason="Denied by VCX policiy"/>

  </taa:rule>

</taa:rule-switch></taa:routed></cpl>

My Problem is, that I need both rules to permit SIP (matches auth.-origin) and H323(matches unauth.-origin).

Why is this? Or have I a problem anywhere?

Greetings

Jens

1 Accepted Solution

Accepted Solutions

Hi Jens,

my guess would be that the incoming SIP call contains a P-Asserted-Identitity header as it hits the VCS which this CPL is running on, and that the authentication settings for the zone the call is received on is configured as 'Do not check credentials'. That would lead to the incoming SIP call being classified as authenticated, while an incoming H323 call would not.

View solution in original post

3 Replies 3

awinter2
Level 7
Level 7

Jens,

are you saying that incoming H323 calls are classified by the VCS as non-authenticated, while incoming SIP calls are classified as authenticated? Are these calls coming in via the same zone/subzone?

In general, it is not considered secure to screen calls based on the unauthenticated origin since it has not been authenticated and could therefore be spoofed by the caller.

Edit: You should also drop the last ")" in the origin fields or optionally add a "(" at the very begininning of each origin field since you currently have one too many ")" in your origin expressions.

*The last ")" was a copy paste mistake* :-D

Both calls are coming from the same traversal Zone. I have done a diagnostic logging and there I could see the match of both rules.

The decision is not based on the unauthenticated-origin. The decision is based on the "(12345|23456)(@.*)?(:.*)?)" endpoint syntax.

Hi Jens,

my guess would be that the incoming SIP call contains a P-Asserted-Identitity header as it hits the VCS which this CPL is running on, and that the authentication settings for the zone the call is received on is configured as 'Do not check credentials'. That would lead to the incoming SIP call being classified as authenticated, while an incoming H323 call would not.