Making FreeSWITCH (and FusionPBX) to send the Ringback Tone Right Away

Today while doing a little support I had this strange issue: if a user dials out through a carrier, he/she will listen to the ringback tone right away; but if this same user calls to another extension he/she won't listen right away. Instead, you will have a variable dead air and then suddenly, the callee will answer.

When a caller listens to a ringback tone, it means that the callee has been reached and it has answered with a SIP signal. Usually, the normal SIP flow is as follows (it could vary):

1. Caller sends the INVITE to the switch
2. Switch sends the INVITE to the callee
3. Callee answers with a 1XX answer (could be 100 or 183) to report it started the ringing
4. Switch sends a 1XX answer to the caller followed by an RTP flow of the ringback tone
5. Callee answers
6. The switch sends a 183 (session in progress) followed by the voice RTP flow

Caller won't listen to the ringback tone until the callee answers with a SIP 1XX code and the switch forwards it. The reasons why this could happen are many. I can just think on the following (of course there are more):

• Addressing conflict: in the odd case, both switch and callee are behind a NAT. If for a reason both are using same addressing space, FreeSWITCH could try to route it directly, which it is wrong. This takes time as FreeSWITCH tries different routes, but it will do the most evident. If you are in this situation, you could use a STUN or TURN server to work around this issue. This will hide the private addressing on the callee end, therefore FreeSWITCH will try to reach using the public IP route.
• NAT issues: some modems could have problems with NAT. The NAT table could be expiring sooner than the SIP registration, this will make an incoming SIP signal to fail. Another reason could be the SIP ALG. SIP ALG will rewrite SIP payload (as SIP payload has IP addressing within). Sometimes, a bad SIP ALG implementation will break the INVITE. Another reason it comes to my mind is when the callee router changes IP very often, this will have a side effect in FreeSWITCH. If FreeSWITCH has multiple registrations enable, it will see more than one time your extension registered, therefore it will try them and this could delay the interaction with the right registration.

Of course, there are more reasons. I think these are the most common. Fortunately for everyone, the FreeSWITCH has a way to workaround this issue. This means it will answer with the 1XX SIP code without waiting for the callee to answer. To do this you just need to set the following variable, just before the bridge statement:

instant_ringback=true

That's it! Good Luck!