Call Flows for Differing Egress Clock Rates

This feature operates on a call's ingress and/or egress interface. This section presents example call flows wherein the application of the allow-diff2833-clock-rate-mode parameter is depicted on a call's egress interface.

SDP negotiation follows the same procedures and rules for establishing media flows regardless of whether that negotiation is with the caller or callee. The previous section presented call flows using this feature during negotiation with the caller, or from the SBC perspective, on the call's ingress interface. This section presents call negotiation using this feature with both the caller and callee over the ingress and egress interfaces. The feature does not behave differently over either interface.

When you configure media-profiles, you include payload types, which include clock rates. You can choose to present a specific payload type for both your codec and for telephone events. With this feature, the clock rates for these payload types do not have to be the same. One of the target environments for this feature includes using 8k for telephone event clock rates regardless of the media codec. Although the working SBC configuration and the SDP negotiation ultimately determine the actual payload types used for each call, you can use this feature to successfully bypass the RFC 4733 recommendation for clock rates being the same.

Example 1

In this example, you have configured allow-diff2833-clock-rate-mode to the value use-2833-clock-rate on both the ingress and egress sip-interface elements.

allow-diff2833-clock-rate-mode to use-2833-clock-rate on the ingress and the egress sip-interface
Ingress codec-policy allows OPUS and telephone-event
Egress codec-policy does not accept OPUS, but adds SILK wide-band, and telephone-event::8k

This image depicts the SBC supporting different clock rates for media and telephone events at ingress and egress.

The call flow proceeds as follows:

The ingress codec-policy allows telephone-event having a different clock rate than audio codec. So, the first offer contains OPUS/48000 and telephone-event/8000.
The egress codec-policy removes OPUS, which is not supported, but does not remove telephone-event/8000. It adds SILK/16000 and the corresponding telephone-event/16000, and sends out the offer to UAC2.

Note:
The egress side allows a telephone-event clock rate that is different from the audio clock rate. Therefore, the system does not remove telephone-event/8000 from the offer. Because telephone-event/8000 is already present in the offer, the system does not add the configured telephone-event::8k (based on codec policy) again.
The egress side generates an answer and sends it towards ingress containing a telephone-event that is the same clock rate as was originally offered, in this case (telephone-event/8000).
The system generates RFC 2833 packets towards the ingress and egress using telephone-event clock rate, which is 8000.

Results of this call flow include the ingress codec-policy allowing OPUS and telephone-event. The egress codec-policy does not allow OPUS, but adds SILK-wideband, telephone-event::8k.

Example 2

In this example, you have configured allow-diff2833-clock-rate-mode to the value use-codec-clock-rate on both the ingress and egress sip-interface elements.

allow-diff2833-clock-rate-mode to use-codec-clock-rate on the ingress and the egress sip-interface
Ingress codec-policy allows OPUS and telephone-event
Egress codec-policy does not accept OPUS, but adds SILK wide-band, telephone-event::8k and telephone-event::24k

This image depicts the SBC using the codec clock rate setting to support different clock rates for media and telephone events at ingress and egress.

The call flow proceeds as follows:

The ingress codec-policy allows telephone-event having a different clock rate than the audio codec. Therefore, the first offer contains OPUS/48000 and telephone-event/8000.
The egress codec-policy removes OPUS, which is not supported, and doesn’t remove telephone-event/8000. It adds SILK/16000, the corresponding telephone-event/16000, and telephone-event/24000 and sends out the offer to UAC2.

Note:
The egress side allows different clock rates for telephone-event and audio, Therefore, the system does not remove the telephone-event/8000 from the offer. Since telephone-event/8000 is already present in the offer, the system does not add the configured telephone-event::8k (based on codec policy).
The egress side generates an answer and sends it towards the ingress containing a telephone-event with the same clock rate that was originally offered (telephone-event/8000).
The system generates RFC 2833 packets towards the ingress and egress, based on the audio codec’s clock rate, which is 48000 towards ingress and 16000 towards egress.

Example 3

In this example, you have configured:

allow-diff2833-clock-rate-mode to use-codec-clock-rate on the ingress and the egress sip-interface
Ingress codec-policy allows SILK and telephone-event
Egress codec-policy does not accept SILK, but adds PCMU, telephone-event::8k and telephone-event::24k

