I have an issue where agent is unable to hear audio from Telecel callers(+233 50 or +233 20) only but works for other carrier providers MTN GH and AirtelTigo. Strangely the audio is clear when you listen to the recorded session on the asteriskPBX. How do we resolve this?

Thanks for reaching out, John. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

here's a sample incoming call for telecel number capture on the asterisk server.

Thanks — I see the SIP/SDP capture you shared from your Asterisk/VoIPNow session for the Telecel incoming call. You mentioned agents can’t hear Telecel callers live, but the recording is clear. I’ll walk through what the capture shows and give targeted next steps to diagnose and fix the one-way audio. What the capture shows (key facts) • The INVITE SDP offers audio codecs: PCMU (payload 0 / G.711 u-law), GSM (payload 3), and telephone-event (DTMF). The media line is:

m=audio 10092 RTP/AVP 0 3 101

and

a=rtpmap:0 PCMU/8000

. • The SIP exchange completes (100/200/ACK), so signaling succeeds and media is established. • Because recordings are clear on the PBX, the media is being received and stored by the PBX/Asterisk, which implies the problem is specific to the real-time forwarding/playback path toward the agent endpoints. Most likely causes given that evidence • Codec negotiation or transcoding mismatch during real-time forwarding (even though G.711 is offered, a different codec or a transcoder step may be used for agents). • RTP packets are arriving at the server but not reaching the agent (one-way audio due to NAT/firewall, SSRC mismatch, or SFU/bridge forwarding issue). • Carrier-specific behavior (Telecel network may apply silence suppression/DTX, jitter, or packet modifications) that interferes with live playback but not with recording/transcoding. • DTX/silence suppression or comfort-noise handling causing perceived silence on agents. Targeted steps to diagnose and resolve 1. Confirm negotiated codec in the 200 OK/ACK for the Telecel call ◦ Inspect the 200 OK SDP for that call to confirm which codec was selected for the media stream. If the negotiated codec is PCMU, that rules out codec mismatch; if GSM or another codec was chosen, force G.711 as a test. 1. Force G.711 for Telecel numbers and retest ◦ For the +23350 / +23320 ranges, configure your SIP trunk or Asterisk dialplan to prefer/force PCMU (G.711 u-law). G.711 is the least likely to require transcoding and often eliminates one-way problems caused by codec handling. ◦ Example: in your Asterisk dialplan or trunk codec settings, set allowed codecs to

PCMU

(and disable GSM for this route), then place a test call. 1. Capture RTP and check packet flow both directions ◦ Take a short pcap of the failing live call and inspect RTP for: ▪︎ RTP packets from the Telecel party to your PBX (SSRC, sequence numbers, payload type). ▪︎ RTP forwarding from PBX -> agent (are packets being sent? different SSRC?). ◦ Look for high packet loss, large jitter, or one-way arrival (RTP arriving to PBX but not outbound to agent) which indicates NAT/firewall or SFU/bridge forwarding issues. 1. Check NAT/firewall and RTP port mappings ◦ Ensure your PBX/SFU/bridge is allowed to open and forward RTP ports to agent endpoints, and that symmetric NAT or firewall rules aren’t blocking RTP to agents. ◦ If agents are remote (behind NAT) confirm STUN/TURN usage or that RTP is reachable from your PBX/bridge. 1. Disable DTX/silence suppression on the Telecel trunk ◦ Turn off DTX or silence suppression for calls from Telecel to rule out missing packets during silent frames. Some mobile carriers’ DTX interacts poorly with WebRTC playback or SFUs. 1. Compare RTP stats vs recorded file ◦ Since the recording is clear, extract timestamps of the recorded call and correlate RTP sequence numbers and packet loss during the same period in the live trace. If RTP reached the PBX intact but was altered or dropped when forwarded, that narrows the fault to the PBX->agent path. 1. Test a direct bridge to an agent (bypass any transcoder) ◦ Create a minimal call path: inbound Telecel -> Asterisk -> single test agent with no processing/transcoding. If agent hears audio, gradual enablement of processing components will reveal the failing component. What I can help you run next • If you can share the 200 OK SDP (the answer SDP) for the same call, I’ll confirm the negotiated codec and payload types and give exact trunk/dialplan changes to force G.711. • If you can provide a short pcap (or RTP stats) for a failing call, I’ll help read it and point to whether packets are being forwarded to agents or being lost/dropped. • Tell me whether agents use WebRTC endpoints (LiveKit/Browser) or SIP phones — that changes the NAT/codec handling steps I’ll recommend next. Pick one of the following and I’ll give the exact commands/checks: • Share the 200 OK SDP (text) for the call. • Upload a short pcap or paste RTP/RTCP stats for that call (showing packet loss/jitter). • Confirm whether agents use WebRTC (browser/mobile app) or SIP phones. I’ll wait for the 200 OK SDP or the pcap and then provide the concrete steps to change trunk settings or verify RTP forwarding. Sources: Introducing LiveKit Phone Numbers: zero to ringing in 60 seconds | LiveKit | sip | livekit/livekit_composite | DeepWiki | How Vicidial Handles Bridging, Transfers, and SIP Calls | Accepting calls overview | LiveKit Documentation | Streamline troubleshooting with Agent Observability | LiveKit

