VOS3000 Transcoding: Codec Converter Configuration Guide for VoIP

Configuring VOS3000 transcoding correctly is one of the most critical steps in building a reliable VoIP platform that can interconnect diverse networks and endpoints. When the caller and callee use incompatible voice codecs, calls simply cannot connect — or they connect with no audio, one-way audio, or severely degraded voice quality. According to the VOS3000 Transcode Module documentation (Section 1.1, Page 1), “When caller and callee voice codecs are incompatible, transcoding function can be used to make them compatible.” This single statement captures the entire purpose and value of VOS3000 transcoding: bridging the codec gap between different VoIP networks, devices, and service providers.

The reality of VoIP operations is that you will frequently encounter situations where your customers (calling side) support one set of codecs while your vendors (called side) support a different set. For example, a retail SIP customer may only support PCMA (G711a), while your termination vendor only accepts G729 calls. Without VOS3000 transcoding enabled and properly configured, these calls will fail every time — costing you revenue and frustrating your customers. The VOS3000 transcode module solves this problem by converting the voice stream from one codec to another in real time, ensuring both ends can communicate regardless of their native codec support.

This comprehensive guide covers every aspect of VOS3000 transcoding configuration, from the basic codec settings on mapping and routing gateways to advanced DTMF handling during transcoding and G729 negotiation modes. All information is based on the official VOS3000 Transcode Module documentation and the VOS3000 V2.1.9.07 Manual. For expert assistance with your transcoding configuration, contact us on WhatsApp at +8801911119966.

Understanding VOS3000 Transcoding Fundamentals

Before diving into configuration, it is essential to understand what VOS3000 transcoding does, when it is needed, and how it interacts with other VOS3000 features like media proxy and DTMF handling. Many VOS3000 operators struggle with transcoding because they configure it without understanding the underlying concepts, leading to misconfigurations that cause audio problems instead of solving them.

What Is VOS3000 Transcoding?

Transcoding in VOS3000 refers to the real-time conversion of a voice media stream from one codec format to another. When a call passes through VOS3000 with media proxy enabled, the softswitch sits in the media path between the caller and callee. This position allows VOS3000 to receive audio in one codec from the caller, decode it, re-encode it in a different codec, and send it to the callee — all in real time with minimal latency. The VOS3000 Transcode Module documentation confirms this process in Section 1.1 (Page 1): “When caller and callee voice codecs are incompatible, transcoding function can be used to make them compatible.”

The key requirement for VOS3000 transcoding to work is that media proxy must be enabled. Without media proxy, VOS3000 does not intercept the RTP media stream and therefore cannot perform codec conversion. The RTP flows directly between endpoints, and both endpoints must share at least one common codec for the call to succeed.

When VOS3000 Transcoding Is Required

VOS3000 transcoding is required in several common VoIP scenarios. Understanding these scenarios helps you determine when to enable codec conversion and how to configure it properly:

• Different codec support between customer and vendor: Your customer’s SIP device only supports PCMA (G711a) and PCMU (G711u), but your termination vendor only accepts G729 calls. Without transcoding, every call between this customer and vendor will fail with a codec negotiation error
• Bandwidth optimization: You want to use G729 on the vendor side to save bandwidth on your WAN link, while customers connect with G711 over their local network where bandwidth is not a concern
• Multi-vendor routing: Different vendors support different codecs, and you need VOS3000 to adapt the codec for each vendor automatically
• Legacy device interconnection: Older SIP phones or gateways may only support G711, while modern networks use G729 or G723 for efficiency
• Mobile VoIP applications: Mobile SIP clients often prefer G729 for lower bandwidth usage, while the called party may be on a traditional G711 landline

VOS3000 Transcoding Resource Considerations

VOS3000 transcoding is a CPU-intensive operation because it requires real-time decoding and re-encoding of voice streams. Each transcoded call consumes significantly more server resources than a simple pass-through call. The impact depends on which codecs are involved: transcoding between G711 and G729 is more CPU-intensive than transcoding between G711 variants. When planning your VOS3000 deployment, factor in the expected percentage of transcoded calls and ensure your server has sufficient CPU capacity. For load testing guidance, see our VOS3000 concurrent call load test guide.

Where to Configure VOS3000 Transcoding Codec Settings

The VOS3000 transcoding codec settings are located in the Additional Settings section of both mapping gateways (customer side) and routing gateways (vendor side). According to the VOS3000 Transcode Module documentation (Section 1.2, Page 1), the codec configuration is found at: Business Management > Routing Gateway/Mapping Gateway > Additional Settings > Codec. This same path is referenced in the VOS3000 Manual Section 2.5.1.1 (Page 32, 47) which describes the codec settings under Additional Settings > Codec > H323/SIP.

Understanding this configuration location is critical because the transcoding behavior is controlled independently on each gateway. The mapping gateway codec settings determine how VOS3000 handles the codec on the caller (customer) side, while the routing gateway codec settings determine the codec handling on the callee (vendor) side. Both sides must be configured correctly for VOS3000 transcoding to function as intended.

Navigating to Codec Settings

To access the VOS3000 transcoding codec settings, follow these steps for each gateway type:

For Mapping Gateway (Customer Side):

