A hazardous-area phone can be fully certified and still sound terrible over a weak link. The problem is often a codec choice that was never tested in real network conditions.
Yes, many SIP explosion-proof telephones support G.729, but support depends on the SIP stack, firmware build, and licensing policy. The right result comes from locking the exact variant, bandwidth plan, and FAT test steps.
How to decide if G.729 is the right codec for a hazardous-area phone
G.729 is a bandwidth tool, not a quality tool
G.729 was built to save bandwidth. It is a common choice for remote tank farms, long microwave hops, and VPN 1 links that carry mixed traffic. In those places, G.711 can be too heavy, and the network jitter can spike during busy hours. A smaller codec can make the voice stream survive.
At the same time, G.729 adds more CPU work and more sensitivity to packet loss than G.711. The voice can also sound less natural. This matters in emergency calling, where clear speech is the main goal.
Make one simple rule for the project
My usual rule is: use G.711 inside the plant LAN, and use G.729 only across constrained links, unless the client has a strict policy. That keeps local calls clean and keeps WAN calls stable.
G.729 is “8 kbps” as a codec rate, but the real on-wire rate is higher because of IP/UDP/RTP headers, VLAN tags, and possible SRTP overhead. Packetization time (ptime) changes that overhead a lot. If ptime is too small, header overhead becomes the main cost. If ptime is too large, delay grows and speech can feel slow.
A quick codec decision table for Ex SIP phones
| Goal | Best codec choice | Why | Risk to manage |
|—|—|—|—|
| Best clarity | G.711 | simple and clean | higher bandwidth |
| Low bandwidth | G.729 | smaller payload | more sensitive to loss |
| Unstable WAN | G.729 with correct ptime | fewer bits per second | needs good jitter control |
| Safety calls | usually G.711 | clearer speech | ensure WAN capacity |
What “support” must mean in procurement
A datasheet line is not enough. “Support G.729” should mean:
-
the codec is selectable in the phone UI or provisioning file
-
the PBX can negotiate it in SDP
-
the phone keeps stable DTMF behavior under loss
-
the supplier can provide a compliance note on licensing and variants
The next sections break this into four checks that procurement teams can act on without guesswork.
Keep reading because the biggest failures happen when the wrong G.729 variant is assumed.
Which variants (G.729, G.729A/B) are licensed?
Wrong variant assumptions can create strange audio, weak VAD behavior, or a codec mismatch that forces transcoding. That is wasted bandwidth and extra delay.
G.729 support should be stated as a specific variant: base G.729, Annex A (G.729A), Annex B (VAD/DTX/CNG), or Annex AB. Confirm the “annexb” setting, because it changes silence behavior and bandwidth.
What each variant really means
G.729 “base” is the core codec. Annex A 2 (often shown as G.729A) is a lower-complexity version that trades a small amount of speech quality for less CPU use. Many SIP systems treat G.729 and G.729A as equivalent at the RTP payload level, so the endpoints must still be compatible in practice.
Annex B is not a different voice codec. It is the silence handling package:
-
VAD (voice activity detection)
-
DTX (discontinuous transmission)
-
CNG (comfort noise generation)
Annex AB is a common shorthand for using Annex A plus Annex B behavior.
Why the “annexb” parameter matters
Many SIP stacks signal whether Annex B is used with an SDP parameter like annexb=yes or annexb=no. If one side expects comfort noise and the other side does not, the call can still connect, but silence can feel strange. Some recording systems also behave differently when DTX is used.
In plants with constant background noise, VAD can misread the environment. It may keep sending full-rate frames all the time, or it may clip speech starts. So the project needs a clear choice: Annex B on or off.
How to write this cleanly in a purchase spec
A simple, audit-friendly wording is:
-
“Endpoint shall support G.729 and G.729A interoperability.”
-
“Endpoint shall support configurable Annex B (VAD/DTX/CNG) on/off.”
-
“SDP shall advertise annexb parameter and obey it.”
A variant checklist table
| Item | What to request | Why it prevents conflict |
|—|—|—|
| Base codec | G.729 and/or G.729A | avoids “works only with one peer” |
| Silence mode | Annex B on/off control | controls bandwidth vs artifacts |
| SDP signaling | annexb parameter behavior | avoids hidden defaults |
| Interop proof | packet capture screenshots | proves real negotiation |
Once the variant is locked, the next question is capacity. People ask “how many calls,” but an Ex telephone is not a gateway. The right answer depends on what “concurrent” really means.
How many concurrent G.729 calls are supported?
A project can fail when a phone is expected to do conference mixing or multiple streams, then the hardware behaves like a simple endpoint. The result is dropped audio or rejected call attempts.
Most explosion-proof SIP telephones are endpoints, so “concurrent calls” usually means the number of call legs the phone can manage (active, held, waiting, or 3-way). True simultaneous media streams depend on the firmware and DSP budget, so it must be proven on the exact model.
Define “concurrent” in a way that matches reality
There are three different meanings in projects:
1) Simultaneous registrations (two SIP accounts registered at once)
2) Call states (one active call plus one held call, plus call waiting)
3) Simultaneous media streams (3-way conference or paging with mixing)
Many industrial phones can register two accounts and can hold a second call. That does not always mean they can mix a 3-way call with G.729. Mixing is heavier than a single stream. If the phone has no local mixing, the PBX can do the conference, and the phone only carries one stream.
So the safe rule is: treat the phone as one active media stream at a time, unless the vendor proves more.
What impacts G.729 concurrency
G.729 uses more processing than G.711 on many embedded stacks. If SRTP is also enabled, CPU load increases. If the phone is running extra apps or services, the margin shrinks. That is why a “two-line phone” can still behave like “one-call audio” in hard conditions.
A clear FAT method for concurrency
A FAT should not guess. It should test:
-
two registrations (primary + secondary or two accounts)
-
active call + call waiting
-
hold/resume behavior
-
3-way conference (if required)
-
call transfer (attended and blind), if required for the site
If the project requires emergency paging plus a live call, test that exact scenario. Some plants want a beacon trigger or multicast paging. That can add a second stream.
A practical acceptance table
| Requirement | Test step | Pass condition |
|—|—|—|
| Dual accounts | register both accounts | stable registration for 1 hour |
| Call waiting | inbound call during active call | correct alert and user control |
| Hold/resume | hold and resume 10 cycles | audio returns cleanly |
| 3-way (if needed) | conference 3 endpoints | stable audio, no reboot |
| SRTP + G.729 | enable both | no CPU overload symptoms |
If the vendor cannot guarantee more than one active stream, the system can still meet the project goal by moving mixing to the PBX or SBC.
Next comes the bandwidth feature many teams want: VAD/CNG. It can save bits, but it can also create strange audio in noisy refineries.
Does VAD/CNG reduce bandwidth without artifacts?
The promise of VAD sounds perfect on paper. In the field, it can clip words or create a “dead silence” that alarms operators.
Annex B VAD/DTX/CNG can reduce bandwidth during real silence, but it can add artifacts in noisy plants and can confuse users or recorders. It should be selectable per line, and tested with real background noise.
What bandwidth saving looks like in practice
With DTX enabled, the phone sends fewer full speech frames during silence. It sends small SID updates instead, and the far end plays comfort noise. This can cut average bandwidth on quiet calls. The gain is smaller on busy radio-style calls where people talk often.
The important detail is “real silence.” Refineries, terminals, and mines are rarely quiet. A constant rumble can push the VAD into “always active” mode. In that case, bandwidth saving becomes small, but artifacts can still appear at speech edges.
Common artifact patterns and how to control them
-
Clipped first syllables: VAD waits too long to switch from silence to speech.
-
Pumping noise: comfort noise level jumps or sounds unnatural.
-
Recorder gaps: some recording systems prefer continuous audio.
A simple control is to disable Annex B on emergency phones or dispatcher lines, and enable it only on non-critical lines where bandwidth is tight.
How jitter and loss change the outcome
DTX does not fix packet loss. It can make loss feel worse in some cases, because the listener expects a steady noise floor. If the network drops SID frames, the comfort noise can vanish, then return suddenly. That can feel like a mute button, not like a network issue.
So VAD and jitter buffer settings should be reviewed together. If the link is unstable, a stable noise floor can help users understand speech better.
A VAD/CNG decision table
| Site condition | Annex B setting | Why |
|—|—|—|
| Safety call points | Off | clarity and predictability |
| Clean WAN, low noise | On | real bandwidth saving |
| Noisy plant areas | Often Off | avoids clipped speech |
| Recorder-driven sites | Often Off | avoids gaps or odd noise |
The last question is the one that decides procurement risk: licensing and audit documents. Many projects assume “patents expired,” so documents do not matter. Auditors often disagree.
Are patents and licensing documented for audits?
Codec licensing can become a surprise during a tender review. The buyer asks for proof, and the supplier has only a datasheet line. That delays the project.
G.729 patent and licensing history is complex, so procurement should request written licensing and usage statements for the exact firmware build. Even when royalties are low or patents have expired, copyright and redistribution terms can still matter in audits.
What auditors usually want to see
Audits may not focus on G.729, but procurement teams often do. The main request is simple: “prove this codec use is legal and traceable.” A clean supplier package usually includes:
-
a statement of codec availability by model and firmware version
-
the source of the codec implementation (in-house, licensed library, or platform vendor)
-
a licensing note that covers patents and distribution rights
-
a change-control record so the codec build does not change silently
For OEM/ODM, this matters even more. Small firmware changes can replace the codec library. A project can ship with one build and deliver another build. That creates risk.
A practical “proof pack” that works in global projects
Here is what I keep ready when a client asks:
-
model and firmware ID list (hash or version number)
-
codec list per firmware profile (G.711, G.729, others)
-
licensing statement from the codec provider (or platform vendor)
-
declaration of conformity style note for software options (not an Ex document, but a supply-chain document)
-
test report summary showing the codec negotiated and used in calls
This keeps the discussion factual. It also protects the buyer during internal compliance review.
How to handle “royalty-free” claims safely
Even if a supplier says “G.729 is free now,” the buyer still needs traceability. Some companies keep internal policies that require a license letter anyway. Also, distribution of some reference code or binary packages can have rules that are not about patents. So a short written statement is still valuable.
A licensing and audit table
| Audit question | Best document to provide | What is not enough |
|—|—|—|
| Which G.729 variant is used? | firmware codec matrix | a marketing brochure |
| Is it licensed for distribution? | license letter or supplier declaration | “trust us” email |
| Can OEM branding change the build? | change-control and BOM control | verbal promise |
| Was it tested on the target PBX? | FAT packet capture + report | “works with most PBX” |
If a project needs a clean proof pack for EPC bidding, that can be supplied as part of the submittal set. For OEM/ODM builds, it is also normal to lock codec options as a controlled variant in the order.
For support on codec selection and compliance-ready documentation for hazardous-area phones, Jason Mark can be reached at info@sipintercommanufacturer.com.
Conclusion
G.729 can work well on Ex SIP phones, but only when the exact variant, concurrency limits, VAD policy, and licensing proof are locked and validated in FAT.
