1. Configuration Guide
  2. External Policy Servers
  3. COPS pkt-mm-3 Policy Control

COPS pkt-mm-3 Policy Control

You can configure the Oracle Communications Session Border Controller’s COPS pkt-mm-3 interface to maintain a persistent TCP connection to the external policy server, despite there being no responses to requests for bandwidth. This permits calls to traverse the Oracle Communications Session Border Controller even though the external policy server either fails to respond or rejects the session. Without this functionality configured, the Oracle Communications Session Border Controller waits for the external policy server’s authorization decision or the request to the external policy server times out, resulting in COPS pkt-mm-3 interface error responses and time-outs.

While these type of error responses and time-outs might be handled in some networks, for others they cause unacceptable call failures and call denials. To avoid this situation, you can select the granularity at which your network admits calls through a best-effort pipe and guarantee the Oracle Communications Session Border Controller’s TCP connection to the external policy server remains uncompromised. The external policy server offers three parameters allowing you to enable this capability: permit-on-reject, disconnect-on-timeout, and gate-spec-mask.

Relationship to the TCP Connection

The TCP connection between the Oracle Communications Session Border Controller and the external policy server plays an important role because second-tier networks can experience issues between the policy server and the cable modem termination system (CMTS). Since one policy server can be connected to multiple others, one CMTS’s failure can cascade and cause multiple failures for other CMTSs and policy servers.

Enables the disconnect-on-timeout parameter allows the Oracle Communications Session Border Controller to maintain its TCP connection to the external policy server regardless of upstream issues between PSs and CMTSs. When you disable this setting, the Oracle Communications Session Border Controller can send Gate-Set and Gate-Delete messages to in response the PS’s timeouts and guard against impact to the TCP connection between the Oracle Communications Session Border Controller and the PS.

COPS Gate-Set Timeout

Without this capability enabled, the Oracle Communications Session Border Controller views the situation as a rejection when its COPS Decision Message times out at the PS. As such, the Oracle Communications Session Border Controller denies the session or attempts to revert to the previously requested bandwidth from either a Gate-Set add or Gate-Delete modify message. The permit-on-reject parameter, however, enables the system to forward the session on at a best-effort.

Enabling both the permit-on-reject and the disconnect-on-timeout parameters prompts yet another Oracle Communications Session Border Controller behavior. Consider the situation where a session is in the processing of being established on the Oracle Communications Session Border Controller, and it carries COPS Gate-Set messages to the PS. Typically in this scenario, one voice call has two COPS decision messages: one for the upstream audio, and one for the downstream audio. If any of the Gate-Set message do not receive a response, the Oracle Communications Session Border Controller forwards on the session under as a best effort. And if a non-final Gate-Set message in the session does not receive a response, any remaining Gate-Set messages for the session are not forwarded to the PS; the whole session is forwarded on as a best effort. In other words, if the first Oracle Communications Session Border Controller Gate-Set message out of two times out, the second for the session is not sent.

At every opportunity, the Oracle Communications Session Border Controller tried to elevate the session to a QoS session from its best-effort status. When you enable the external policy server configuration’s reserve-bandwidth parameter, the Oracle Communications Session Border Controller checks twice for bandwidth: once upon INVITE, and a second time upon the 200 OK. Alternatively, when Oracle Communications Session Border Controller receives a ReINVITE, it checks for bandwidth then, too. At the time of these second checks, a call’s best-effort status can improve to that of a QoS session.

When a Gate-Set Times Out

If the Oracle Communications Session Border Controller labels a session best-effort, it does so because the Gate-Set message it has sent to the PS have timed out. The Oracle Communications Session Border Controller does not send a Gate-Delete in this situation because it has not received a valid Gate-Id for that session from the PS.

It is also possible that when a Gate-Set message times out, the CMTS and PS might have allocated the session after the Oracle Communications Session Border Controller’s timeout. One of two errors scenarios result from this occurrence, neither of which is of significance. However, you should be aware of them:

  • If a Gate-Set message times out on the INVITE side of the session, the subsequent Gate-Set message triggered by the 200 OK looks like a request to allocate the same resources. If the CMTS and PS are able to successfully install the flow outside the Oracle Communications Session Border Controller’s eight-second request time-out, issues can ensue.
  • Assuming the Gate-Set message time out but are nonetheless installed after the Oracle Communications Session Border Controller’s request time-out, the Oracle Communications Session Border Controller does not send Gate-Delete messages for the flows because it believes they are unallocated on the PS. Because the Oracle Communications Session Border Controller has no Gate-Id data, it remains unaware the sessions are installed on the PS and CMTS. The PS and CMTS might then be left with stranded gates.

This diagram shows a call flow where the Gate-Set times out. It assumes an access-to-core configuration, where the external bandwidth management configuration shows:

  • disconn-on-timeout=disabled
  • permit-conn-down=enabled
Depicts a call flow when a gate-set times out.

COPS Decision Gate-Set Message Rejected

The COPS pkt-mm-3 interface reply as it does when this feature is not enabled (reply with an error to the signaling application) when:

  • The PS responds to the Gate-Set message with an error, either denying or rejecting the flow
  • The permit-on-reject parameter is disabled (its default setting)

This again results in the situation where a session is in the processing of being established on the Oracle Communications Session Border Controller, and it carries COPS Gate-Set messages to the PS. Typically in this scenario, one voice call has two COPS decision messages: one for the upstream audio, and one for the downstream audio. If any of the Gate-Set message do not receive a response, the Oracle Communications Session Border Controller fowards on the session under as a best effort when the permit-on-reject parameter is enabled.

If a non-final Gate-Set message for a session elicits an error or deny response, the remaining Gate-Set message(s) for that session are not sent to the PS. The Oracle Communications Session Border Controller forwards the entire session as a best effort. This means that if the Oracle Communications Session Border Controller sends two Gate-Set messages and the first meets an error or deny response, then the second one is not sent. Still, the Oracle Communications Session Border Controller attempts to elevate the session’s status from best-effort to QoS given the multiple requests for bandwidth it might issue.

Note

Note:

The Oracle Communications Session Border Controller does not send Gate-Delete message for session that have been deemed best-effort. This is because the Gate-Set messages the Oracle Communications Session Border Controller sent to the PS have timed out, and the Oracle Communications Session Border Controller does not have the PS’s Gate-Id data for the session.

This diagram shows a call flow where Gate-Set messages are denied. t assumes an access-to-core configuration, where the external bandwidth management configuration shows a permit-on-reject set to enabled.

Depicts a call flow when a gate-set times out.

About the Gate-Spec Mask

Vendors of policy servers and those who incorporate PSs into their networks must allow the CMTS to overwrite IP packets with ToS bytes because the value of the Oracle Communications Session Border Controller ’s DSCP/TOS mask is 0xFF. The CMTS uses the following equation to determine whether or not a ToS byte should be overwritten: 

new-ip-tos=((orig-ip-tos AND tos-and-mask) OR (tos-or-mask)

Using the gate-spec-mask parameter, you can configure theOracle Communications Session Border Controller to use a mask comprised entirely of zeros (0s). Doing so allows the PS to reset the byte before calculations using the media policy configuration’s DCSP field can take place.