BSG Policy Overview
The BSG uses policies to control system behavior and to determine how VoIP signaling is handled on a services PIC or MS-DPC. All incoming VoIP requests are matched against policies, and the actions defined in the matching policies determine how the request is handled; for example, which INVITE requests to accept and which to reject. Each BSG feature, such as QoS, call admission control, and routing of SIP requests, is controlled by policies and has its own actions.
This topic covers:
Types of BSG Policies
There are two types of policies:
- New transaction policies—Define how the BSG handles
signaling for new dialogs and for out-of-dialog transactions. A new
transaction event is raised when a new SIP request, such as an INVITE,
either opens a new dialog or is not related to any dialog. If the
event does not match a new transaction policy, the BSG rejects the
SIP request and returns a 403 (Forbidden) message.
The actions that you can take on requests that match conditions in new transaction policies include accepting, rejecting, or tracing traffic; routing of SIP requests; applying CAC (call admission control); adding, modifying, or removing fields in SIP headers; modifying the request URI in SIP messages; or rejecting SIP messages based on information in the SIP header.
- New call policies—Define how the BSG handles media sessions (voice and video). New call policies classify media and provision the actions to take on media streams, such as mark, drop, applying QoS, applying media anchoring, or detecting latch deadlocks or other media inactivity on a gate.
BSG Policy Model
BSG policies are made up of terms that contain conditions and actions that cause the BSG to handle incoming requests in a certain way.
- Condition—The from statement in the policy.
Defines values or fields that a request must contain before an action
is triggered; for example, a source address, contents of the contact
or request URI fields, registration state, a SIP method, or a media
type, such as audio or video.
- If you have multiple matching fields defined in a from clause within the same term, an AND function is between the conditions. For example, if you have both a contact defined and a SIP method defined, the term must match the values defined for both the contact and the SIP method.
- If you have multiple definitions for the same field in a from clause, an OR function is between the values in the condition. For example, if you have multiple values defined for a contact, the term must match one the values defined.
- Action—The then statement in the policy. Specifies the action that is performed on incoming traffic that matches the condition; for example, accept or reject, mark with a DSCP code point, apply QoS, redirect messages that generated a 3XX response, or route to a next-hop or egress point.
If you have a policy that includes multiple terms, the software applies the actions in the first term that matches the policy.
Policy Sets
You can configure policy sets, which are a list of policies that you can then apply to a service point. All policies in a set are evaluated. The order in which you add policies to the set determines the order in which the BSG processes the policies. In each policy, the action in the first term that matches is the action that is applied.
Service Points
Service points identify a service interface and transport parameters for incoming requests. You attach policies to the service point, and all requests that arrive at the service point are handled by these policies. You can also configure a service point to be used as an egress service point to which SIP requests are routed.
A service interface that you use for service points is a service interface that has been configured for the BSG. See Configuring the Services PIC or DPC for the BSG.
You can configure a VPN on the service point so when you set the egress service point, the packet is sent on a VPN.