1. Navigate to Business Management > Mapping Gateway
2. Double-click the mapping gateway you want to configure
3. Click the Additional Settings tab
4. Select the Codec sub-tab
5. Configure the SIP and/or H323 codec settings as needed

For Routing Gateway (Vendor Side):

1. Navigate to Business Management > Routing Gateway
2. Double-click the routing gateway you want to configure
3. Click the Additional Settings tab
4. Select the Codec sub-tab
5. Configure the SIP and/or H323 codec settings as needed

For mapping gateways, the path is Business Management > Mapping Gateway > Additional Settings > Codec > H323/SIP (referenced in VOS3000 Transcode Module Section 1.2 and VOS3000 Manual Section 2.5.1.1, Page 32). For routing gateways, the path is Business Management > Routing Gateway > Additional Settings > Codec > H323/SIP (referenced in VOS3000 Transcode Module Section 1.2 and VOS3000 Manual Section 2.5.1.1, Page 47). Both paths lead to the same codec configuration interface, but the settings you apply on each gateway type control different sides of the call.

VOS3000 Transcoding Configuration Options Explained

The VOS3000 transcoding codec configuration provides two primary settings that control how the softswitch handles codec negotiation and conversion: “Softswitch specified” and “Allow codec conversion.” Understanding the exact behavior of each option is essential for correct VOS3000 transcoding configuration.

Softswitch Specified Codec Setting

According to the VOS3000 Transcode Module documentation (Section 1.2, Page 1), the “Softswitch specified” option means that both the caller and callee use the codec specified by the softswitch. When this option is selected, VOS3000 dictates the codec to be used on that gateway side, regardless of what codecs the far-end device supports or negotiates in SDP.

The practical impact of the “Softswitch specified” setting is significant:

• On the mapping gateway (caller side): Selecting “Softswitch specified” with a specific codec (e.g., PCMA) forces VOS3000 to use PCMA when communicating with the customer’s device, even if the customer’s device offers G729 in its SDP
• On the routing gateway (callee side): Selecting “Softswitch specified” with a specific codec (e.g., G729) forces VOS3000 to use G729 when sending media to the vendor, even if the vendor’s SDP also offers PCMA
• Combined effect: When both sides use “Softswitch specified” with different codecs, VOS3000 transcoding is automatically activated to convert between the two specified codecs

This is the most common and recommended configuration for VOS3000 transcoding because it gives you precise control over which codec is used on each side of the call.

Allow Codec Conversion Setting

The “Allow codec conversion” checkbox is the second critical setting for VOS3000 transcoding. According to the VOS3000 Transcode Module documentation (Section 1.2, Page 1), “When caller and callee codecs are inconsistent, use codec conversion to convert to far-end supported voice codec.” This setting explicitly permits VOS3000 to perform real-time codec conversion when the codecs on the two sides of the call do not match.

The “Allow codec conversion” checkbox must be checked on both the mapping gateway and the routing gateway for full transcoding support. The behavior is as follows:

• Checked on mapping gateway: VOS3000 is allowed to convert the codec on the caller (customer) side to match what the callee (vendor) requires
• Checked on routing gateway: VOS3000 is allowed to convert the codec on the callee (vendor) side to match what the caller (customer) is sending
• Unchecked on either side: VOS3000 will not perform codec conversion on that side, which may result in call failure if the codecs are incompatible

The combination of “Softswitch specified” and “Allow codec conversion” creates a complete VOS3000 transcoding configuration that ensures calls succeed even when the caller and callee have no common codecs.

VOS3000 Transcoding Function Scenario: Step-by-Step

The VOS3000 Transcode Module documentation (Section 1.3, Pages 2-3) provides a detailed application scenario that demonstrates exactly how VOS3000 transcoding works in practice. This scenario is the most important configuration example to understand because it shows the complete flow of a transcoded call from start to finish.

Scenario: Caller Supports PCMA Only, Callee Supports G729 Only

In this scenario, the caller (customer connected through a mapping gateway) only supports the PCMA codec (G711a), while the callee (vendor connected through a routing gateway) only supports G729. Without VOS3000 transcoding, this call would fail because the two endpoints have no common codec. With VOS3000 transcoding properly configured, the call succeeds because VOS3000 converts the voice stream from PCMA to G729 in real time.

According to the VOS3000 Transcode Module documentation (Section 1.3, Pages 2-3), the configuration steps are:

Step 1: Configure the Mapping Gateway (Caller Side)

1. Navigate to Business Management > Mapping Gateway
2. Double-click the mapping gateway used by the caller
3. Go to Additional Settings > Codec
4. Check the “Allow codec conversion” checkbox
5. Select “Softswitch specified codec PCMA”
6. Save the configuration

By checking “Allow codec conversion” and selecting “Softswitch specified codec PCMA” on the mapping gateway, you are telling VOS3000 to force the use of PCMA when communicating with the caller, and to allow VOS3000 to convert this codec to whatever the callee requires.

Step 2: Configure the Routing Gateway (Callee Side)

1. Navigate to Business Management > Routing Gateway
2. Double-click the routing gateway used for the callee
3. Go to Additional Settings > Codec
4. Check the “Allow codec conversion” checkbox
5. Select “Softswitch specified codec G729”
6. Save the configuration