here's another sample telecel session logs from livekit.

Thanks — I’ve reviewed the LiveKit session screenshots and the Asterisk/VoIPNow SIP capture you supplied. I’ll summarize what we know and the exact next diagnostics I need to pinpoint the root cause and give a precise fix. What I see so far • The INVITE SDP from the Telecel call offers PCMU (G.711 u-law), GSM, and telephone-event. Signaling completes (100/200/ACK), so the call is established. • LiveKit session shows an audio track published as

audio/opus

and packet-loss graphs. The LiveKit dashboard indicates RTP/track telemetry is available and packet-loss points appear at specific timestamps (one screenshot shows packet loss at 0% at 25914 but the graphs indicate some variability across sessions). • Recordings on Asterisk are clear, which means the PBX receives usable audio, but agents don’t hear Telecel callers in real time — this points to an issue in the real-time forwarding or codec/transcoding path (PBX/SFU -> agent) rather than the media being entirely lost upstream. What I need from you to narrow this down (pick any you can share) 1. The 200 OK SDP (answer) for the same Telecel call ◦ This confirms the negotiated codec and payload types. If the 200 OK selected PCMU, we can rule out codec mismatch; if it selected GSM (or later transcoding to opus), that’s important to know. 1. RTP/RTCP stats or a short pcap for a failing call ◦ A short pcap (30–60s) or RTP stats showing packet counts, loss, jitter, SSRCs and payload types for the problematic timeframe will show whether RTP packets are forwarded to agents or dropped/altered. ◦ If you can’t share a pcap, paste the LiveKit per-track RTP stats (sent/received packets, packets lost, jitter) for the Telecel track and the agent’s subscribed track at the same timestamps. 1. Agent endpoint type ◦ Are agents using WebRTC (browser/mobile app via LiveKit) or SIP phones/softphones? WebRTC implies opus/rtcp/jitter-buffer differences and possible need for TURN; SIP phones imply different NAT/trunk handling. 1. Trunk/traverse settings you control ◦ Can you temporarily force codecs on your Asterisk trunk for the Telecel number ranges? Being able to set allowed codecs to only

PCMU

for +23350/+23320 is helpful for quick tests. ◦ Can you disable DTX/silence suppression for that trunk? Immediate tests you can run right now (fast checks) 1. Inspect the 200 OK SDP for payload negotiation (paste it here). 2. Force G.711 (PCMU) on the Telecel trunk and place a test call. Does the agent hear the caller? 3. On LiveKit dashboard during a failing call, capture a screenshot of per-track RTP stats (packets sent/received, packets lost) for both the Telecel publisher track and the agent’s subscribed track at the same timestamps. 4. If you can run tcpdump on the PBX during a failing call, capture RTP for the call ports and share a short pcap (I can give exact filters once you confirm you can capture). Likely fixes I’ll guide you through once you share one of the above • Force/verify G.711 end-to-end for Telecel calls to avoid problematic transcoding. • Disable DTX on Telecel trunks. • Confirm RTP forwarding and NAT/port mappings from PBX/SFU to agents; enable TURN if agents are WebRTC and NATed. • Apply a telephony-optimized audio processor (telephony noise cancellation) for SIP-originated tracks if transcoding to opus causes issues. Which of the items above can you provide right now — the 200 OK SDP, RTP stats/pcap, or confirm agent endpoint type? Send that and I’ll give the exact commands/config edits and packet filters to run.

