One way Audio

1. Brekeke Product Name and Version:3.9.5.8

2. Java version:1.8

3. OS type and the version:RHEL7

4. UA (phone), gateway or other hardware/software involved:

5. Your problem: One way audio.

We are experiencing One way audio on both inbound/outbound calls.

I have done the following trouble-shoting and found that BSS is not setting up RTP stream from BSS to PBX.

I have taken the wireshark trace on the BSS including the RTP. BSS does not start the RTP stream from BSS to PBX.
There are 2 (RX/TX) RTP streams between BSS and provider. I am able to hear the audio coming into from provider's side for inbound calls. But BSS does not pass the audio to PBX.
But there only one RTP stream (RX) from PBX to BSS. There is no RTP stream from BSS to PBX.



BSS has 2 network interfaces.
ETH1:This network interface has public IP. This network interface is used towards the provider side. We can send the outbound calls to provider. We can also receive the DID inbound calls from provider.
ETH2:This network interface has private IP. This network inteface is used towards our local PBX. PBX sends/receive calls from BSS.
Local interface of BSS and PBX are on the same subnet, connected to same ethernet switch. There is no firewall between BSS and PBX. Both are able to ping each other.

(Provider)1.1.1.1<------>2.2.2.2(BSS)10.10.10.10<-------->(PBX)10.10.10.11

Dial plan From Provider to PBX

Matching Patterns
$request = ^INVITE
$addr = ^1.1.1.1$
To = sip:(.+)@
From = sip:(.+)@

Deploy Patterns
To = sip:%1@10.10.10.11
From = sip:%2@10.10.10.10
$b2bua = true
$rtp = true
$ifsrc = 2.2.2.2
&net.rtp.ifsrc = 2.2.2.2
&net.rtp.bindsrc = 2.2.2.2
$ifdst = 10.10.10.10
&net.rtp.ifdst = 10.10.10.10
&net.rtp.binddst = 10.10.10.10

Dial Plan From PBX to Provider
Matching Patterns
$request = ^INVITE
$addr = ^10.10.10.11$
To = sip:(.+)@
From = sip:(.+)@

Deploy Patterns
To = sip:%1@%1.1.1.1
From = sip:%2@2.2.2.2
$b2bua = true
$rtp = true
$ifsrc = 10.10.10.10
&net.rtp.ifsrc = 10.10.10.10
&net.rtp.bindsrc = 10.10.10.10
$ifdst = 2.2.2.2
&net.rtp.ifdst = 2.2.2.2
&net.rtp.binddst = 2.2.2.2

are you sure interface IP addresses defined in DialPlan are correct?

Harold,

I have double checked the IP's they are correct.
the IP's I have shared are an example not the actual IP's.

Go to the Session Details page from Active Session page during a call is active.
There are two "packet-count" fields for each direction.
so find the "packet-count" field which indicates the provider to PBX via BSS.

If it is 0, the SIP Server didn't receive RTP packets sent from the provider.
It is it not 0, the SIP Server didn't send RTP packets to the PBX.


> This network interface has private IP.

Is it a private IP address defined by RFC?
Do you have any value at [External IP address pattern] or [Internal IP address pattern] in the settings?

Yes, the interface having private ip address is on subnet 192.168.X.X.
There is no IP address pattern defined for both External and Internal under configuration.



Following is the detail of active session: I have changed the actual IP's and phone numbers rest everything is original. It shows that packets are coming in from provider but not going towards PBX.


From-URI sip:18005551212@provider.com
From-UA Callcontrol
From-IP 1.1.1.1:5060 (UDP)
From-Interface 2.2.2.2
To-URI sip:18005552323@10.10.10.11
To-UA Excel_CSP/84.11.35
To-IP 10.10.10.11(UDP)
To-Interface 10.10.10.10
Call-ID 4UGMCEPBI56H5COTH0GTEMN74C@1.1.1.1
B2B-Mode on
DialPlan-Rules DID_INBOUND
Port-Listen 5060
Session-PlugIn session
Session-Status Talking
Plugin-Status max=0
Session-Timeout[sec] 259182
Time-Inviting Wed May 27 11:31:59.048 EDT 2020
Time-Talking Wed May 27 11:31:59.310 EDT 2020
Length-Talking 00:00:17.114
ST-Refresher No Session-Timer
Time-Latest-Packet Wed May 27 11:31:59.313 EDT 2020
SIP-Packets-Total 6
rtp-relay on
rtp-srcdst
media audio
transport RTP/AVP
payload -
status active
listen-port 20002
send-port 20000
target 10.10.10.11:15236
packet-count 0
packet/sec 0
buffer size 260
rtpex plug-in RTPexJNI
rtp-dstsrc
media audio
transport RTP/AVP
payload 0 (PCMU/8000)
status active
listen-port 20000
send-port 20002
target 1.1.1.1:10122
packet-count 856
packet/sec 50
buffer size 260
rtpex plug-in RTPexJNI

Was it a call made from the provider?

See the first "packet-count" field which indicates 0.
It means the SIP Server didn't receive RTP packets from the provider.
It is the reason of the one-way audio issue.

Let you check that the RTP interface address and UDP ports are not blocked by any firewalls. Even if a firewall allows ping, make sure it allows UDP.

Yes, its a DID call coming in from provider's side.

First packet count it on the private interface going towards PBX and it shows packet count 0.

Second packet count is on the public interface coming in from provider's side and it shows the packet count 856.

I am runing wireshark on both the interfaces on BSS. My wireshark trace shows that packets are coming in from provider's side but packets are not going out out the private interface towards PBX.

There is no firewall between BSS and PBX. Both are connected to the same Ethernet switch and are on the same subnet.

The issue is around the interface faces to the provider.

Are you sure that RTP packets are sent to the correct UDP port from the provider?
It must be the same port number what SDP announced.

Yes, I have already verified that that provider is sending the RTP on the same port mentioned in the SDP.

Do you have the one-way audio issue with other calls too?

We have replaced BSS and moved both the IP's from BSS to another SIP proxy and audio issue is not observed.

We put BSS back and again audio issue is observed. I am not sure what am I missing in BSS config.

Can you paste the SDP what BSS sent to the provider?

Sorry for the delayed response:


SDP From Provider-->BSS
SDP From BSS-->Proivder
SDP From BSS-->PBX

Even if you make a test call within the local subnet, does the one-way audio issue happen?

It was a network configuration issue. We reconfigured the network on the server and it resolved the issue.

I appreciate your time.

Thanks, I have the same problem in our company.