By checking “Allow codec conversion” and selecting “Softswitch specified codec G729” on the routing gateway, you are telling VOS3000 to force the use of G729 when communicating with the vendor, and to allow VOS3000 to convert the incoming PCMA stream to G729 before sending it to the vendor.

How the Call Flow Works During VOS3000 Transcoding

Understanding the complete call flow during VOS3000 transcoding helps you troubleshoot issues and design your transcoding architecture correctly. Here is what happens at each stage of the call:

1. Call initiation: The caller sends a SIP INVITE to VOS3000 with PCMA in the SDP codec list
2. Codec selection on mapping gateway: VOS3000, using the “Softswitch specified codec PCMA” setting on the mapping gateway, responds to the caller with PCMA as the selected codec, regardless of what other codecs the caller offered
3. Call routing: VOS3000 routes the call to the appropriate routing gateway based on the dial plan and LCR configuration
4. Codec selection on routing gateway: VOS3000, using the “Softswitch specified codec G729” setting on the routing gateway, sends a SIP INVITE to the vendor with only G729 in the SDP, forcing the vendor to use G729
5. Media path established: The caller sends RTP audio in PCMA format to VOS3000. VOS3000 decodes the PCMA audio, re-encodes it as G729, and sends the G729 audio to the vendor. In the reverse direction, the vendor sends G729 audio to VOS3000, which decodes it and re-encodes as PCMA for the caller
6. Two-way audio: Both parties hear each other clearly because VOS3000 transcoding handles the codec conversion in both directions simultaneously

This bidirectional real-time codec conversion is the core function of VOS3000 transcoding. The process is seamless to both parties — neither the caller nor the callee is aware that their voice is being decoded, converted, and re-encoded by VOS3000 in the middle.

VOS3000 Transcoding: Auto Negotiation vs Softswitch Specified

The VOS3000 Manual Section 2.5.1.1 (Page 32, 47) describes two primary codec selection modes available in the Additional Settings > Codec > H323/SIP configuration: Auto negotiation and Softswitch specified. Choosing the correct mode for each gateway is critical for VOS3000 transcoding to work properly.

Auto Negotiation Mode

In Auto negotiation mode, VOS3000 allows the endpoints to negotiate the codec through the standard SDP offer/answer mechanism. VOS3000 does not force a specific codec; instead, it facilitates the negotiation between the caller and callee to find a mutually supported codec. If both endpoints share at least one common codec, Auto negotiation will select it and no transcoding is needed.

Auto negotiation is appropriate when:

• Both endpoints share common codecs: If your customers and vendors both support G711 and G729, Auto negotiation will select the best common codec without requiring transcoding
• You want to minimize server load: Auto negotiation avoids transcoding when possible, reducing CPU consumption on your VOS3000 server
• Simple deployments: When all your gateways and endpoints use the same codecs, Auto negotiation is the simplest configuration

However, Auto negotiation fails when the caller and callee have no common codecs. In this case, VOS3000 cannot complete the SDP negotiation and the call will fail with a codec mismatch error. This is exactly when you need to switch from Auto negotiation to Softswitch specified with “Allow codec conversion” enabled.

Softswitch Specified Mode

In Softswitch specified mode, VOS3000 dictates which codec is used on each side of the call. As described in the VOS3000 Transcode Module documentation (Section 1.2, Page 1), “Softswitch specified: Both caller and callee use softswitch specified codec.” This mode gives you complete control over the codec selection on each gateway, independent of what the endpoints negotiate or offer in SDP.

Softswitch specified mode is required when:

• Caller and callee have no common codecs: You must force different codecs on each side and rely on VOS3000 transcoding to bridge the gap
• You need to control bandwidth usage: Forcing G729 on the vendor side reduces bandwidth consumption, even if both sides support G711
• A specific codec is required by a gateway: Some SIP gateways only work correctly with a specific codec, and you need to force it regardless of the endpoint’s SDP offer

VOS3000 Transcoding G729 Negotiation Modes

When configuring VOS3000 transcoding with the G729 codec, you must understand the G729 negotiation modes available in VOS3000. According to the VOS3000 Manual Section 2.5.1.1 (Page 32, 47), the G729 codec has multiple variants and VOS3000 supports several negotiation modes for handling them.

G729 Variants and Their Differences

The G729 codec family includes several variants, the most important being:

• G729: The original G729 codec (also known as G729A annex), providing 8 kbps voice compression
• G729a: A lower-complexity version of G729 with slightly reduced voice quality but significantly lower CPU requirements. The “a” stands for “annex A”
• G729b: G729 with Voice Activity Detection (VAD) and Comfort Noise Generation (CNG), which reduces bandwidth during silence periods
• G729ab: Combination of G729a (low complexity) and G729b (VAD/CNG)

While all G729 variants use the same basic encoding algorithm and are largely interoperable, some SIP devices are strict about which variant they accept. If a device advertises only G729a in its SDP but VOS3000 sends G729, the call may fail even though the audio encoding is compatible. The G729 negotiation modes in VOS3000 solve this problem by controlling how VOS3000 advertises and handles G729 variants.

G729 Negotiation Mode Options

VOS3000 provides four G729 negotiation modes, as referenced in the VOS3000 Manual (Section 2.5.1.1, Page 32, 47):