is it possible to specify a particular codecs for telecel calls on the livekit trunk?

Short answer: Yes — LiveKit supports G.711 (PCMU/PCMA) and will negotiate codecs during SIP handshakes, but LiveKit doesn’t expose a per-number “force codec” toggle for inbound trunks. You can influence codec selection by controlling what codecs your PBX/trunk advertises and by specifying codec preferences when creating outbound SIP participants. What this means for your Telecel calls • LiveKit advertises and supports G.711 (PCMU/PCMA) and G.722 for SIP media. If both sides offer G.711, the call will use it. • There isn’t a documented per-trunk/phone-number setting in LiveKit to forcibly override the negotiated codec on inbound calls. Instead, codec selection is determined by SIP SDP negotiation between the carrier/PBX and LiveKit. Practical steps to ensure Telecel uses G.711 (recommended) 1. Force/limit codecs on your PBX/trunk for Telecel ranges (+23350 / +23320) ◦ On your Asterisk/VoIPNow trunk or dialplan, set allowed codecs to only PCMU (or PCMA) for those numbers and re-test. This ensures the INVITE/200OK exchange only contains G.711, so LiveKit will negotiate G.711. 1. Confirm negotiated codec in the 200 OK SDP ◦ Inspect the 200 OK SDP returned in the Telecel call. If it lists

PCMU/8000

as the selected payload, the media is G.711 end-to-end; if not, adjust the PBX trunk to advertise only G.711. 1. For outbound calls through LiveKit (if applicable) ◦ When creating SIP participants for outbound calls you can indicate codec preferences so LiveKit will attempt to negotiate those codecs with the carrier endpoint. 1. If you still see one-way audio after ensuring G.711 is negotiated ◦ Capture RTP/RTCP stats or a short pcap during a failing call and compare: ▪︎ RTP arriving at your PBX (Telecel -> PBX) ▪︎ RTP forwarded from PBX/SFU to the agent (PBX -> LiveKit/agent) ◦ Check for packet loss, NAT/firewall issues, DTX/silence suppression, or SSRC mismatches in the forwarding path. If you want, I can: • Tell you exactly what to look for in the 200 OK SDP (paste it here) and show how to confirm the negotiated codec. • Provide the Asterisk/VoIPNow dialplan/trunk lines to force PCMU for the Telecel number ranges (tell me which PBX you’re using and I’ll give the exact config). • Walk through capturing the pcap or reading the LiveKit per-track RTP stats to confirm whether RTP is being forwarded to agents. Which would you like to do next — paste the 200 OK SDP, or tell me your PBX type so I can provide the exact dialplan/trunk changes to force G.711? Sources: Agents telephony integration | LiveKit Documentation | test/integration/sip_test.go | sip | livekit/livekit_composite | DeepWiki | g711/alaw.go

host=196.X.X>X type=peer context=from-trunk disallow=all allow=ulaw,alaw&opus trustrpid=yes insecure=port,invite canreinvite=no transfer=yes allowsipguests=no qualify=yes directmedia=no nat=force_rport,comedia rtpsymmetric=yes allowrefer=yes here's the incoming trunk settings on the asterisk.

Thanks — this is helpful. I can see your trunk currently disallows all codecs then allows

ulaw,alaw&opus

