Acme Packet 4500
 

PLA-Support>Sun Systems>CommsGBU>Session Delivery Network>SN-SND: Acme Service Provider
 

SBC is negotiating the Payload type mapping in signaling however not converting in Media.

In this Document

Symptoms

Changes

Cause

Solution

RFC2833 to SIP-INFO

RFC2833 to DTMF

References

Created from <SR 3-13212086411>

Applies to:

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

In C6.x release, the SBC does not support translating to or from in-band DTMF. It only supports translating between RFC2833 telephone-events and SIP-INFO, however if an endpoint sent in-band DTMF, the SBC would simply forward the in-band DTMF in the audio RTP stream.

In C7.x support for in-band DTMF was added and it does require transcoding DSP. As per support-info, their system only has a Quad port GigE SFP PHY which does not have transcoding DSP.

Solution

This device did not have a transcoding DSP, as needed for the DTMF conversion.
Requested them to purchase a new NIU with transcoding DSP.

Once the transcoding DSP was installed, the following changes were necessary:

As per customer configuration, rfc2833-mode is set to transparent in both sip-interfaces.
Setting a sip-interface or a session agent's rfc2833-mode to transparent disables RFC2833 translation on the SBC.

RFC2833 to SIP-INFO

If you change the rfc2833-mode on the access sip-interface to preferred and make test call, the end result will be rfc-2833 on the access and SIP-INFO on the core.

RFC2833 to DTMF

If you add a codec-policy on the core realm with dtmf-in-audio set to preferred and make test call, the end result will be rfc-2833 on the access and DTMF on the core.

References

This solution has no attachment