No audio between some extensions (strange)


(Jameel) #1

Hi, we are facing very strange issue, i am new to freepabx so i am not sure where to start looking for trouble? The version we are using is FreePBX 14.0.1alpha34.

everything was normal for years and then since last week i have started receive complains for no audio. here is the detail user told me.

when user A calls user B both hear no audio. When the same user A calls user C audio is working fine. and when user C calls user A and user B audio is working fine.

where should i look for trouble? this is really strange for me.


(Itzik) #2

Can you try updating your PBX and rebooting?


(Alex) #3

please does anybody know how to fix the issue, I am having the same issue No audio when placing call on public Ip , no audio externally , within my network the audio work fine


#4

Hi Jameel, are all the phones on the same network? If not, do you only experience issues where a phone on a remote network is involved? Also, it’s helpful to know if there were any recent network changes on any of the networks involved, including the phone’s if it’s remote. What make/model of phone is being used, and are they configured with Endpoint Manager module? You may want to start troubleshooting my looking at the asterisk CLI, and comparing the output of a good call vs a bad call. If nothing obvious sticks out, the next step is most likely to look at packet traces to see what’s different.

Alex, it’s hard to say if your issue is the same without knowing more. Have things ever worked for audio to external devices? Are the RTP ports defined in Asterisk SIP Settings being forwarded, and is the External Address correct?


(Jameel) #5

Hi wmoon, thanks for help.

All the phones and pbx server are in internal network, single ip scheme. Phone involved are Grandstream 1628, 2140 and not configured with Endpoint manager.

Do i have to debug that affected call? How to effectively look at CLI for this issue?


#6

Jameel, would you say there’s consistency with this issue? In your example, you said:
When userA calls userB and neither hears audio. If userC calls userA or userB, audio works fine both ways.
Do you always get those results when trying the same call again? How about after rebooting the phones and then trying the call? Do you ever have audio issues when the phones call system extensions like the directory or voicemail?

Another thing you might want to try is having userB and userC swap phones(registration configuration), and see if the problem follows, or if you see the exact same behavior.

Another thing is to check each of the Extension’s settings on FreePBX(Applications->Extensions). Look for any settings that are unexpectedly different between the extensions. Especially check to see if they are not all using SIP vs PJSIP. It’s ok to have differing options and protocols, but it could lead to clues toward the actual problem. It’s possible there’s nothing here since you said things were working fine before, but it’s still something to look at.

If you’re unfamiliar with the CLI output for a call, you’ll see a lot of stuff flying by. However, it’s still worth comparing the output from a good vs bad call to see if any obvious differences, or messages stick out. You can try showing us the output of a bad call here to see if we can spot anything. It could also be a codec related issue, but it’s hard to say since there were no recent changes. Eventually, doing some packet traces might be in order to view the flow of RTP(voice traffic).

Itzik makes a good point about mentioning an update, since you’re on an alpha build of an older version. Since things were working not long ago, maybe try the extra troubleshooting for now, but at least updating to the latest version of 14 could be a good idea at some point.


(Alex) #7

the RTP is well define in asterisk and i check the external IP address it configure well , i dont just know where to go to rectify the issue, i try pjsip and chansip the problem is still the same

i am using gswave on both phone to make call no audio is there any other thing i can check


#8

Hi Alex,

Are the RTP ports being forwarded correctly on your firewall? Or, can you try calls where both extensions are on the same local network as the pbx, to see if you still have problems? Also, if gswave are softphones, are you sure the audio settings are set up properly?

I suggest making a new, separate post to continue discussion for your issue. The troubleshooting may be similar to Jameel’s issue, but things may start to differ, and you might be able to get better help that way. Make sure you mention the gswave softphones you’re using in case others are more familiar with those.


(Jameel) #9

hi wmoon, no i wouldn’t say there is consistency with this issue as those same users won’t complain for days now and it always auto resolves.

i would like to thank you so much for the trouble shooting approach you have given. i am really surprised why didn’t i went with all these basic logical trouble shooting on my own as i am a technical network guy. (this is because i am afraid of this voice thing and i have no knowledge about it. it was setup by someone else and now that they have left, i have no idea)

well, i would look into these steps and would try to find out the real problem. here is what i would do.