, and has NAT/RTCP-related options enabled. That gives us good levers to force G.711 for Telecel calls. Why forcing G.711 helps • G.711 (ulaw/PCMU or alaw/PCMA) avoids narrowband transcoding steps and is widely interoperable with carrier trunks and WebRTC/SFUs. Forcing ulaw for Telecel calls removes codec-negotiation ambiguity and often fixes one-way/playback problems caused by transcoding or carrier-side codec handling. Recommended quick changes on the Asterisk trunk (safe to test) 1. Limit allowed codecs for Telecel inbound routes to PCMU (ulaw) only ◦ You can do this either on the trunk (if you have a dedicated Telecel trunk) or in the dialplan for calls matching the +23350/+23320 ranges. Example — trunk-level (sip.conf or chan_sip style): • Change: ◦ allow=ulaw,alaw&opus • To: ◦ allow=ulaw Example — dialplan force (extensions.conf) for matching DID ranges: 1. Create a context for Telecel calls and set codec preference before routing to the usual context. 2. Use the

Set

and

G722

style or prefer codec via SIP channel vars if needed. Minimal dialplan snippet (conceptual): 1. Create an entry point for Telecel DID: ◦ exten => _0242XXXXXXX,1,NoOp(Inbound Telecel) ◦ exten => _0242XXXXXXX,n,Set(PJSIP_CODEC_PREFERENCE=pcmu) ◦ exten => _0242XXXXXXX,n,Goto(from-trunk,${EXTEN},1) (Exact variable name may depend on chan_sip vs chan_pjsip; tell me which driver you use and I’ll provide exact lines.) 1. Disable DTX/silence suppression for those calls ◦ On the trunk or in the gateway configuration, ensure silence suppression/DTX is off. Some carriers’ DTX breaks real-time forwarding but recordings can still look fine. 1. Keep NAT/rtp settings (rtpsymmetric, comedia) enabled — these are usually correct ◦ Your

nat=force_rport,comedia

,

rtpsymmetric=yes

, and

directmedia=no

are appropriate for gateway->Asterisk->agent scenarios. Leave them in place during tests. 1. After change, verify negotiated codec in the 200 OK SDP ◦ Place a test call from a Telecel number and capture/paste the 200 OK SDP here (or check Asterisk CLI logs). The 200 OK should show

a=rtpmap:0 PCMU/8000

or equivalent as the chosen codec. If you’re using chan_pjsip (PJSIP) vs chan_sip (chan_sip) — tell me which one and I’ll provide exact config lines: • For chan_sip: the

allow=

change above is appropriate in sip.conf. • For chan_pjsip: use

allow = ulaw

in the endpoint/transport config or set

audio_codec

preferences in the PJSIP config; the dialect differs slightly. Extra diagnostics if one-way persists after forcing ulaw • Capture a short pcap during a failing call and check: ◦ RTP from Telecel -> Asterisk (payload type, SSRC, packets) ◦ RTP from Asterisk -> LiveKit/agent (are packets being forwarded? different SSRC? dropped?) • Paste the 200 OK SDP here if the negotiated codec still isn’t PCMU after the change. • Share whether agents use WebRTC or SIP phones — WebRTC requires opus negotiation and may need transcoding on Asterisk or LiveKit; if agents use WebRTC and you force PCMU on the trunk, the PBX/bridge or LiveKit will transcode PCMU <-> opus which usually works reliably. Which SIP driver do you run (chan_sip or chan_pjsip)? I’ll give the exact config/dialplan snippet to implement

allow=ulaw

or the PJSIP equivalent and a short test plan to validate.

chanpjsip

Great — thanks for confirming you’re on chan_pjsip. Below are concise, safe steps you can apply to force G.711 μ-law (ulaw/PCMU) for Telecel inbound calls, why this helps, and what to check after you make the changes. Why force ulaw (PCMU) • G.711 (ulaw) is widely interoperable and avoids problematic transcoding. For Telecel calls that show one-way live audio but clear recordings, forcing PCMU end-to-end often eliminates real-time playback issues caused by codec mismatch, mobile-carrier DTX, or intermediate transcoding. Steps to force PCMU for Telecel inbound calls (chan_pjsip) 1) Create a dedicated endpoint/identify a match for Telecel DID ranges • If you have a single inbound endpoint handling many carriers, the simplest approach is to set codec preferences on the inbound AOR/endpoint used for Telecel calls, or create a separate endpoint/transport used only for Telecel numbers and point Telecel DID routing to it. 2) Set allowed codecs to ulaw in the PJSIP endpoint config • In your pjsip endpoint (or the endpoint template used for the Telecel inbound route), add or change:

