SOLVED No audio in inbound calls

[AndreyRubtsov]

Hello, i have a problem. All outbound calls work well, but inbound calls doesn't. My provider use RTP ports 10000-65535, where i can modify this port range in Fusion?
Also, my Fusion is behind the NAT. Should i set external_rtp_ip or external_sip_ip to autonat?

 

[Adrian Fretwell]

Don't worry about the RTP port your provider uses. These are just the port numbers that the supplier will send RTP from. Fusion (FreeSwitch) will tell your provider what port to send RTP to in the SDP body of an INVITE or 200 OK message.

If your Fusion is behind NAT, AND your SIP provider is good at detecting that you are behind NAT, you may get away with the default configuration, your SIP provider will be correcting the errors caused by NAT in your Contact headers and SDP bodies.

If you have a static public IP address you should put that IP in both external_rtp_ip and external_sip_ip.

I'm sure someone will correct me if I'm wrong, but I think autonat is only used when you need the SIP profile to talk to devices both outside your local LAN and inside it. Most people do not, which I why we have both internal and external SIP profiles.

 

[AndreyRubtsov]

Thank you for your reply. I've just set these vars to my static public IP, but still no audio for inbound calls from external callers. What else can it be?

 

[Adrian Fretwell]

Have you restarted the SIP profile? Or restart the whole machine to be sure, if it's not doing anything else.

The best way to diagnose this is to look at a packet capture, sometimes referred to as a pcap trace. If you don't know how to do this, let me know, I will explain.

It helps greatly to have an understanding of the SIP protocol when trying to diagnose issues like this.

 

[AndreyRubtsov]

Do you mean tools like siptrace in fs_cli or wireshark? I restarted machine, but nothing has changed.

 

[Adrian Fretwell]

Yes, Wireshark is a very useful tool. I tend to use tcpdump to do the capture then use Wireshark or sngrep to look at the results. If I just want a quick and easy look at a few packets I use ngrep. sngrep will also capture but it has memory leaks and I find it will often segfault at just a few calls per second.

Here are some examples using tcpdump and ngrep:
Log everything on port 5060 to a file called capture.pcap

tcpdump -i any -w capture.pcap port 5060

Log everything from ip address 1.2.3.4 on interface eth0 to a file called capture.pcap

tcpdump -i eth0 -w capture.pcap host 1.2.3.4

Show on screen packets on port 5060

ngrep -W byline -td any . port 5060

If you are using the Internal and External profiles on their default ports you can log 5080 to see what it happening between Fusion and your supplier and log 5060 to see what is happening between Fusion and your phones. Of course you can log both 5060 and 5080 at the same time.

tcpdump -i any -w capture.pcap port 5060 or port 5080

When diagnosing problems with audio you need to look at the SDP body part where it exists in the SIP message, typically in an INVITE and the 200 OK - You may see SDP bodies in other messages like a 183 session progress.

Here is a typical INVITE message with an SDP body:

U 2019/11/18 15:06:10.652575 22.23.24.25:1024 -> 144.145.146.147:5060
INVITE sip:*9664@af-sandpit-1.mydomain.uk:5060 SIP/2.0.
Via: SIP/2.0/UDP 22.23.24.25:1024;branch=z9hG4bK2869618489;rport.
From: "201" <sip:201@af-sandpit-1.mydomain.uk:5060>;tag=2707493168.
To: <sip:*9664@af-sandpit-1.mydomain.uk:5060>.
Call-ID: 0_3506530060@192.168.6.43.
CSeq: 1 INVITE.
Contact: <sip:201@22.23.24.25:1024>.
Content-Type: application/sdp.
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE.
Max-Forwards: 70.
User-Agent: Yealink SIP-T46S 66.84.0.15.
Supported: 100rel.
Supported: from-change.
Supported: timer.
Session-Expires: 1800;refresher=uac.
Min-SE: 90.
Allow-Events: talk,hold,conference,refer,check-sync.
Supported: replaces.
Content-Length: 255.
.
v=0.
o=- 20154 20154 IN IP4 22.23.24.25.
s=SDP data.
c=IN IP4 22.23.24.25.
t=0 0.
m=audio 12690 RTP/AVP 9 8 101.
a=rtpmap:9 G722/8000.
a=rtpmap:8 PCMA/8000.
a=ptime:20.
a=sendrecv.
a=rtcp:12691.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