• Auto: VOS3000 automatically selects the G729 variant based on the remote endpoint’s SDP offer. If the endpoint offers G729, VOS3000 responds with G729. If the endpoint offers G729a, VOS3000 responds with G729a. This is the recommended setting for maximum compatibility
• G729: VOS3000 always uses G729 regardless of what the remote endpoint offers. Use this when you need to force G729 for compatibility with gateways that only accept this variant
• G729a: VOS3000 always uses G729a regardless of the remote endpoint’s offer. Use this when you need the lower-complexity variant for CPU savings on high-capacity transcoding
• G729&G729a: VOS3000 offers both G729 and G729a in the SDP, allowing the remote endpoint to choose which variant to use. This provides maximum compatibility by supporting both variants simultaneously

Choosing the Right G729 Negotiation Mode for VOS3000 Transcoding

For most VOS3000 transcoding deployments, the Auto G729 negotiation mode is the best choice because it automatically adapts to the remote endpoint’s G729 variant, minimizing compatibility issues. However, if you encounter G729 codec negotiation failures where calls fail with codec mismatch errors even though both sides claim to support G729, try switching to G729&G729a mode, which offers both variants in the SDP and allows the remote endpoint to select the one it supports.

If your VOS3000 server handles a large number of concurrent transcoded calls and CPU utilization is a concern, consider using G729a mode, which uses less CPU per call due to its lower algorithmic complexity. The voice quality difference between G729 and G729a is minimal and typically imperceptible to callers.

VOS3000 Transcoding and DTMF Handling

DTMF (Dual-Tone Multi-Frequency) handling is a critical consideration when configuring VOS3000 transcoding. When VOS3000 performs transcoding, it sits in the media path and processes all RTP packets, including DTMF signals. The VOS3000 Transcode Module documentation (Section 2, Pages 5-6) provides detailed information about how DTMF is handled during transcoding, and understanding these behaviors is essential for ensuring that IVR systems, calling card platforms, and PIN authentication work correctly with transcoded calls.

DTMF Transport Methods in VOS3000 Transcoding

VOS3000 supports three DTMF transport methods, each with different behavior during transcoding:

SIP INFO: According to the VOS3000 Transcode Module documentation (Section 2.2, Page 5), “SIP INFO belongs to independent signaling, where key presses are carried in separate signaling messages.” SIP INFO DTMF signals travel in the SIP signaling channel, completely separate from the RTP media stream. This means SIP INFO DTMF is unaffected by codec conversion because it does not travel in the media path.

RFC2833: According to the VOS3000 Transcode Module documentation (Section 2.3, Page 5), “RFC2833 is identified in SDP by a=rtpmap:101 telephone-event/8000, and key presses are carried in separate RTP packets.” RFC2833 transmits DTMF as special RTP events within the media stream, identified by a specific payload type. The SDP attribute a=rtpmap:101 telephone-event/8000 advertises RFC2833 support and specifies the payload type number (commonly 101).

Inband: According to the VOS3000 Transcode Module documentation (Section 2.4, Page 5), “Inband key presses are carried in the RTP as a continuous segment of voice.” Inband DTMF embeds the DTMF tones as actual audio in the RTP voice stream. This is the most problematic method for VOS3000 transcoding because the DTMF tones are compressed along with the voice audio, which can distort them beyond recognition — especially when transcoding between G711 and G729.

RFC2833 Payload Configuration for VOS3000 Transcoding

The RFC2833 payload value is a critical setting for VOS3000 transcoding when DTMF is transported via RFC2833. According to the VOS3000 Transcode Module documentation, only RFC2833 has a Payload value setting. The payload number (typically 101) identifies the RTP payload type used for telephone-event packets. When configuring VOS3000 transcoding, ensure that the RFC2833 payload value matches on both sides of the call, or that VOS3000 is correctly translating the payload type during transcoding.

The SDP for RFC2833 includes the following attribute:

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

