Some Inbound calls no audio - PCAP Shows RTP Transmission

FreePBX Endpoints
1

Ok, so update:

I found a cell phone to use that when calling in, would never deliver audio to the PBX. I took the test number (#A) that I was calling into and redirected to my 3CX office phone. He called it again, my 3CX office phone rang, but it still did not work!

I then took a DID (#B) that I created new and gave it an inbound route to my PBX. Called it from the same cell phone that NEVER worked, and now it works. I can repeat this over and over again.

To Recap:

When the test phone calls #A hosted by Free PBX it does not work.
When the test phone calls #A hosted by 3CX it does not work

When the test phone calls #B hosted by 3CX it does work.
When the test phone calls #B hosted by FreePBX it does work.

All same trunks, ring groups, routes, codec, you name it, all the same.

Does anyone know how this is possible?

Original:

I’ve been working on this for a week. Here’s where I am at:

I am now hosting FreePBX on an Azure VM with all inbound UDP 4k-65000 allowed, and similar outbound. It does a 1:1 NAT from public to private IP (i’m pretty sure).

I take that cloud hosted FreePBX and though an IAX2 trunk, I send the calls to the on prem FreePBX. This PBX connects with the extension.

When it works, it works great. However I have the following problems with INBOUND calls only. The problem is the same on Flowroute and on SIPStation (I currently have both live for testing).

      • Some calls have one-way audio, where the end user picks up the call and says “Hello” until they give up.
      • Some calls start with a delay where the end user picks up, says hello, and the two parties say hellow for a while until the delay gets better.
      • Some calls are great.

I was able to get a packet capture today, from the sys ad pro module. The stream being sent from the PBX to the PSTN plays back perfectly. The stream from the PSTN to the PBX is exactly as the end user hears it, silent. I can see the RTP flowing both ways, but they are filled with silence, or they are not the right packets or something.

I am focusing on the SIPStation trunk because FreePBX auto configured it using the SIPStation module, so I’m guessing it’s gotta be (probably, maybe) right.

Also something I noticed, and this is a small sample size, whenever the call-in user has tmobile it’s worse. I can’t correlate enough data to be sure of that though.

Keep in mind, SOME calls are great. I can’t figure it out. Help me before it’s too late, I’m on borrowed time!!

UPDATE: It’s highy correlative to certain inbound callers. Certain inbound callers can NEVER get through. Certain other inbound callers seemingly never have a problem.

Here is a sample call log. One Way Audio - FreePBX Pastebin

goodandbadcalls
goodandbadcalls1065×569 41.2 KB

2

You only seem to have the outbound leg signalling. My guess is that the inbound leg is still in early media, because the OK hasn’t arrived at the ITSP. The delay could reflect the number of retransmissions required before it arrives.

3

Thanks for the response. How can I analyze your theory about the inbound leg stuck in early media? Is there an additional sip signal that should be present? If so, what new settings should I test?

4

There should be an inbound INVITE, with a 200 OK response, and an inbound ACK, or equivalents under some other protocol. Lack of the ACK would be suggestive, but you would need logs from the other side to confirm.

Your logs show none of these, although something must have been received, to start the call.

If they re all there, I would say the problem is with the service provider.

5

This is an addition to the lines #1, and lines #4 of the flow diagram? These are what I would think are inbound INVITE and ACK, but maybe I’m wrong?

I get the same results on Flowroute and on SIPStation, so I’m not thinking it’s the service provider. Also, this is my second PBX (the local onprem used to go directly to Sip Trunk). I had same problem on both. It’s gotta be a setting somewhere.

6

You haven’t explained what the different addresses represent, but the signalling is going between two private addresses, so I assume that the 192 is asterisk and the 10 address is your local phone, and the 226 one is the provider.

There is certainly only signalling for one leg shown here.

7

Yeah, the 192 is confusing, but it’s a public IP, it got me at first.

192.159.66.3 → This is SIPStation
10.1.0.4 → FreePBX
206.144.16.41 → Media Provider (PSTN)

This packet capture shows the to and from directly from the media provider. I started troubleshooting the phones at first only to realize that when I packet captured the external interface I couldn’t even get audio there (sometimes, again, some calls are good).

8

I think the best shot will be to have a pcap for a good and for a bad call and compare them. Also the pcap file would be helpful, not the screenshot.

9

I have actually done this and gone line by line on each SIP transaction and each packet seems identical except for caller id and user information.

I’d love to post the PCAP, but obviously there’s personal information on it. Happy to send via DM if you’re interested.

I’m capturing all day today, but Saturdays are slow. I have an example of a good call, waiting for bad call.

10

Generally people prefer protocol traces taken from /var/log/asterisk/full, with the appropriate channel driver debugging enabled. These are text files, that can be edited to redact information (although one has to be careful not to destroy important distinctions in the process) and can be uploaded to pastebin.freepbx.org.

11

@david55 Thank you, I try to learn how to do that so I can provide better information.

Does this make any sense, it may be a breakthrough?

Most of the failed calls are inside sales reps and other inside org persons. I’m realizing that those are the calls that fail almost 100%, maybe even 100%. When you call them (outbound) it always works.

This correlation must been something, it’s way, way strong.

I think they may be company provided phones too, not sure, I will find out. Also, one of them says when she receives texts it goes so a “strange email.” I’m sure that means something about her phone.

12

@david55 @spioli Is this detailed enough, or do I need more debuggers on?

https://pastebin.freepbx.org/view/b13b3b5a

13

Ok, so update:

I found a cell phone to use that when calling in, would never deliver audio to the PBX. I took the test number (#A) that I was calling into and redirected to my 3CX office phone. He called it again, my 3CX office phone rang, but it still did not work!

I then took a DID (#B) that I created new and gave it an inbound route to my PBX. Called it from the same cell phone that NEVER worked, and now it works. I can repeat this over and over again.

To Recap:

When the test phone calls #A hosted by Free PBX it does not work.
When the test phone calls #A hosted by 3CX it does not work

When the test phone calls #B hosted by 3CX it does work.
When the test phone calls #B hosted by FreePBX it does work.

All same trunks, routes, codec, you name it, all the same.

Does anyone know how this is possible?

14

You didn’t do CLI: “pjsip set logger on”.

15

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