Cisco Cisco TelePresence Video Communication Server Expressway 관리 매뉴얼
Device authentication
Cisco VCS Administrator Guide (X7.2)
Page 100 of 498
n
The authentication of presence messages by the VCS is controlled by the authentication policy setting on
the Default Subzone (or relevant alternative subzone) if the endpoint is registered (which is the usual case),
or by the authentication policy setting on the Default Zone if the endpoint is not registered.
the Default Subzone (or relevant alternative subzone) if the endpoint is registered (which is the usual case),
or by the authentication policy setting on the Default Zone if the endpoint is not registered.
n
The relevant Authentication policy must be set to either Check credentials or Treat as authenticated,
otherwise PUBLISH messages will fail, meaning that endpoints will not be able to publish their presence
status.
otherwise PUBLISH messages will fail, meaning that endpoints will not be able to publish their presence
status.
See
for more information.
Controlling system behavior for authenticated and non-
authenticated devices
authenticated devices
How calls and other messaging from authenticated and non-authenticated devices are handled depends on
how search rules, external policy services and CPL are configured.
how search rules, external policy services and CPL are configured.
Search rules
When configuring a search rule, use the Request must be authenticated attribute to specify whether the
search rule applies only to authenticated search requests or to all requests.
search rule applies only to authenticated search requests or to all requests.
External policy services
External policy services are typically used in deployments where policy decisions are managed through an
external, centralized service rather than by configuring policy rules on the VCS itself.
external, centralized service rather than by configuring policy rules on the VCS itself.
You can configure the VCS to use policy services in the following areas:
n
n
n
n
When the Cisco VCS uses a policy service it sends information about the call or registration request to the
service in a POST message using a set of name-value pair parameters. Those parameters include
information about whether the request has come from an authenticated source or not.
service in a POST message using a set of name-value pair parameters. Those parameters include
information about whether the request has come from an authenticated source or not.
More information about policy services, including example CPL, can be found in External policy on VCS
deployment guide.
deployment guide.
CPL
If you are using the Call Policy rules generator on the VCS, source matches are carried out against
authenticated sources. To specify a match against an unauthenticated source, just use a blank field. (If a
source is not authenticated, its value cannot be trusted).
authenticated sources. To specify a match against an unauthenticated source, just use a blank field. (If a
source is not authenticated, its value cannot be trusted).
If you use uploaded, handcrafted local CPL to manage your Call Policy, you are recommended to make your
CPL explicit as to whether it is looking at the authenticated or unauthenticated origin.
CPL explicit as to whether it is looking at the authenticated or unauthenticated origin.
n
If CPL is required to look at the unauthenticated origin (for example, when checking non-authenticated
callers) the CPL must use unauthenticated-origin. (However, if the user is unauthenticated, they
can call themselves whatever they like; this field does not verify the caller.)
callers) the CPL must use unauthenticated-origin. (However, if the user is unauthenticated, they
can call themselves whatever they like; this field does not verify the caller.)
n
To check the authenticated origin (only available for authenticated or “treat as authenticated” devices) the
CPL should use authenticated-origin.
CPL should use authenticated-origin.