How is codec priority managed on explosion-proof telephones?

Bad codec order turns a certified hazardous-area phone into a “working but unusable” endpoint. Calls connect, then sound rough, and the site blames the hardware.

Codec priority is managed by the SDP offer order from the phone and the policy on the PBX/SBC. The best results come from locking a per-account codec list, restricting codecs per trunk, and proving re-INVITE and payload mapping in FAT.

Codec priority is a negotiation policy, not a device checkbox

Codec order is decided in SDP, not on a datasheet

Codec priority is expressed by the order of codecs listed in the SDP ¹ offer. The phone can prefer one codec, but the server or peer still decides what gets used in the answer. This is why a phone can “support Opus” and still end up on G.711. The negotiation logic, not the marketing list, decides the call.

Priority exists in three places: phone, PBX, and SBC

In most hazardous-area deployments, the phone is not the only decision-maker. Codec order can be influenced by:

• The phone’s per-account codec enable list and priority order.

• The PBX dial plan or trunk policy, which may override the phone.

• The SBC, which can rewrite SDP and force a codec for the trunk.

So the first integration step is to pick who owns the policy. In my projects, the PBX or SBC owns policy. The phone follows a strict “safe set” list and only changes per site rule.

A safe “industrial codec set” that avoids surprises

For most sites, the stable set looks like:

• LAN calls: G.711 (PCMA/PCMU) and optional G.722

• WAN calls: G.729 or Opus (only if the trunk supports it) plus a G.711 fallback

• No “extra codecs” enabled unless there is a reason

Extra codecs create extra failure modes. The PBX might pick a codec the recorder cannot handle. Or a trunk might reject the offer and force a re-INVITE that some devices handle badly.

A practical policy table

| Link type | Preferred codec | Fallback codec | Why this works |

|—|—|—|—|

| Inside plant LAN | G.711 or G.722 | G.711 | simple and stable audio |

| Constrained WAN | G.729 | G.711 | saves bandwidth, keeps interop |

| SIP trunk to PSTN | G.711 | G.711 | wideband often not accepted |

| Dispatch recording | G.711 | G.711 | keeps recording clean |

FAT focus: confirm what gets used, not what is offered

A FAT should capture:

• SIP INVITE SDP from the phone

• 200 OK SDP from the server

• actual RTP payload and codec used

This removes guessing. It also catches hidden overrides at the SBC.

If this overall policy is clear, the detailed questions become easy to answer. The next sections go point by point on offer ordering, re-INVITE fallback, wideband restrictions, and payload remapping.

A good codec policy also helps OEM/ODM projects. When firmware or module options change, the policy stays stable and the acceptance tests stay the same.

Can per-account SDP offer orders be customized?

Codec order often looks fine on one account and wrong on another. That happens when a phone applies one global codec list, or when provisioning templates only affect one profile.

Per-account codec order can be customized on many SIP explosion-proof telephones, but not all. The safe approach is to require per-account codec enable and priority control, then verify the exact SDP offer order for each account in FAT.

Where per-account control matters most

Per-account codec control matters in these cases:

• One phone registers to a local PBX and a backup registrar.

• One account is for dispatch and one is for normal calling.

• One account goes to a narrowband trunk, and one stays on-net.

If a phone uses a single global codec list, the trunk side can poison the on-net side. For example, a trunk that rejects wideband can force the phone to remove it, and now the on-net calls lose HD voice too.

What to ask the supplier to confirm

Instead of asking “can you set codec priority,” ask this:

• “Can codec lists be set per SIP account?”

• “Does each account generate its own SDP offer order?”

• “Can provisioning set different codec priorities per account?”

• “Can the phone disable a codec completely per account?”

These questions are easy to test and hard to dodge.

A per-account provisioning template pattern

A simple pattern that works well:

• Account 1 (site LAN): allow G.711 + G.722

• Account 2 (WAN trunk): allow G.729 + G.711

• Disable everything else

This keeps negotiation clean and avoids odd re-INVITE cases.

FAT test steps that prove it