[telecel-endpoint]
type = endpoint
context = from-trunk
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
direct_media = no

• If you use an endpoint template, add

allow = ulaw

there and ensure the Telecel calls use that template. 3) Option: restrict codecs on the AOR/transport or in inbound trunk match • If you cannot change the endpoint, set the codec on the inbound section that matches the Telecel DID in pjsip.conf or via dialplan variables before bridging:

[aor-telecel]
type = aor
contact = ...
; ensure matching to telecel-endpoint

(Exact layout depends on your config structure — tell me if your pjsip.conf uses templates and I’ll tailor the snippet.) 4) Dialplan alternative (if you prefer to force per-call) • If modifying endpoints is inconvenient, set the codec preference in the dialplan before bridging:

exten => _0240XXXXXXXX,1,NoOp(Inbound Telecel)
 same => n,Set(PJSIP_CODEC_PREFS=pcmu)
 same => n,Goto(from-trunk,${EXTEN},1)

• Note:

PJSIP_CODEC_PREFS

is commonly supported; if not, let me know and I’ll provide the exact channel variable for your Asterisk version. 5) Disable DTX/silence suppression if enabled on any gateway • Some carriers or gateways introduce DTX that can create gaps. Ensure any voice gateway or upstream trunk config does not enable silence suppression for Telecel calls. Validation steps after change 1. Make a Telecel test call and capture the SIP 200 OK SDP (paste the full answer SDP here). Confirm it shows PCMU/8000 (a=rtpmap:0 PCMU/8000 or similar). 2. On the LiveKit session dashboard during the same call, check the published audio track’s codec kind (should show audio/opus for a WebRTC endpoint, but the PBX->LiveKit negotiation should be PCMU on the SIP leg). 3. Optionally capture a short pcap on the Asterisk host and verify: ◦ RTP from Telecel -> Asterisk uses payload type for PCMU. ◦ Asterisk -> LiveKit/agent RTP is being forwarded (no packet loss on that leg). If the call still exhibits one-way audio after forcing ulaw • Share the 200 OK SDP from the failed call and a short pcap or LiveKit per-track RTP stats for the timeframe. I’ll analyze whether packets are being forwarded and where they’re being dropped or transcoded. Tell me which option you want: • I can give a ready-to-paste pjsip.conf snippet matching your current config (if you paste your pjsip.conf endpoint block or template). • Or try the dialplan PJSIP_CODEC_PREFS approach and paste the 200 OK SDP after testing. I’m here to craft the exact lines you need for your setup — paste the relevant pjsip.conf endpoint/template if you want a tailored snippet. , with interactive elements

I used the dialplan approach and it still not working. I noticed when I speak close to the phones microphone it catches some of the audio but not all and in essence given just chunk of it to the agent. most of the time it does not hear me at all. let's fix this. captured some packets as well on the

