Call Flows for Differing Tel-event and Codec Clock Rates

This section presents examples of the application of the allow-diff2833-clock-rate-mode parameter within call flows.

In this first example, you set the allow-diff2833-clock-rate-mode parameter on the ingress interface to use-2833-clock-rate. The diagram below shows the SBC accepting a different clock rate for the SILK codec and the tel-event from UAC1. This interface is ingress to UAC1. The SBC presents PCMU, and telephone-event with a clock rate of 8000. The SBC maintains the original offer and presents the 200OK to UAC1 using the clock rates it offered.

The OCSBC supporting different clock rates for SILK and Tel-events

In this next example call flow, the diagram shows the SBC using the same allow-diff2833-clock-rate-mode configuration as the example above, allowing it to accept a different clock rate for the opus codec and the telephone-event from UAC1. Again, the SBC presents PCMU, and telephone-event with a clock rate of 8000. The SBC maintains the original offer and presents the 200OK to UAC1 using the clock rates it offered.

The OCSBC supporting different clock rates for OPUS and Tel-events

In this next example call flow, the diagram presents the SBC handling differing telephone-event and codec clock rates without transcoding. Notice that the "top" codec in A0 and O1 are the same. Without enabling features such as dtmf-in-audio detection or RTCP generation, which you could expect would force a transcoded call, the system treats the call as passthrough, even though the telephone-event clock rate differs on ingress and egress. This is because the audio codecs negotiated between ingress and egress are the same. Nevertheless, the SBC maintains the differing telephone-event clock rates and supports the flow.

The OCSBC Supporting different clock rates without transcoding.

In this next example call flow, your configuration includes allow-diff2833-clock-rate-mode on both the ingress (UAC1) and egress (UAC2) interfaces set to different values. In addition, the example is complicated by codec policies:

Note:

The designation of ingress and egress above is relative to UAC1. From the UAC2 perspective, the sip-interface pointing to UAC2 is the ingress interface.
  • The sip-interface pointing to UAC2 is set to use-2833-clock-rate
  • The sip-interface pointing to UAC1 is set to use-codec-clock-rate
  • The codec-policy towards UAC1 allows OPUS and telephone-event
  • The codec-policy towards UAC2 does not allow OPUS, but adds SILK-wideband
The OCSBC supporting differing codec and tel-event clock rates with a more complex configuration.

Using this configuration, and receiving an offer (O1) that contains OPUS/48000 and telephone-event/8000, SBC behavior includes:

  1. Per ingress codec-policy, accepts OPUS/48000 and the telephone-event/8000.
  2. Per egress codec-policy, removes OPUS, which is not supported.
  3. Offers SILK/16000 and telephone-event/16000 to the egress.
  4. Sends out the offer to UAC2.
  5. Receives the 200 OK answer, which confirms the SDP, from UAC2.
  6. Sends an answer towards UAC1 containing a telephone-event using the same clock rate originally offered (telephone-event/8000).
  7. Towards ingress (UAC1), generates rfc2833 packets using the audio codec’s clock rate (48000).
  8. Towards egress (UAC2), generates rfc2833 packets using the telephone-event's clock rate (16000).

Note that the allow-diff2833-clock-rate-mode setting on the interface facing UAC2 has no effect on this flow because the audio codec and telephone-event both have the same clock rate. At egress, the SBC continues to match the clock rate of the telephone-event with a codec introduced by the add-codecs-on-egress parameter.

In this next example call flow, you have configured the SBC with a codec-policy towards UAC2 that accepts SILK and telephone-event; and allow-diff2833-clock-rate-mode is use-2833-clock-rate. In addition, codec-policy towards UAC1 does not accept SILK; and adds OPUS at egress. allow-diff2833-clock-rate-mode is use-2833-clock-rate.

The OCSBC supporting differing codec and tel-event clock rates with a more complex configuration.

Using this configuration, and receiving an offerless INVITE, SBC behavior includes:

  1. UAC1 sends an offerless INVITE. Offer is received from UAC2 in 200-OK. Therefore, UAC2 becomes ingress and UAC1 becomes egress.
  2. Ingress codec policy (UAC2’s codec-policy) does not remove anything from the offer since it accepts SILK and telephone-event both.
  3. Egress codec policy (UAC1’s codec-policy) removes SILK and a telephone-event mismatching clock rate of audio codec. It adds OPUS and a telephone-event matching clock rate of OPUS.
  4. Answer towards UAC2 contains telephone-event of same clock rate as was received in offer.
  5. Rfc2833 packets towards ingress and egress will be generated based on telephone event clock rate i.e. 8000 towards UAC2 (ingress) and 48000 towards UAC1 (egress).