1) Place a call from account 1 to an on-net extension.

2) Capture the INVITE and confirm codec order.

3) Place a call from account 2 to a trunk destination.

4) Capture the INVITE and confirm codec order is different.

5) Confirm the selected codec matches the expected policy.

A per-account control table

| Requirement | What to test | Pass criteria |

|—|—|—|

| Separate codec lists | account 1 vs account 2 | lists are different |

| Separate SDP order | Wireshark capture | order follows policy |

| Provisioning works | push config file | phone applies without manual edits |

| Codec disable works | disable a codec | it never appears in SDP |

Per-account control is the cleanest way to manage mixed networks. If the phone cannot do this, the next best control is an SBC policy that rewrites SDP per trunk. But that shifts complexity to the network edge.

Is codec fallback handled during re-INVITE scenarios?

Codec fallback can sound like magic. A call starts on wideband, then the trunk changes, and the call continues on narrowband. But many devices do not handle codec changes cleanly.

Codec fallback during re-INVITE depends on the SIP stack. Some phones handle mid-call codec renegotiation well, while others treat it as a call restart risk. The safest design is to avoid mid-call codec switching unless the PBX/SBC requires it, then prove it in FAT.

When re-INVITE codec changes happen in real sites

Codec changes during re-INVITE commonly happen when:

• A call is transferred from on-net to a trunk.

• A call is moved through an SBC that forces a codec change.

• A conference bridge pulls the call into a different media policy.

• A recorder inserts itself and changes codec preference.

Many teams only test a basic call. They do not test transfer and conference paths, which are the main triggers for renegotiation.

Why codec renegotiation can fail

A device may fail because:

• It does not accept a new codec offer mid-call.

• It accepts the offer but does not switch RTP payload correctly.

• It resets jitter buffer and causes a loud gap.

• It mishandles DTMF settings when the codec changes.

So “fallback handled” must be proven, not assumed.

How to design so fallback is rare

The best method is to keep codec policy consistent across the call path:

• Use the same primary codec on both sides when possible.

• Do not offer wideband on calls that will go to PSTN trunks.

• Keep one clean fallback codec that every segment supports.

This reduces the chance that the PBX will need to renegotiate at all.

FAT tests that matter more than a normal call

A strong FAT includes:

• Attended transfer from on-net to trunk

• Blind transfer from trunk back to on-net

• Three-way conference creation and tear-down

• Hold/resume cycles

• DTMF IVR digit test during each scenario

If the phone survives these with clean audio and no reboot, codec fallback is likely safe on site.

A codec renegotiation acceptance table

| Scenario | What to observe | Pass criteria |

|—|—|—|

| On-net call then transfer to trunk | re-INVITE appears | call stays up, audio ok |

| Conference bridge inserted | new SDP offer/answer | no long mute, no drop |

| DTMF during renegotiation | digits sent and received | IVR gets all digits |

| RTP payload stability | payload type and codec match | no mismatched payload |

If renegotiation fails, the fix is often policy, not hardware. Force a single codec for that call route at the PBX/SBC, so the phone never sees a mid-call codec change.

Are wideband options blocked on narrowband trunks?

Wideband codec offers can waste time and cause odd call setup delays. Some trunks reject offers that contain unsupported codecs. Other trunks accept the call but downgrade it.

Wideband should be blocked on narrowband trunks using PBX/SBC trunk policies or per-account codec lists on the phone. The goal is to ensure the SDP offer to the trunk contains only narrowband codecs that the carrier accepts.

Why wideband and PSTN trunks often clash

Many PSTN-connected trunks deliver narrowband audio. Some carriers allow wideband only for on-net calls inside their network, and not for calls that break out to the PSTN. This can lead to:

• extra SDP negotiation steps

• early media confusion

• transcoding, which adds delay and can reduce quality

So it is better to keep trunk offers narrowband unless the trunk contract clearly supports wideband end-to-end.

Two clean ways to block wideband

1) Per-trunk policy on the PBX/SBC

• Route calls to trunk with a narrowband codec list

