Hi all, I have a user who is reporting one-way audio, but only when a call is made to or from particular PSTN (cell) numbers. Their phones are behind a NAT router and my server is on the open Internet. Calls within their office sound fine. Calls to/from most numbers sound fine. When they took their phones home, those same phone numbers still had problems. So, I don't think it's their network. I've taken pcaps of both legs of example calls. On the provider-side, I see 2-way audio. On the client-side, I only hear one side. Most of the time, though, their phones work correctly. Any ideas where to look to fix this? Thanks in advance. -- Mike Diehl -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20190319/c7854467/attachment.html>
On Tuesday 19 March 2019 at 21:36:53, Mike Diehl wrote:> Hi all, > > I have a user who is reporting one-way audio, but only when a call is made > to or from particular PSTN (cell) numbers.I'm assuming you're using a PSTN trunking provider to connect to those numbers (ie: you don't have your own on-site gateway device). Do you use only a single trunking provider, through which some calls show this problem, but most don't, or do you use several trunking providers, and the call numbers showing this problem always go via the same one?> Their phones are behind a NAT router and my server is on the open Internet. > > Calls within their office sound fine. Calls to/from most numbers sound > fine.I think that basically rules out the common NAT reasons for one-way audio.> When they took their phones home,...almost certainly also behind NAT...> those same phone numbers still had problems.But presumably other numbers didn't? (Important to check!)> So, I don't think it's their network.From what you've said, I think you're right.> I've taken pcaps of both legs of example calls. On the provider-side, I see > 2-way audio. On the client-side, I only hear one side.Please explain that in a bit more detail. You have an Asterisk server on the Internet, presumably with one IP address (or maybe two, but one IP4 and one IP6). Where are you capturing "the provider side" and "the client side"? Can you show us the tshark / tcpdump / whatever commands you are actually using to perform these captures, and make clear which machine/s you're running those commands on?> Most of the time, though, their phones work correctly. > > Any ideas where to look to fix this?Only two things spring to mind so far: 1. Transcoding? 2. IPv4 on one side and IPv6 on the other (although I'm hard pushed to see how this could create one-way audio rather than no audio)? I think the key thing I would look for in the pcaps is for any re-invites - is one side telling the other "oh, you can get my audio from here" and that's not an accessible address? However, why this would be specific to particular _numbers_ rather than particular SIP connections puzzles me too. Antony. -- Please apologise my errors, since I have a very small device. Please reply to the list; please *don't* CC me.
My comments below: On Wednesday, March 20, 2019 12:19:08 AM Antony Stone wrote:> On Tuesday 19 March 2019 at 21:36:53, Mike Diehl wrote: > > Hi all, > > > > I have a user who is reporting one-way audio, but only when a call is made > > to or from particular PSTN (cell) numbers. > > I'm assuming you're using a PSTN trunking provider to connect to those > numbers (ie: you don't have your own on-site gateway device). > > Do you use only a single trunking provider, through which some calls show > this problem, but most don't, or do you use several trunking providers, and > the call numbers showing this problem always go via the same one?I only have the one inbound provider, and all numbers go through that provider.> > Their phones are behind a NAT router and my server is on the open > > Internet. > > > > Calls within their office sound fine. Calls to/from most numbers sound > > fine. > > I think that basically rules out the common NAT reasons for one-way audio. > > > When they took their phones home, > > ...almost certainly also behind NAT... > > > those same phone numbers still had problems. > > But presumably other numbers didn't? (Important to check!) > > > So, I don't think it's their network. > > From what you've said, I think you're right. > > > I've taken pcaps of both legs of example calls. On the provider-side, I > > see 2-way audio. On the client-side, I only hear one side. > > Please explain that in a bit more detail.I use voipmonitor to create sniffer traces of calls on my server. I get 2 pcap files for each call: 1. Traffic from the phone to my server. 2. Traffic from my server to the trunk provider. In the cases I'm concerned about, one of these legs (only) will exhibit the one-way audio.> You have an Asterisk server on the Internet, presumably with one IP address > (or maybe two, but one IP4 and one IP6). > > Where are you capturing "the provider side" and "the client side"? > > Can you show us the tshark / tcpdump / whatever commands you are actually > using to perform these captures, and make clear which machine/s you're > running those commands on? > > > Most of the time, though, their phones work correctly. > > > > Any ideas where to look to fix this? > > Only two things spring to mind so far: > > 1. Transcoding?There is no transcoding. I ONLY allow ulaw for voice.> 2. IPv4 on one side and IPv6 on the other (although I'm hard pushed to see > how this could create one-way audio rather than no audio)?My server doesn't have IPv6 configured at all.> I think the key thing I would look for in the pcaps is for any re-invites - > is one side telling the other "oh, you can get my audio from here" and > that's not an accessible address?I will take a more thorough look at the pcaps.> However, why this would be specific to particular _numbers_ rather than > particular SIP connections puzzles me too. > > > Antony.Thank you for your time, and for validating/confirming my conclusions. Any other ideas would be most welcome! -- Mike Diehl -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20190320/854ea790/attachment.html>
Reasonably Related Threads
- Asterisk - can't hear other side. Or other side does not hear us
- Asterisk - can't hear other side. Or other side does not hear us
- unable to dissect libvirt rpc packets using wireshark plugin
- Re: unable to dissect libvirt rpc packets using wireshark plugin
- Upgraded server crashes on voicemail storage