This is my desk phone, ext 201, calling music on hold *9664.
The first line shows the source and destination for the packet; my desk phone is on IP 22.23.24.25 and my FusionPBX is on IP 144.145.146.147.

The SDP body is below the dot following the Content-Length header. The c=IN IP4 22.23.24.25. is instructing the PBX to send its audio to IP address 22.23.24.25, and the m=audio 12690 is specifying the port. The SDP in the 200 OK from the PBX will instruct the desk phone where to send it's audio. If all the IP addresses and ports are correct we should have two way speech.

With this information it is relatively easy to see if the audio is being sent to the wrong place.

I hope that helps a little.

 

[EasyBB]

Did you test with SIP ALG disabled on your router?

I use sngrep on Fusion box; it provides better graphical representation and easy navigation.

To analyse an incoming call, run

sngrep port 5080

on the Fusionbox, assuming you are running external profile on 5080.

 

[AndreyRubtsov]

I run "sngrep port 5060" from my fusion and from router. Results in attachments. Any ideas?

 

[AndreyRubtsov]

Yes, Wireshark is a very useful tool. I tend to use tcpdump to do the capture then use Wireshark or sngrep to look at the results. If I just want a quick and easy look at a few packets I use ngrep. sngrep will also capture but it has memory leaks and I find it will often segfault at just a few calls per second.

Here are some examples using tcpdump and ngrep:
Log everything on port 5060 to a file called capture.pcap

tcpdump -i any -w capture.pcap port 5060

Log everything from ip address 1.2.3.4 on interface eth0 to a file called capture.pcap

tcpdump -i eth0 -w capture.pcap host 1.2.3.4

Show on screen packets on port 5060

ngrep -W byline -td any . port 5060

If you are using the Internal and External profiles on their default ports you can log 5080 to see what it happening between Fusion and your supplier and log 5060 to see what is happening between Fusion and your phones. Of course you can log both 5060 and 5080 at the same time.

tcpdump -i any -w capture.pcap port 5060 or port 5080

When diagnosing problems with audio you need to look at the SDP body part where it exists in the SIP message, typically in an INVITE and the 200 OK - You may see SDP bodies in other messages like a 183 session progress.

Here is a typical INVITE message with an SDP body:

U 2019/11/18 15:06:10.652575 22.23.24.25:1024 -> 144.145.146.147:5060
INVITE sip:*9664@af-sandpit-1.mydomain.uk:5060 SIP/2.0.
Via: SIP/2.0/UDP 22.23.24.25:1024;branch=z9hG4bK2869618489;rport.
From: "201" <sip:201@af-sandpit-1.mydomain.uk:5060>;tag=2707493168.
To: <sip:*9664@af-sandpit-1.mydomain.uk:5060>.
Call-ID: 0_3506530060@192.168.6.43.
CSeq: 1 INVITE.
Contact: <sip:201@22.23.24.25:1024>.
Content-Type: application/sdp.
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE.
Max-Forwards: 70.
User-Agent: Yealink SIP-T46S 66.84.0.15.
Supported: 100rel.
Supported: from-change.
Supported: timer.
Session-Expires: 1800;refresher=uac.
Min-SE: 90.
Allow-Events: talk,hold,conference,refer,check-sync.
Supported: replaces.
Content-Length: 255.
.
v=0.
o=- 20154 20154 IN IP4 22.23.24.25.
s=SDP data.
c=IN IP4 22.23.24.25.
t=0 0.
m=audio 12690 RTP/AVP 9 8 101.
a=rtpmap:9 G722/8000.
a=rtpmap:8 PCMA/8000.
a=ptime:20.
a=sendrecv.
a=rtcp:12691.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.