1. i would check all the ABC extensions and see if there is any configuration related difference.
2. i would swap the extensions, or the phone sets to see if the problem follows.
3. i would try to to take call traces for good and bad call and compare it.
4. i would do packet traces to view RTP flow. (i dont know how it is done, do i have to do it in freepbx server or at network level?
5. and finally i would go for an update.

i will update here the results here.


#10

That sounds like a good plan Jameel. Usually, I don’t see these types of audio issues for systems where all the phones and the pbx are on the same subnet with no NAT between them, especially when it’s not consistent, and assuming there are no IP collisions going on. As for the packet tracing, there are different ways to go about it. I think many like to use tcpdump, but for a simple check of the rtp flow, before digging deeper, I like to use tshark just because I’m used to it.

From the PBX command line, I’d do the following:
[root@freepbx]# tshark host 10.12.21.65

In this example, my phone is at 10.12.21.65, and my PBX is at 10.12.4.11. While tshark is running, I will place a call from my test phone. The output that flies by will look something like:

1 0.000000000 10.12.21.65 -> 10.12.4.11 SIP/SDP 1111 Request: INVITE sip:103@10.12.4.11 |
2 0.018268165 10.12.4.11 -> 10.12.21.65 SIP 592 Status: 401 Unauthorized |
3 0.055583814 10.12.21.65 -> 10.12.4.11 SIP 407 Request: ACK sip:103@10.12.4.11 |
4 0.068091626 10.12.21.65 -> 10.12.4.11 SIP/SDP 1399 Request: INVITE sip:103@10.12.4.11 |
5 0.104914332 10.12.4.11 -> 10.12.21.65 SIP 394 Status: 100 Trying |
6 1.090579212 10.12.4.11 -> 10.12.21.65 SIP 659 Status: 180 Ringing |
7 1.115429589 10.12.4.11 -> 10.12.21.65 SIP/XML 1218 Request: NOTIFY sip:101@10.12.21.65:5060;ob |
8 1.147347429 10.12.4.11 -> 10.12.21.65 SIP 659 Status: 180 Ringing |
9 1.157864282 10.12.21.65 -> 10.12.4.11 SIP 590 Status: 200 OK |
10 1.975603976 10.12.21.65 -> 10.12.4.11 SIP 566 Request: REGISTER sip:10.12.4.11:5060 |
11 1.977003543 10.12.4.11 -> 10.12.21.65 SIP 600 Status: 401 Unauthorized (0 bindings) |
12 1.980277889 10.12.21.65 -> 10.12.4.11 SIP 855 Request: REGISTER sip:10.12.4.11:5060 |
13 1.984652942 10.12.4.11 -> 10.12.21.65 SIP 546 Status: 200 OK (1 bindings) |
14 2.004116904 10.12.4.11 -> 10.12.21.65 SIP 672 Request: NOTIFY sip:101@10.12.21.65:5060;ob |
15 2.018600766 10.12.21.65 -> 10.12.4.11 SIP 414 Status: 200 OK |
16 2.701966854 10.12.4.11 -> 10.12.21.65 SIP/SDP 1096 Status: 200 OK |
17 2.846513984 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18456, Time=1976200720
18 2.861299491 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18457, Time=1976200880
19 2.870240161 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62174, Time=2068152745
20 2.875086836 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18458, Time=1976201040
21 2.889239405 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62175, Time=2068152905
22 2.894463921 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18459, Time=1976201200
23 2.909481741 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62176, Time=2068153065
24 2.918681238 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18460, Time=1976201360
25 2.929525192 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62177, Time=2068153225
26 2.945471823 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18461, Time=1976201520
27 2.949280087 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62178, Time=2068153385
28 2.956528507 10.12.4.11 -> 10.12.21.65 RTP 214 PT=ITU-T G.722, SSRC=0x64CADBD9, Seq=18462, Time=1976201680
…a lot more of this…
200 4.669428890 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62264, Time=2068167145
201 4.689204523 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62265, Time=2068167305
202 4.709188690 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62266, Time=2068167465
203 4.729021260 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62267, Time=2068167625
204 4.748711515 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62268, Time=2068167785
205 4.768801404 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62269, Time=2068167945
206 4.788601085 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62270, Time=2068168105
207 4.808806558 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62271, Time=2068168265
208 4.828580204 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62272, Time=2068168425
209 4.848547744 10.12.21.65 -> 10.12.4.11 RTP 214 PT=ITU-T G.722, SSRC=0xC06C8722, Seq=62273, Time=2068168585
210 4.866766218 10.12.4.11 -> 10.12.21.65 SIP 476 Request: BYE sip:101@10.12.21.65:5060;ob |

In this example, I can see RTP packets going back and forth between the PBX and phone. In some cases with audio issues, you’d just see the flow going in one direction which can lead to clues as for what to look at next.


#12

My personal experience has been that audio issues are almost always related to firewall and/or NAT.

You’ve said that all of these phones are “internal,” by which I assume that you mean that the phones are on the same subnet and the same physical network. I also assume that your PBX is also internal, i.e., running on a local computer and not in the cloud.

If that’s true, the first place that I would look at is your PBX’s SIP settings to ensure that your external and internal networks are designated correctly. That’s an item that should be in any basic FreePBX getting started guide.

The second place that I would look at is your PBX’s firewall. I don’t use responsive firewall because I’ve never been able to find adequate documentation on what it actually does and does not do, and so if that’s what you’re using, I cannot help. But, you might try turning it off during troubleshooting to see if it makes a difference.

If you’ve configured Iptables yourself, I’d re-evaluate those settings.


(system) closed #13

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