• Keep internal routes wideband-capable

2) Per-account codec list on the phone

• Account used for trunk only offers narrowband

• Account used for internal calls can offer wideband

In my view, the PBX/SBC method is stronger because it protects all endpoints, not only one phone model.

A safe trunk codec shortlist

For most trunks, the safe list is:

• G.711 PCMA/PCMU

• optional G.729 (only if allowed and licensed)

Avoid offering G.722 or Opus to the trunk unless you have proven interop with that carrier and the call route stays on-net.

What to test in FAT

• Place a call to a PSTN destination and confirm the offer contains only narrowband codecs.

• Confirm the answered codec matches policy.

• Confirm no extra call setup delay occurs due to renegotiation.

• Confirm recording and DTMF still work.

A trunk restriction table

| Call route | Allowed codecs | Blocked codecs | Why |

|—|—|—|—|

| Internal extensions | G.711, optional G.722 | none | best user quality |

| PSTN trunk | G.711, optional G.729 | G.722, Opus | avoids trunk mismatch |

| Dispatch bridge | G.711 | wideband unless tested | keeps monitoring stable |

Wideband blocking is not about “lower quality.” It is about predictable calls. In hazardous areas, predictability beats novelty.

Can payload types be remapped for legacy PBXs?

Payload types are a hidden trap in older systems. Modern SIP follows standard mappings for static payload types, but some legacy PBXs expect nonstandard assignments or require fixed dynamic payload numbers.

Payload types can sometimes be remapped, but it depends on the phone and the PBX. Static payload types for common codecs should follow standard RTP profiles, while dynamic payload types (96–127) can be assigned per session. Legacy systems that demand fixed mappings should be handled by an SBC or gateway when the phone cannot remap reliably.

What “payload type remap” really means

There are two worlds:

• Static payload types for classic codecs like PCMU and PCMA. These should stay standard for best interoperability.

• Dynamic payload types in the 96–127 range for codecs that do not have static assignments in the profile, or for vendor features.

Some legacy PBXs use fixed dynamic numbers in a fragile way. They may expect “G.729 is always PT=18” in every call, or they may break if DTMF events change payload types. Modern SIP endpoints normally negotiate dynamic types in SDP, so the receiver should follow the SDP, not a hard-coded number. But legacy systems do not always behave correctly.

Why phones should not carry the whole legacy burden

Even if a phone offers a “payload type” field, using it can create new problems:

• Two different peers might demand two different mappings.

• DTMF event payload might collide with another mapping.

• Updates in firmware might reset the mapping.

For these reasons, a gateway or SBC is the safer place to do payload normalization. It can:

• accept modern SDP from the phone

• rewrite payload mappings toward the legacy PBX

• keep the phone standard and stable

How to handle legacy PBX requirements safely

A safe plan looks like this:

• Keep the phone on standard settings.

• Place an SBC/gateway at the boundary to the legacy PBX.

• Remap only on that boundary, not on every endpoint.

• Document the mapping as a controlled configuration.

FAT tests that prove payload interop

• Confirm the phone’s SDP uses standard static payloads for G.711.

• Confirm DTMF events use a negotiated payload type and are decoded correctly.

• Confirm the legacy PBX receives correct audio and DTMF after mapping.

• Confirm hold/resume and transfer do not change mapping unexpectedly.

A payload mapping risk table

| Item | Low-risk approach | High-risk approach |

|—|—|—|

| G.711 payload | keep standard static PT | force custom static PT |

| G.729 payload | follow profile if static, else SDP dynamic | hard-code without SDP |

| DTMF events | negotiate via SDP | fixed PT that collides |

| Legacy normalization | do it at SBC/gateway | do it on each phone |

When a site has legacy PBX constraints, the boundary device is the right place to absorb complexity. The hazardous-area phone should stay simple and predictable.

Conclusion

Codec priority works best when policy is owned by PBX/SBC, per-account codec lists are clean, wideband is blocked on narrowband trunks, and re-INVITE and payload behavior are proven with FAT packet captures.

Footnotes