Freeswitch Automatically Hangs Up After ~30 Seconds

[dryauquaman]

Newbie here. I've been groping my way through this and finally decided reach out for help.
I'm working with a default (demo) Freeswitch configuration on a Raspberry Pi.
Using a SIP client on my cell phone as extension 1005, I can dial into Tetris at 9198.
Using sngrep, I can see the connection being made, then FS sends ~10 200 OK sdp packets then sends a BYE.
I can connect to other SIP clients and the same thing happens.
Here's what it looks like in sngrep:

Client FS
------- ------
Invite -->
<-- 407 Proxy Auth Req
ACK -->
Invite -->
<-- 100 Trying
<-- 200 OK
<-- 200 OK
(snip)
<-- 200 OK
<--BYE
200 OK --->

It takes about 30 seconds before I get the BYE.


It doesn't matter what SIP client I use. I've tried it on my cell phone, PC and and ATA.
I've no idea what might be causing it.
Can you give me an idea where to look?

 

[Adrian Fretwell]

You would normally expect the client to respond with an ACK to the 200 OK. There are several possibilities; the client is not seeing the 200 OK or it is sending the ACK to the wrong place - the ACK is clearly not getting to your server. We can work out more from a full packet capture (you can 'save as' from sngep).

 

[dryauquaman]

Thank you. I should have just posted the pcap in the first place.

 

[Adrian Fretwell]

From a quick glance, it looks like your server is setting the contact header in the 200 OK to:

Contact: <sip:9198@69.244.183.148:5060;transport=udp>

This means that your client will try to send the ACK to 69.244.183.148 instead of 192.168.1.40.

As you become more familiar with the SIP protocol you will be able to easily spot issues like this.

 

[dryauquaman]

From a quick glance, it looks like your server is setting the contact header in the 200 OK to:

Contact: <sip:9198@69.244.183.148:5060;transport=udp>

This means that your client will try to send the ACK to 69.244.183.148 instead of 192.168.1.40.

As you become more familiar with the SIP protocol you will be able to easily spot issues like this.

Thank you. I'll study that out a bit so I'm sure to understand it.

The follow-on question is, where do I change that?
I know the system is doing a STUN lookup on boot. This project will not require any outside access.
I've tried to Google-Fu it but all I can find are comments telling people to turn off STUN or start FS with an option flag, but I haven't see anywhere someone said how to turn it off.

Then again, maybe STUN isn't the cause of the problem here.

 

[Adrian Fretwell]

Unless things have changed recently, I don't believe that STUN is enabled by default in FreeSWITCH or in the FusionPBX configuration.

What IPs are written into Contact headers and SDP bodies are controlled by the ext-sip-ip and ext-rtp-ip settings in your internal and external SIP profiles. If all you are doing is contained within your local LAN subnet, then set these values to the local IP of the server.

 

[dryauquaman]

Interesting. I thought I read that somewhere in my digging. I'll look to see if I can find where I saw that.

In the meantime, I was able to program a Mitel ATA up as one of the default extension. It doesn't have that problem.
I'm trying to figure out what the difference is. Both the SIP client I have on my cell phone and one I put on my laptop both have the 200OK problem.

The one problem I do have with all of them, is that when I dial an extension number, there is a 10 second delay between the invite/100trying and when it answers with a 200OK. It's as if FS is waiting for something.

 

[dryauquaman]

That was it! I changed ext-sip-ip and ext-rtp-ip to be my server's IP.
It no longer hangs up after a few seconds.

I still have the 10 second delay before the call starts ringing. It's 10 seconds after seeing the 100 Trying.
Any idea about that?

 

[dryauquaman]

I found the problem with the delay.
I saw the warnings about changing the default password in the /log 7.
I had ignored it. As soon as I changed it, the delay went away.

Now on to the next phase of this little project.