My Oracle Support Banner

SBC is Not Converting DTMF from in-band to RFC2833/telephone-event in RTP (Doc ID 2218231.1)

Last updated on AUGUST 27, 2020

Applies to:

Acme Packet 4500 - Version S-Cz7.2.0 to S-Cz7.4.0 [Release S-Cz7.0]
Information in this document applies to any platform.

Symptoms

SBC is not converting the DTMF from in-band to RFC2833 and vice-versa while handling media however we can see that SBC is negotiating properly in signaling.

Call flow :

A---------| ----------SBC---------|----------------B
        2.2.2.2                  3.3.3.3

We can see in the wireshark that in the first leg (endpoint A <--> SBC) uses in-band, and the other leg (SBC <--> endpoint B) uses rfc2833. Here SBC is taking responsibility for converting the DTMF  from in-band to RFC 2833 if we see the signaling negotiation. However, DTMF is not converted in RTP packets by SBC because of which IVR is not recognizing the DTMF digits.

The initial INVITE only contained one payload in the SDP, payload 0 (PCMU). This implies that the endpoint does *NOT* support RFC-2833 telephone-events. It also implies the endpoint support *either* out-of-band SIP-INFO or in-band DTMF, however from the SIP signaling you can't tell which one the endpoint supports.

Changes

Customer upgraded the system from 6.x to 7.x.
No issues observed with 6.x version.

Cause

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Symptoms
Changes
Cause
Solution
 RFC2833 to SIP-INFO
 RFC2833 to DTMF
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.