Thanks — I can tell this is frustrating, and I appreciate the detail and packet screenshots. You’ve already tried forcing ulaw in the dialplan and still see very choppy/near-silent audio except when speaking very close to the phone mic. That pattern strongly points to RTP-level problems (loss/jitter, DTX/silence suppression) or a mismatch in how RTP is forwarded/transcoded to the agent side — not just codec negotiation alone. I’ll list the most likely causes based on what you reported, then give a focused set of checks and immediate changes to run. After those, I’ll ask for two small artifacts (a 200 OK SDP and a short pcap or LiveKit per-track RTP stats) so I can pinpoint the exact failure and give the final fix. Why this is happening (summary from your symptoms) • Recordings are clear → the PBX receives and stores the audio correctly. • Live audio to agents is mostly silent except for loud close-mic speech → either: ◦ RTP packets are being lost, delayed, or treated as “silence” on the live forwarding path (DTX/silence suppression or aggressive jitter buffer dropping), or ◦ The PBX/bridge is doing intermittent or incorrect transcoding to the agent codec (opus for WebRTC), or ◦ RTP/SSRC mapping or NAT issues cause the SFU/agent to ignore most packets (only bursts get through). Immediate checks and actions (please run these in order) 1) Confirm negotiated codec in the 200 OK SDP (one-line quick check) • Capture/paste the full 200 OK SDP for a failing call (the answer from the far side). We need to confirm the payload type actually used (should be PCMU/8000 if ulaw succeeded). • If the 200 OK shows anything other than PCMU (e.g., GSM), that’s important. 2) Disable DTX/silence suppression end-to-end • Ensure any upstream gateway / carrier trunk is not doing silence suppression for Telecel numbers. • In Asterisk/PJSIP, disable any voice activity detection/silence detection features on the inbound endpoint or trunk. • Also check any intermediary SBC or media gateway for DTX/CNG settings and turn them off for Telecel calls. 3) Increase jitter-buffer tolerance and logging on Asterisk • Temporarily increase Asterisk jitter buffer and enable RTP debugging for the call to see late packets being dropped: ◦ In pjsip.conf endpoint: set

timers=yes

and ensure jitter buffer params are set higher (example depends on version — I can give exact params if you want). ◦ On the Asterisk CLI during the test run: enable

rtp set debug on

(or use tcpdump) and watch sequence number gaps and retransmissions. • If you see many late/duplicate packets, increase jitter buffer sizes so agent playback is smoother. 4) Verify RTP forwarding from Asterisk -> LiveKit/agent • Capture a short pcap on the Asterisk host for one failing call (30–60s). Filter example: ◦ If the RTP port in the SDP is 55470, use:

tcpdump -i any host <other-party-ip> and udp and port 55470 -w telecel_rtp.pcap

• We’ll compare: ◦ RTP from Telecel -> Asterisk (are packets coming in normally?) ◦ RTP from Asterisk -> LiveKit/agent (are packets being forwarded? same SSRC or being remapped? any packet loss?) • If you cannot send a pcap, export LiveKit per-track RTP stats (packets sent/received, packets lost, jitter) for the same timestamps. 5) Check NAT/rtp_symmetric and direct_media interplay • You have

rtp_symmetric=yes

,

force_rport=yes

,

direct_media=no

— those are generally correct. But if LiveKit agents use WebRTC (opus) and Asterisk is doing PCMU->opus transcoding, confirm Asterisk is actually performing the transcoding and forwarding frames in real time. • If agents are behind restrictive NAT, ensure TURN is available for WebRTC or that RTP flows are reachable. 6) Force PCMU at pjsip endpoint (not just dialplan) and reload • You mentioned using the dialplan approach. For chan_pjsip it’s often more reliable to set

allow = ulaw

on the endpoint or transport that these Telecel DIDs use. If you haven’t already patched the actual endpoint used by the call, please apply the endpoint-level

allow = ulaw

and reload pjsip. • After changing, place a test call and paste the 200 OK. 7) Check Asterisk console for dropped frames / transcoder logs • During the failing call, watch the Asterisk CLI: any “transcoding” warnings, “dropped RTP packets”, or “jitter buffer” messages will point to the root cause. What to capture and share so I can analyze precisely • The full 200 OK SDP for a failing Telecel call (paste the text). • A short pcap (30–60s) covering both RTP directions for the call OR LiveKit per-track RTP stats for the same timestamps (packets sent, received, packets lost, jitter). • Tell me agent endpoint type: WebRTC (browser/app) or SIP phone? If you prefer, I’ll give exact pjsip.conf lines and the tcpdump filter based on the real SDP port/addresses you paste. Quick prioritized next action I recommend you do now • Disable DTX/silence suppression on the Telecel gateway/trunk and increase the jitter buffer on the pjsip endpoint, then place a test call and paste the 200 OK SDP here. If that doesn’t fix it, grab the short pcap and I’ll analyze packet loss/jitter/SSRC issues and provide the exact fix. I’m ready to analyze the 200 OK SDP or pcap as soon as you paste/upload them and will give step-by-step commands/config edits to resolve this. , with interactive elements