Just thought this might help others after troubleshooting intermittent failures to receive incoming calls on Sipgate that had been working well, not sure if something has changed at Sipgate recently or I had just been lucky until now. This issue may crop up with other providers.
This seems to be related to only IPv6 which should be less troublesome without NAT in the way, in theory.
Problem I had: some calls didn’t come through, the caller would hear quiet for about 15 or 20 seconds then get voicemail at Sipgate, outgoing calls were always working and fine and other calls immediately after would come through okay.
Thankfully I’m using pfSense and the troubling shooting tools available are a huge help in tracking down issues like this.
So most SIP phones will just work via IPv6 without needing anything done on the firewall. The SIP phone creates an outbound connection to the SIP server on port 5060 and holds it open ready to receive any calls or to make a call. Firewalls typically always allow outbound connections by default and only drop unsolicited connections coming in, so it will just work. Incoming calls are fine on the already established connection. The complexities of NAT are no longer an issue on IPv6 so one way audio should be a thing of the past.
So when a call coming in is signalled to the phone over the connection being held open all is good. However, Sipgate have more than one IPv6 SIP server, and occasionally rather than signal from the server the SIP phone has connected to, Sipgate would try and send an “incoming call” notification from one of their other servers. The firewall quite correctly rejects this incoming connection as there is no existing connection established between that server and the SIP phone, and so the SIP phone never gets the message that a call is being received. Sipgate eventually give up and put the call through to voicemail, hence the 15 or so seconds of silence the caller has.
The solution was to add a firewall rule to allow any incoming connection from Sipgate servers, in this case this is the range 2001:ab7::/32, this immediately resolved the problem. Thankfully I could see all this happening in the firewall logs on pfSense and using pfTop with a filter to see the connections coming in and out to the SIP phone in almost real time. Hopefully this may help someone from spending time trying to solve such an intermittent problem like this.
I don’t think this particular issue happens on IPv4 (I hadn’t seen it) as SIP providers must assume or can tell it is over NAT and so make sure SIP servers are sticky, i.e. they always signal calls from the same server that has established the SIP connection. With IPv6 the assumption must be it is a public facing reachable IP address with no NAT involved and so can receive packets from any server and they load balance, but that only works if the firewall is told to allow those connections of course.
Another interesting thing I found out that happens is when a call is established the RTP packets arriving carrying the audio are initially blocked by the firewall (as seen by loads of blocked entries in the log) as they too come from a different server again aimed at ports not previously opened by the SIP phone. I wondered how on earth it worked. Turns out this is a known issue and it simply works because the SIP phone and remote server deliberately default to using the same ports for RTP, so once the SIP phone has caught up and establishes its outgoing RTP connection for audio, the incoming ones can then find their way in using the same established connection. With adding the allow firewall rule this also fixes this ‘dirty’ start to the call setup.