In addition, the SBC sends and receives multiple telephone-events in the answer.

The call flow proceeds as follows:

The ingress codec-policy allows the telephone-event to have a different clock rate than the audio codec. Therefore, the first offer contains SILK/16000 and telephone-event/8000.
The egress codec-policy removes SILK, which is not supported. This policy adds PCMU/8000 and telephone-event/24000 and sends out the offer to UAC2.

Note:
The egress side allows the audio and telephone-event to use different clock rates. Therefore, the system does not remove telephone-event/8000 from the offer. Since telephone-event/8000 is already present in offer, the system does not add the configured telephone-event::8k (based on codec policy).
The egress side generates an answer, selects the topmost telephone-event (8000) and sends the answer towards the ingress containing a telephone-event using the same clock rate that was originally offered (telephone-event/8000).
The system generates RFC 2833 packets towards the ingress and egress, based on the audio codec’s clock rate, which is 16000 towards the ingress and 8000 towards the egress.

Results of this call flow include the ingress codec-policy allowing SILK and telephone-event. The egress codec-policy does not allow SILK, but adds PCMU, telephone-event::8k and telephone-event::24k;.

Example 4

In this example, you have configured:

allow-diff2833-clock-rate-mode to use-codec-clock-rate on the ingress and egress sip-interface
Ingress codec-policy allows SILK and telephone-event
Egress codec-policy does not accept SILK, but adds PCMU, telephone-event::8k and telephone-event::16k

In addition, you have received multiple telephone-events in the answer.

The call flow proceeds as follows:

The ingress codec-policy allows the telephone-event to have a different clock rate than the audio codec. The first offer contains SILK/16000 and telephone-event/16000.
The egress codec-policy removes SILK, which is not supported. This policy also adds PCMU/8000 and the corresponding telephone-event/8000 and sends out the offer to UAC2.

Note:
The egress side allows the audio and telephone-event to use different clock rates. Therefore, the system does not remove telephone-event/16000 from the offer. Since telephone-event/16000 is already present in the offer, the system does not add hence telephone-event::16k (based on codec policy) again.
The egress side generates an answer, selects the topmost telephone-event, which is 16000, and sends the answer towards ingress containing a telephone-event that uses the same clock rate originally offered (telephone-event/16000).

The results of this call flow has the system generating ingress rfc2833 packets based on audio codec’s clock rate (16000), and generating rfc2833 packets using the telephone-event clock rate (16000) towards the egress.

Example 5

In this example, you have configured:

allow-diff2833-clock-rate-mode to use-codec-clock-rate on the ingress and egress sip-interface
Ingress codec policy allows PCMA and telephone-event
Egress codec-policy does not allow PCMA, but adds SILK-wideband, telephone-event::8k

In this example, there is no telephone event and, therefore, no telephone-event clock rate from the caller. The SBC, however, does need to negotiate telephone-events with UAC2. This example depicts the egress using your clock rate mode configuration on the egress to support different clock rates between itself and UAC2 independent of, and not triggered by the caller's signaling.

Here, your configuration uses the allow-diff2833-clock-rate-mode setting to support different RTP and telephone event clock rates on the egress. In addition, the egress codec-policy does not allow PCMA, generating transcoding on the call.

This image depicts the SBC supporting different clock rates for media and telephone events at egress only.

The call flow proceeds as follows:

The Ingress offer contains PCMA/8000, but does not contain a telephone-event.
The SBC egress codec-policy removes PCMA, which is not supported. It adds SILK/16000, a corresponding telephone-event/16000 and a telephone-event/8000 (configured in codec policy), then sends out the offer to UAC2.
The egress side generates an answer and sends the answer towards the ingress using PCMA/8000.

Note:

This call flow depicts an inband/Rfc2833 or SIP-INFO/Rfc2833 DTMF interworking case. If you set rfc2833-mode to preferred at the egress and transparent at the ingress, the SBC generates SIP-INFO packets towards the ingress side.

This configuration and flow ultimately includes the egress codec-policy replacing PCMA with SILK-wideband at 16k, and supporting telephone-events at 8k, thereby supporting different clock rates on the egress only.