11-02-2012 02:45 AM - edited 03-18-2019 12:04 AM
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
Solved! Go to Solution.
11-02-2012 03:26 AM
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.
11-02-2012 02:56 AM
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.
11-02-2012 03:09 AM
*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.
11-02-2012 03:26 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide