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 The OCSBC supporting different clock rates for SILK and Tel-events](img/silk-clock3.png)
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 The OCSBC supporting different clock rates for OPUS and Tel-events](img/opus-clock2.png)
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. The OCSBC Supporting different clock rates without transcoding.](img/silk-clock4-noxcode.png)
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. The OCSBC supporting differing codec and tel-event clock rates with a more complex configuration.](img/complex-clocking3.png)
Using this configuration, and receiving an offer (O1) that contains OPUS/48000 and telephone-event/8000, SBC behavior includes:
- Per ingress codec-policy, accepts OPUS/48000 and the telephone-event/8000.
- Per egress codec-policy, removes OPUS, which is not supported.
- Offers SILK/16000 and telephone-event/16000 to the egress.
- Sends out the offer to UAC2.
- Receives the 200 OK answer, which confirms the SDP, from UAC2.
- Sends an answer towards UAC1 containing a telephone-event using the same clock rate originally offered (telephone-event/8000).
- Towards ingress (UAC1), generates rfc2833 packets using the audio codec’s clock rate (48000).
- 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. The OCSBC supporting differing codec and tel-event clock rates with a more complex configuration.](img/offerless2.png)
Using this configuration, and receiving an offerless INVITE, SBC behavior includes:
- UAC1 sends an offerless INVITE. Offer is received from UAC2 in 200-OK. Therefore, UAC2 becomes ingress and UAC1 becomes egress.
- Ingress codec policy (UAC2’s codec-policy) does not remove anything from the offer since it accepts SILK and telephone-event both.
- 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.
- Answer towards UAC2 contains telephone-event of same clock rate as was received in offer.
- 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).