In this example, payload type 101 is used for telephone-event, and keys 0-16 are supported (digits 0-9, *, #, and additional keys A-D). When media proxy is enabled during VOS3000 transcoding, VOS3000 controls the payload type and key range sent to each side.

Use Peer RFC2833 Ability Setting

The “Use peer RFC2833 ability” setting controls how VOS3000 advertises RFC2833 support in the SDP during VOS3000 transcoding. According to the VOS3000 Transcode Module documentation (Section 2.5, Page 6):

• When checked: If the peer (far end) sends RFC2833 capability in its SDP, VOS3000 will also advertise RFC2833 to the other side. If the peer does not send RFC2833, VOS3000 will not advertise it either. This follows the peer’s capability transparently
• When unchecked: If the peer sends RFC2833 capability, VOS3000 sends RFC2833 to the far end normally. If the peer does not send RFC2833, VOS3000 auto-generates the SDP field to include RFC2833 capability, regardless of what the peer supports. This forces RFC2833 on the far end even when the original peer did not offer it

For VOS3000 transcoding deployments where you want to ensure RFC2833 DTMF works reliably on both sides, unchecking “Use peer RFC2833 ability” is often the better choice because it guarantees that VOS3000 advertises RFC2833 in SDP to both endpoints, enabling proper DTMF relay during transcoding.

VOS3000 Transcoding DTMF Behavior with Media Proxy

The VOS3000 Transcode Module documentation (Section 2.6, Page 6) provides critical details about how DTMF is handled when media proxy is enabled or disabled during VOS3000 transcoding. This is one of the most important aspects of transcoding configuration because incorrect DTMF handling can cause IVR failures, PIN entry problems, and other issues that directly impact your customers.

DTMF with Media Proxy Enabled (Required for VOS3000 Transcoding)

When media proxy is enabled — which is required for VOS3000 transcoding — VOS3000 fully intercepts and processes all RTP media streams, including DTMF signals. According to the VOS3000 Transcode Module documentation (Section 2.6, Page 6), “If media forwarding is enabled, the RFC2833 payload and 0-16 key support type received from the far-end SDP is terminated by VOS, and VOS integrates and sends the values set in VOS DTMF configuration to the peer end.”

This means that with media proxy on during VOS3000 transcoding:

• RFC2833 is terminated and regenerated: VOS3000 receives the RFC2833 DTMF events from one side, terminates them, and then generates new RFC2833 DTMF events on the other side using the payload value and key range configured in VOS3000’s DTMF settings
• DTMF conversion is possible: VOS3000 can convert DTMF from one method to another (e.g., SIP INFO on the caller side to RFC2833 on the callee side)
• Payload type is controlled by VOS3000: The RFC2833 payload type number sent to each endpoint is determined by VOS3000, not passed through from the remote side
• Key support range is controlled: VOS3000 sends DTMF key support 0-16 (digits 0-9, *, #, A-D) as configured in the DTMF settings

DTMF Without Media Proxy (Passthrough Mode)

When media proxy is disabled, VOS3000 does not intercept the RTP stream and DTMF signals pass through directly between endpoints. According to the VOS3000 Transcode Module documentation (Section 2.6, Page 6), without media proxy, “RFC2833 passthrough” is the behavior — DTMF events travel directly from the caller to the callee without modification.

However, without media proxy, VOS3000 transcoding cannot function because VOS3000 does not have access to the media stream to perform codec conversion. This means passthrough mode and transcoding are mutually exclusive — if you need VOS3000 transcoding, media proxy must be enabled, and VOS3000 will actively handle DTMF as described above.

Important VOS3000 Transcoding DTMF Notes and Edge Cases

The VOS3000 Transcode Module documentation (Section 2.6, Page 6) includes several important notes about DTMF behavior during transcoding that are critical for avoiding common problems. These edge cases frequently cause confusion and support issues, so understanding them thoroughly is essential.

Dual DTMF Method Handling

According to the VOS3000 Transcode Module documentation, “When the far-end sends both SIP INFO and RFC2833, VOS will only recognize the first detected key press type.” This means that if a device sends DTMF using both SIP INFO and RFC2833 simultaneously (which some devices do), VOS3000 locks onto whichever method it detects first and ignores the other for the remainder of that call. This first-detected-type locking mechanism prevents duplicate DTMF digits but can cause issues if the far-end switches DTMF methods mid-call.

Inband to SIP INFO/RFC2833 Conversion

The VOS3000 Transcode Module documentation states: “If Inband is received but far-end uses SIP INFO/RFC2833, VOS can only identify and pass through, then send additional SIP INFO/RFC2833.” This means VOS3000 can detect Inband DTMF in the incoming RTP stream and then generate the corresponding SIP INFO or RFC2833 DTMF on the outgoing side. However, this conversion requires media proxy to be enabled and is not 100% reliable because Inband DTMF detection depends on audio quality and codec type.

RFC2833/SIP INFO to Inband Conversion

When the situation is reversed, the VOS3000 Transcode Module documentation explains: “If peer sends RFC2833/SIP INFO but far-end uses Inband, the RFC2833/SIP INFO is discarded and converted to Inband.” VOS3000 discards the incoming RFC2833 or SIP INFO DTMF and instead generates Inband DTMF tones in the outgoing RTP audio stream. This conversion is less common but may be necessary when connecting to legacy PBX systems or analog gateways that only understand Inband DTMF.

Key Range and Payload Control with Media Proxy

As stated in the VOS3000 Transcode Module documentation, “With media proxy on: RFC2833 payload and 0-16 key support terminated by VOS, VOS sends configured DTMF values.” This means VOS3000 takes full control of the RFC2833 parameters on both sides of the transcoded call. The payload type number and the supported key range (0-16) advertised in the SDP are determined by VOS3000’s configuration, not by what the original endpoint offered. This ensures consistency and prevents payload type mismatches that could cause DTMF failures.

For more detailed DTMF configuration guidance beyond transcoding, see our dedicated VOS3000 no voice and one-way audio troubleshooting guide which covers DTMF-related audio issues in detail.

These DTMF edge cases highlight the importance of understanding VOS3000 transcoding behavior in detail. The key takeaways are: (1) VOS3000 locks to the first detected DTMF type when multiple methods are received simultaneously; (2) Inband to SIP INFO/RFC2833 conversion is partial and may not be fully reliable; (3) RFC2833/SIP INFO to Inband conversion is full and reliable with media proxy; (4) With media proxy on, VOS3000 has full control over RFC2833 payload type and key range; (5) Without media proxy, RFC2833 passthrough is the only option and transcoding is not possible.

Complete VOS3000 Transcoding Configuration Walkthrough

This section provides a complete, step-by-step walkthrough for configuring VOS3000 transcoding in a real-world scenario. The example uses the most common transcoding situation: a customer who only supports G711 (PCMA) connecting through a vendor that only accepts G729.

Prerequisites for VOS3000 Transcoding

Before configuring VOS3000 transcoding, ensure the following prerequisites are met:

• VOS3000 transcode module is installed: The transcode module must be installed and licensed on your VOS3000 server. Without it, codec conversion options will not be available in the gateway configuration
• Media proxy is enabled: VOS3000 transcoding requires media proxy to intercept and process the RTP media stream. Verify that media proxy is set to “Auto” or “On” on both the mapping gateway and routing gateway
• Sufficient server CPU capacity: Each transcoded call consumes more CPU than a pass-through call. Monitor your server’s CPU utilization and ensure you have headroom for the expected number of concurrent transcoded calls
• Proper DTMF configuration: If your calls involve IVR or DTMF-dependent features, configure DTMF settings correctly on both gateways before enabling transcoding

Step 1: Configure Mapping Gateway Codec for VOS3000 Transcoding

Access the mapping gateway configuration for the customer who will be sending calls:

1. Navigate to Business Management > Mapping Gateway
2. Double-click the target mapping gateway
3. Click the Additional Settings tab
4. Select the Codec sub-tab
5. Under the SIP section:
   • Set codec mode to “Softswitch specified”
   • Select PCMA as the softswitch specified codec
   • Check “Allow codec conversion”
6. Set media proxy to Auto or On
7. Click Save

Step 2: Configure Routing Gateway Codec for VOS3000 Transcoding

Access the routing gateway configuration for the vendor who will be receiving calls:

1. Navigate to Business Management > Routing Gateway
2. Double-click the target routing gateway
3. Click the Additional Settings tab
4. Select the Codec sub-tab
5. Under the SIP section:
   • Set codec mode to “Softswitch specified”
   • Select G729 as the softswitch specified codec
   • Set G729 negotiation mode to Auto
   • Check “Allow codec conversion”
6. Set media proxy to Auto or On
7. Click Save

Step 3: Configure DTMF for VOS3000 Transcoding

On both the mapping gateway and routing gateway, configure the DTMF settings to ensure DTMF works correctly during transcoding:

1. In the same Additional Settings tab, select the Protocol sub-tab (or DTMF sub-tab depending on your VOS3000 version)
2. Set DTMF receive to All (accepts all DTMF methods)
3. Set DTMF send (SIP) to Auto or RFC2833
4. Set RFC2833 Payload to 101 (default)
5. Uncheck “Use peer RFC2833 ability” if you want VOS3000 to always advertise RFC2833 regardless of the peer’s capability (recommended for transcoding)
6. Click Save

Step 4: Test VOS3000 Transcoding

After completing the configuration, test the transcoding with actual calls:

1. Use a SIP softphone configured with only PCMA codec to place a test call
2. The call should route through the mapping gateway (PCMA side) to the routing gateway (G729 side)
3. Verify two-way audio by speaking and confirming the other party can hear you
4. Test DTMF by pressing keypad buttons during the call and verifying they are received on the far end
5. Check the VOS3000 Current Call view to verify that the caller is using PCMA and the callee is using G729
6. Review CDR records after the call to confirm the codec information is recorded correctly

For detailed call testing procedures, see our VOS3000 PIN test and SIP account call testing guide.

Troubleshooting VOS3000 Transcoding Issues

VOS3000 transcoding problems typically manifest as no audio, one-way audio, or DTMF failures. This section covers the most common issues and their solutions.

Issue 1: No Audio After Enabling VOS3000 Transcoding

If you enable VOS3000 transcoding but calls have no audio at all, the most common causes are:

• Media proxy not enabled: VOS3000 transcoding requires media proxy to be active. Check that both the mapping gateway and routing gateway have media proxy set to “Auto” or “On”
• Transcode module not installed: Without the transcode module installed and licensed, VOS3000 cannot perform codec conversion even if the settings are configured. Verify the transcode module is active in your VOS3000 installation
• Firewall blocking RTP: Check that your server’s firewall allows RTP traffic on the configured media port range. For firewall configuration guidance, see our VOS3000 extended firewall configuration guide
• Incorrect codec selection: Verify that the “Softswitch specified codec” on each gateway matches a codec that the endpoint actually supports. If you specify G729 on the mapping gateway but the customer’s SIP phone does not support G729, the call will fail

Issue 2: One-Way Audio with VOS3000 Transcoding

One-way audio during VOS3000 transcoding means that one party can hear the other but not vice versa. This typically indicates an asymmetric configuration issue:

• Codec conversion only enabled on one side: If “Allow codec conversion” is checked on the mapping gateway but not the routing gateway, transcoding may only work in one direction. Ensure both sides have “Allow codec conversion” checked
• NAT/routing issue on one side: The RTP stream from VOS3000 to one endpoint may be blocked by a NAT or firewall. This is not a transcoding issue but a network issue that must be resolved separately
• Asymmetric media proxy: If media proxy is enabled on one gateway but not the other, the RTP path may be incomplete. Enable media proxy on both gateways for VOS3000 transcoding

Issue 3: DTMF Not Working During VOS3000 Transcoding

DTMF failures during transcoded calls are common and usually caused by DTMF method mismatches or incorrect payload configuration:

• Inband DTMF with G729: If the DTMF method is set to Inband but the transcoded call uses G729 on one side, DTMF tones will be distorted by the codec compression. Switch to RFC2833 or SIP INFO for reliable DTMF during VOS3000 transcoding
• Payload mismatch: If the RFC2833 payload value configured in VOS3000 does not match what the endpoint expects, DTMF events will not be recognized. Verify the payload value matches the SDP negotiation
• “Use peer RFC2833 ability” misconfigured: If this setting is checked and the peer does not advertise RFC2833 support, VOS3000 will not advertise RFC2833 to the other side, causing DTMF to fail. Try unchecking this option so VOS3000 always advertises RFC2833

For comprehensive audio troubleshooting, including DTMF-related audio problems, see our VOS3000 one-way audio troubleshooting guide.

Best Practices for VOS3000 Transcoding Configuration

Following these best practices will help you configure VOS3000 transcoding correctly and avoid common problems that affect call quality and reliability.

1. Minimize Transcoding When Possible

VOS3000 transcoding consumes significant server CPU resources and introduces a small amount of latency and potential voice quality degradation. Always prefer direct codec passthrough when both endpoints share a common codec. Only enable VOS3000 transcoding when there is a genuine codec incompatibility that prevents calls from connecting. Use Auto negotiation as the default codec mode, and switch to Softswitch specified with Allow codec conversion only when you need to force different codecs on each side.

2. Use RFC2833 for DTMF with VOS3000 Transcoding

RFC2833 is the most reliable DTMF method for VOS3000 transcoding because it is carried in separate RTP packets that VOS3000 can terminate and regenerate without quality loss. SIP INFO is also reliable since it travels in the signaling channel, but it may not be supported by all devices. Avoid Inband DTMF with transcoded calls because codec compression distorts the DTMF tones, especially with G729.

3. Monitor CPU Utilization

VOS3000 transcoding is CPU-intensive. Monitor your server’s CPU utilization regularly, especially during peak call volumes. If CPU utilization consistently exceeds 70-80%, consider upgrading your server hardware or reducing the number of concurrent transcoded calls. Use the VOS3000 system monitoring tools to track resource usage in real time.

4. Configure G729 Negotiation Mode Correctly

For maximum compatibility with diverse gateways and SIP devices, use the Auto G729 negotiation mode. If you encounter G729-specific negotiation failures, switch to G729&G729a mode to offer both variants. Only use the strict G729 or G729a modes when you have a specific reason to force one variant.

5. Always Enable Media Proxy for VOS3000 Transcoding

VOS3000 transcoding cannot function without media proxy. Always verify that media proxy is set to Auto or On on both the mapping gateway and routing gateway before enabling codec conversion. If media proxy is set to Off, VOS3000 will not intercept the RTP stream and cannot perform codec conversion.

6. Test After Every Configuration Change

Always test with actual calls after making any VOS3000 transcoding configuration change. Verify two-way audio, DTMF functionality, and call completion. Use the Current Call view to confirm that the correct codecs are being used on each side. For testing methodology, see our VOS3000 call testing guide.

By following these six best practices — minimizing unnecessary transcoding, using RFC2833 for DTMF, monitoring CPU utilization, configuring the correct G729 negotiation mode, always enabling media proxy, and testing after every change — you can ensure that your VOS3000 transcoding deployment delivers reliable, high-quality voice calls while efficiently utilizing your server resources.

VOS3000 Transcoding vs No Transcoding: Decision Guide

Not every VOS3000 deployment needs transcoding. In some cases, enabling VOS3000 transcoding unnecessarily can waste server resources and introduce quality issues. Use this decision guide to determine whether VOS3000 transcoding is needed for your deployment.

When VOS3000 Transcoding Is Required

• Your customers and vendors have no common codecs (e.g., customer only G711, vendor only G729)
• You need to optimize bandwidth by using G729 on one side while keeping G711 on the other
• You are interconnecting networks with different codec requirements
• You need to force a specific codec on a gateway for compatibility reasons
• You are connecting legacy SIP devices that only support G711 to modern G729-based networks

When VOS3000 Transcoding Is Not Required

• All your customers and vendors share common codecs (Auto negotiation will select the best match)
• You have low server CPU capacity and cannot afford the overhead of transcoding
• Your traffic volume is high enough that transcoding CPU cost would be prohibitive
• Both endpoints can natively agree on a codec without softswitch intervention

In summary: if your customers and vendors share common codecs, use Auto negotiation without transcoding. If they have no common codecs (e.g., customer G711 only, vendor G729 only), enable Softswitch specified with Allow codec conversion. For bandwidth optimization, force G729 on the WAN side and G711 on the LAN side. For G723 to G729 scenarios, use Softswitch G723 on the gateway side and G729 on the vendor side.

🔗 Related Resources

• 📖 VOS3000 Extended Firewall Configuration Guide
• 📖 VOS3000 Prefix Conversion and Callee Rewrite Rules
• 📖 VOS3000 One-Way Audio and No Voice Troubleshooting
• 📖 VOS3000 PIN Test and SIP Account Call Testing
• 📖 VOS3000 Concurrent Call Load Test with Multahost Server
• 📖 Faster Support for VOS3000 — Easy Troubleshoot Guide
• 📥 VOS3000 Downloads — Manual and Software

Frequently Asked Questions About VOS3000 Transcoding

❓ What is VOS3000 transcoding and when do I need it?

VOS3000 transcoding is the real-time conversion of voice media streams between different codecs (e.g., PCMA to G729). You need it when your caller and callee have incompatible codecs — for example, when a customer only supports G711 but your termination vendor only accepts G729. Without transcoding, these calls would fail due to codec mismatch. According to the VOS3000 Transcode Module documentation (Section 1.1), “When caller and callee voice codecs are incompatible, transcoding function can be used to make them compatible.”

❓ Where do I configure VOS3000 transcoding codec settings?

VOS3000 transcoding codec settings are located in the Additional Settings > Codec section of both mapping gateways and routing gateways. Navigate to Business Management > Routing Gateway/Mapping Gateway > Additional Settings > Codec, as documented in the VOS3000 Transcode Module documentation (Section 1.2, Page 1) and the VOS3000 Manual Section 2.5.1.1 (Pages 32, 47). You must configure both the mapping gateway (caller side) and routing gateway (callee side) for transcoding to work correctly.

❓ Does VOS3000 transcoding work without media proxy?

No. VOS3000 transcoding requires media proxy to be enabled because the softswitch must intercept the RTP media stream to decode and re-encode the audio in a different codec. Without media proxy, RTP flows directly between endpoints and VOS3000 cannot perform codec conversion. Always set media proxy to Auto or On on both gateways when enabling VOS3000 transcoding.

❓ What is the difference between Softswitch specified and Auto negotiation?

Auto negotiation allows endpoints to negotiate a common codec through the standard SDP offer/answer mechanism, with no transcoding needed if both sides share a codec. Softswitch specified forces VOS3000 to use a specific codec on each gateway side, regardless of what the endpoints offer. When you use Softswitch specified with different codecs on each side, VOS3000 transcoding is activated to bridge the codec gap. Use Auto negotiation when both sides share common codecs, and Softswitch specified when they do not.

❓ How does DTMF work during VOS3000 transcoding?

During VOS3000 transcoding with media proxy enabled, VOS3000 terminates all incoming DTMF signals (RFC2833, SIP INFO, or Inband) from one side and regenerates them on the other side according to the DTMF send settings configured for that gateway. RFC2833 is the recommended DTMF method for transcoded calls because VOS3000 can reliably terminate and regenerate the telephone-event packets. Inband DTMF should be avoided with G729 transcoding because codec compression distorts the DTMF tones.

❓ Why is my G729 transcoded call failing with a codec error?

G729 codec errors during VOS3000 transcoding are usually caused by G729 variant mismatches. Some devices only accept G729 while others only accept G729a, even though they are largely compatible. Try changing the G729 negotiation mode on the routing gateway to “G729&G729a” which offers both variants in the SDP, giving the remote endpoint the choice. If that does not resolve the issue, check that the vendor actually supports G729 and that the transcode module is properly installed and licensed.

❓ How much CPU does VOS3000 transcoding use?

VOS3000 transcoding is CPU-intensive, with each transcoded call consuming significantly more CPU than a pass-through call. The exact CPU usage depends on the codecs involved and the server hardware. G729 transcoding is more CPU-intensive than G711-to-G711 transcoding. Monitor your server’s CPU utilization during peak hours and ensure you have sufficient capacity. If CPU exceeds 80%, consider upgrading your server or reducing the number of concurrent transcoded calls. For load testing, see our VOS3000 concurrent call load test guide.

❓ Can I get professional help configuring VOS3000 transcoding?

Absolutely. Our VOS3000 specialists have extensive experience configuring transcoding for VoIP deployments of all sizes. We can help you determine when transcoding is needed, configure codec conversion on both mapping and routing gateways, optimize DTMF settings for transcoded calls, and troubleshoot any transcoding issues. Contact us on WhatsApp at +8801911119966 for expert assistance with your VOS3000 transcoding configuration.

Get Expert Help with VOS3000 Transcoding Configuration

VOS3000 transcoding is a powerful feature that enables your VoIP platform to interconnect diverse networks and endpoints, but it must be configured correctly to deliver reliable call quality. Misconfigured transcoding can cause no audio, one-way audio, DTMF failures, and excessive CPU load — all of which directly impact your customers’ experience and your business revenue.

Whether you are setting up VOS3000 transcoding for the first time, troubleshooting an existing configuration, or planning a large-scale deployment with multiple codec conversions, our team can help. We provide complete VOS3000 transcoding configuration services including codec analysis, gateway configuration, DTMF optimization, and performance tuning.

📱 Contact us on WhatsApp: +8801911119966

Our VOS3000 experts are available to help you configure transcoding for any scenario — from simple PCMA to G729 conversion to complex multi-codec deployments. We can also assist with server capacity planning to ensure your hardware can handle the transcoding load. For faster troubleshooting of any VOS3000 issue, see our VOS3000 easy troubleshoot guide.

📞 Need Professional VOS3000 Setup Support?

For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:

📱 WhatsApp: +8801911119966
🌐 Website: www.vos3000.com
🌐 Blog: multahost.com/blog
📥 Downloads: VOS3000 Downloads