One way audio, level3 in aws

FreePBX Configuration
1

Have a new rash of one way audio problems.
Problem only happens on calls coming into the system. Not outbound calls.
Calls are get delievered to a private IP space from level 3.
they are landing in an asterisk instance and get forwarded to another asterisk instance.
The caller ie cell phone hear’s no audio till he call is put on hold and then they hear everything as normal.

in sniffer traces I don’t see any port for rtp changing between the sbc asterisk instance or from the asterisk instance to the client. below are the settings at the sbc

The sbc is in networks 10.123.244.0 , the asterisk host for users is in 10.123.245.0 Level 3 is in the 8.49.149.136 network. Note thats its not over the internet, is over here IPVPN product, think mpls for AWS so no nat.

server1*cli>sip show settings

Global Settings:

UDP Bindaddress: 0.0.0.0:5060
TCP SIP Bindaddress: Disabled
TLS SIP Bindaddress: Disabled
RTP Bindaddress: Disabled
Videosupport: No
Textsupport: No
Ignore SDP sess. ver.: No
AutoCreate Peer: Off
Match Auth Username: No
Allow unknown access: Yes
Allow subscriptions: Yes
Allow overlap dialing: No
Allow promisc. redir: No
Enable call counters: No
SIP domain support: No
Path support : No
Realm. auth: No
Our auth realm asterisk
Use domains as realms: No
Call to non-local dom.: Yes
URI user is phone no: No
Always auth rejects: Yes
Direct RTP setup: No
User Agent: Asterisk PBX 16.11.1
SDP Session Name: Asterisk PBX 16.11.1
SDP Owner Name: root
Reg. context: (not set)
Regexten on Qualify: No
Trust RPID: No
Send RPID: No
Legacy userfield parse: No
Send Diversion: Yes
Caller ID: asterisk
From: Domain:
Record SIP history: Off
Auth. Failure Events: Off
T.38 support: No
T.38 EC mode: Unknown
T.38 MaxDtgrm: 4294967295
SIP realtime: Disabled
Qualify Freq : 60000 ms
Q.850 Reason header: No
Store SIP_CAUSE: No

Network QoS Settings:

IP ToS SIP: CS0
IP ToS RTP audio: CS0
IP ToS RTP video: CS0
IP ToS RTP text: CS0
802.1p CoS SIP: 4
802.1p CoS RTP audio: 5
802.1p CoS RTP video: 6
802.1p CoS RTP text: 5
Jitterbuffer enabled: No

Network Settings:

SIP address remapping: Enabled using externaddr
Externhost:
Externaddr: x.88.153.103:0
Externrefresh: 10
Localnet: 10.123.245.0/255.255.255.0
8.49.149.136/255.255.255.248
10.123.244.0/255.255.255.0
10.119.0.0/255.255.0.0

Global Signalling Settings:

Codecs: (ulaw)
Relax DTMF: Yes
RFC2833 Compensation: No
Symmetric RTP: Yes
Compact SIP headers: No
RTP Keepalive: 0 (Disabled)
RTP Timeout: 0 (Disabled)
RTP Hold Timeout: 0 (Disabled)
MWI NOTIFY mime type: application/simple-message-summary
DNS SRV lookup: No
Pedantic SIP support: Yes
Reg. min duration 60 secs
Reg. max duration: 3600 secs
Reg. default duration: 120 secs
Sub. min duration 60 secs
Sub. max duration: 3600 secs
Outbound reg. timeout: 20 secs
Outbound reg. attempts: 0
Outbound reg. retry 403:No
Notify ringing state: Yes
Include CID: No
Notify hold state: No
SIP Transfer mode: open
Max Call Bitrate: 384 kbps
Auto-Framing: Yes
Outb. proxy:
Session Timers: Accept
Session Refresher: uas
Session Expires: 1800 secs
Session Min-SE: 90 secs
Timer T1: 500
Timer T1 minimum: 100
Timer B: 32000
No premature media: Yes
Max forwards: 70

Default Settings:

Allowed transports: UDP
Outbound transport: UDP
Context: public
Record on feature: automon
Record off feature: automon
Force rport: Yes
DTMF: rfc2833
Qualify: 0
Keepalive: 0
Use ClientCode: No
Progress inband: No
Language:
Tone zone:
MOH Interpret: default
MOH Suggest:
Voice Mail Extension: asterisk
RTCP Multiplexing: No

server2 is running pjsip

Global Settings:

ParameterName : ParameterValue

