1. Configuration Guide
  2. Transcoding
  3. Separate Clock Rates for Audio and Telephone Events

Separate Clock Rates for Audio and Telephone Events

RFC 4733 recommends that telephone events within an audio stream that use the same synchronization source (SSRC) should use the same timestamp clock rate as the audio channel. As an example, if SILK/16000 is being used as the audio stream then the flow should use telephone-event TE/16000. By default, the ESBC complies with this behavior. You can configure the ESBC, however, to support flows when using different clock rates for audio and telephone events. This allows the ESBC to adapt to environments that do not follow the recommendation.

To perform this function, you configure the allow-diff2833-clock-rate-mode parameter on the sip-interface. The applicable interface can point to the caller or callee to accommodate offers with different clock rates. The most common scenario to use this features is when a caller sends an INVITE to the ESBC with SDP that uses different codec and tel-event clock rates. Furthermore, a Re-INVITE (or UPDATE) coming from, for example, a callee, results in the ESBC applying this function based on this parameter's setting on the callee's sip-interface. This is also true for a Re-INVITE (or UPDATE) coming from a caller, with the ESBC referring to the caller's ingress sip-interface.

Note:

If you enable this feature, and the SDP presents multiple telephone events, the ESBC selects the clock rate of the top-most telephone-event in the SDP.

Mixed clock rate offers appear in the SDP media-level rtpmap attributes with different clock rates.

a=rtpmap:104 SILK/16000
a=rtpmap:100 telephone-event/8000

When presented with mixed clock rates and set to use-2833-clock-rate, the ESBC accepts these mixed rate lines and generates RFC2833 packets using the signaled telephone-event clock rate to the corresponding interface. When set to use-codec-clock-rate, it generates rfc2833 packets using the audio codec's clock rate.

This configuration does not change any other signaling behavior at the egress. For example, if the ESBC adds a codec as a result of your add-codecs-on-egress configuration, it also adds the corresponding telephone-event with the same clock rate. Nevertheless, it is still required that you consider the results of your codec processing and manipulation to achieve the desired effect of your allow-diff2833-clock-rate-mode setting. In addition, this feature does not change how the ESBC handles transcoding processes, but it can affect how the ESBC treats or generates DTMF digits, whether they are RFC2833 packets, SIP-INFO messages or inband DTMF tones.

The existing behavior for inband DTMF signal generation/detection and generation of SIP-INFO messages is not affected by this feature:

  • The ESBC generates inband DTMF signal and encodes it into RTP packets according to the audio codec bandwidth.

    Note that the DTMF generator can only operate in 8000 Hz or 16000 Hz mode. This means the ESBC cannot reliably detect inband DTMF signal that is encoded in RTP media using other bandwidths, such as OPUS FB, SILK SWB and EVS FB.

  • For non-transcoded call, the system generates outgoing RFC2833 or SIP-INFO using the duration field in the received SIP-INFO or RFC2833 as is, regardless of the clock rate signaled for telephone-event.