This is my desk phone, ext 201, calling music on hold *9664.
The first line shows the source and destination for the packet; my desk phone is on IP 22.23.24.25 and my FusionPBX is on IP 144.145.146.147.

The SDP body is below the dot following the Content-Length header. The c=IN IP4 22.23.24.25. is instructing the PBX to send its audio to IP address 22.23.24.25, and the m=audio 12690 is specifying the port. The SDP in the 200 OK from the PBX will instruct the desk phone where to send it's audio. If all the IP addresses and ports are correct we should have two way speech.

With this information it is relatively easy to see if the audio is being sent to the wrong place.

I hope that helps a little.

Thank you! Can provider ignore my 200 OK(SDP) messages? May be some header in SDP body is incorrect? I attached some printscreens from sngrep. Сould you look at the file?

 

[Adrian Fretwell]

OK. I assume:
the IP ending in 22 is your SIP trunk provider
192.168.4.112 is your FusionPBX
10.0.5.20 is your VoIP phone

You see the 200 OK message from Fusion to the SIP provider is repeated several times, this is because Fusion is not seeing a response to the 200 OK from your SIP provider. The most likely reason your SIP provider is not responding (or more correctly, you are not seeing it) is because you have an RFC 1918 IP address (192.168.4.112) in your Contact header.

You may also want to check your port forwarding/DMZ set up. Because the INVITE from your SIP provider is going to port 5060 on your Fusion, this is normally the Internal profile, I would have expected to see the INVITE going to 5080.

If your Fusion thinks it's external interface is listening on external_sip_ip port 5080 then external_sip_ip port 5080 should be forwarded to 192.168.4.112:5080.

I'm just trying to guess your network setup here, diagnostics are always difficult at a distance!

 

[AndreyRubtsov]

OK. I assume:
the IP ending in 22 is your SIP trunk provider
192.168.4.112 is your FusionPBX
10.0.5.20 is your VoIP phone

You see the 200 OK message from Fusion to the SIP provider is repeated several times, this is because Fusion is not seeing a response to the 200 OK from your SIP provider. The most likely reason your SIP provider is not responding (or more correctly, you are not seeing it) is because you have an RFC 1918 IP address (192.168.4.112) in your Contact header.

You may also want to check your port forwarding/DMZ set up. Because the INVITE from your SIP provider is going to port 5060 on your Fusion, this is normally the Internal profile, I would have expected to see the INVITE going to 5080.

If your Fusion thinks it's external interface is listening on external_sip_ip port 5080 then external_sip_ip port 5080 should be forwarded to 192.168.4.112:5080.

I'm just trying to guess your network setup here, diagnostics are always difficult at a distance!

Thank you. You guess it right. I'll think about your assumption about the causes of the problem.

 

[AndreyRubtsov]

How can i put my external ip to Contact header instead of 192.168.4.112? which variables can i use?external_rtp_ip and external_sip_ip? i set them to my external ip yesterday, and it doesn't work as i see.

 

[Adrian Fretwell]

How can i put my external ip to Contact header instead of 192.168.4.112? which variables can i use?external_rtp_ip and external_sip_ip? i set them to my external ip yesterday, and it doesn't work as i see.

I think the reason 192.168.4.112 was in the Contact header is because your inbound call is hitting your internal profile on port 5060 not your external profile on port 5080.

 

[AndreyRubtsov]

i changed my forwarding rules. From External 5060 to Fusion 5080. I thought it would help, but it wouldn't.

 

[Adrian Fretwell]

Just double check that in your external SIP profile you have set ext-rtp-ip and ext-sip-ip to your actual external IP address or set the equivalent variables. When you originally configured your external IP did you edit the values in Advanced->Variables?

 

[AndreyRubtsov]

Thank you! It works! At the beginning i changed external_rtp_ip $${local_ip_v4} to my Exrternal IP in Advanced->Variables. i thought that ext-rtp-ip will use this variable. Now i set my external_rtp_ip to $${local_ip_v4} and ext-rtp-ip to External IP and it works! Thank you for help!