contact_expiration_check_interval : 30
debug : no
default_from_user : asterisk
default_outbound_endpoint : default_outbound_endpoint
default_realm : asterisk
default_voicemail_extension :
disable_multi_domain : false
endpoint_identifier_order : ip,username,anonymous,header,auth_username
ignore_uri_user_options : false
keep_alive_interval : 90
max_forwards : 70
max_initial_qualify_time : 0
mwi_disable_initial_unsolicited : false
mwi_tps_queue_high : 500
mwi_tps_queue_low : -1
norefersub : yes
regcontext :
send_contact_status_on_update_registration : no
taskprocessor_overload_trigger : global
unidentified_request_count : 5
unidentified_request_period : 5
unidentified_request_prune_interval : 30
use_callerid_contact : no
user_agent : FPBX-15.0.16.75(16.12.0)

System Settings:

ParameterName : ParameterValue

accept_multiple_sdp_answers : false
compact_headers : false
disable_rport : false
disable_tcp_switch : true
follow_early_media_fork : true
threadpool_auto_increment : 5
threadpool_idle_timeout : 60
threadpool_initial_size : 0
threadpool_max_size : 50
timer_b : 32000
timer_t1 : 500

Local networks include the desktop network where I’m in, as well as the sbc network 10.123.245.0.

I’m really at a loss as to why. I would think its got to be some nat thing but I havent’ found it.

2

I assume this means that it used to work but doesn’t anymore. Are you aware of any change that may have caused this (module update, system update, trunk settings change, etc.)?

Are all incoming calls affected? If not, approximately what percentage? Any obvious pattern e.g. only when heavily loaded?

Do calls between extensions on server2 work reliably?

Is a VPN client running on the desk phone connecting to a VPN server running on the FreePBX system? If not, please describe the network path between phone and PBX.

Please describe this in more detail. In particular, the L3 media server addresses are almost certainly different from 8.49.149.136. What is the path for media to/from the SBC?

When the call has no audio to the caller, does the capture on FreePBX, show RTP coming in? Going out? On the SBC, is RTP coming in? Going out to the correct address and port? If the flow looks ok, check whether the packets are correct codec, correct packetization and actually contain sound.

Once we know what step is failing, it shouldn’t be hard to find out why.

3

So its a new service. I had some issues and then it went away so thought maybe all was good till today.

So I believe so. Many calls work from anoher carrier that is Natted. through the same sbc.

VPN client is on the network layer. Iin AWS they have there stuff, we are Fortigate units.

The network for Level 3 is the 8.49.149.136/28 And you are right media is from a ip in tha subnet as well as the voice services.

In the sniffer trace I see audio and its a flat line till the call is put on hold and then off hold.

And now I don’t have the same issue today. Hard to find when its not broken.

4

We’ve seen cases over the past year where putting someone on hold and then coming off hold as cleared a one-way audio problem. It points to a firewall routing problem in your NAT setup. The incoming call doesn’t establish a good outbound path to the original caller, but putting them on hold stops and restarts the stream, which then wires up an outbound path through your RTP block on the firewall.

5

In this case, maybe not.

If you still have those .pcap files, take another look. On simple calls (no transcoding, jitter buffer or conference bridge), for each RTP packet that comes in, Asterisk immediately sends one out with the same payload. If nothing is coming in, nothing gets sent out, except perhaps for once per second keep-alive packets.

Assuming ulaw here, real world silence has at least two LSBs of noise, i.e. if the payload is all 0xff, that’s fake RTP. Silence has random 0xfe, 0x7f, etc.

So, if server2 had RTP coming in for the call (either fake or silent), that’s what the phone was sending. And if the user was talking, then either the phone was malfunctioning or there was a signaling problem that caused the phone to come up muted when answered.

At face value, that seems inconsistent with your other observations, but you could compare the INVITEs sent to the phone in the two cases.

Another thought: look at the signaling to/from the phone and see whether it was auto-answered. Many phones (for privacy) will auto-mute on auto-answer (and the mute will of course be released if the call is put on hold and taken off). If you still have trouble, let us know the make and model of the device(s) used.

6

image
image1695×490 20.9 KB

About 9 seconds should be the hold and off hold time.

7

The only client has been Zoipoer 5 pro version.

I havent’ been in the office due to covid to validate with a desphone.

I haven’t had the failure in testing with Openwengo for the last day or two. Like its a Zoiper issue but that doesn’t make sense to me. The calls above was with zoiper.

8

g729??? Why? If nothing in the path has very limited bandwidth, you should have ulaw as the first priority codec. (If L3 can pass calls from VoLTE mobiles in wideband, you will probably want to have HD when available, but ignore that for now.) If there is a bandwidth limitation, Opus will sound much better (provided that you have enough horsepower on server2 to transcode).

At least for testing, switching to ulaw will show whether the codec is an issue (either transcoding by Asterisk or handling it at L3). Also, it’s much easier to debug – just looking at the packets you can see when sound is present. However, recent Wireshark can natively decode and play g729.

1 Like
9

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.