Checkpoint Firewall Router with 2talk

Forums › VoIP › Checkpoint Firewall Router with 2talk

Suckerpunch

85 posts

Master Geek
+1 received by user: 16

Topic # 240319 1-Sep-2018 19:51

Hey guys,

Has anyone got experience with a Checkpoint 6xx, 7xx or 11xx firewall/router and configuring it to let 2talk SIP through?

Even with every blade turned off, the Checkpoint prevents all incoming calls to my Cisco SPA502G via the UDP protocol (they're sent to VM).
When I set the SPA to the TCP protocol, I end up with registration issues and calls connecting but no audio.

I've read in these forums and from 2talk support about disabling ALG.
But I can't figure out where and how to do this on the appliance.

Any advice or tips would be much appreciated!

Thanks heaps.
Phil

speed

157 posts

Master Geek
+1 received by user: 51

Reply # 2082597 1-Sep-2018 23:07

Try registering to 2talk using SIP port 50060 instead of 5060. They listen on both ports, and often using 50060 is enough to bypass an ALG.

Suckerpunch

85 posts

Master Geek
+1 received by user: 16

Reply # 2082654 2-Sep-2018 09:13

Thanks Speed!

By doing that the call is now making it through to the actual phone.
But when I answer the call on the phone, it sits there's saying "answering"........and then "call failed".

speed

157 posts

Master Geek
+1 received by user: 51

Reply # 2082665 2-Sep-2018 09:35

Bugger! It sounds like the signalling is getting through now, but not the media.

Are you able to change your SIP client to use TCP for it's transport layer instead of UDP? That may help.

Suckerpunch

85 posts

Master Geek
+1 received by user: 16

Reply # 2082960 3-Sep-2018 07:09

Hey,

So have changed to TCP with port 50600. I don't seem to have the registration issues now, and calls do answer and connect...

However I've now got this issue where when an outgoing or incoming call is answered, there is no audio.
Some phones are affected, and others aren't. A couple of restarts of the phone and the audio works again (but unsure for how long).

2talk support explain that this issue is caused by outgoing audio being blocked...

"I can see this device never sent us an audio stream after we told it the call was answered. We need to receive an audio stream for us to respond with one due to the way we do 'symmetric RTP' - responding with reversed source/destination IP addresses and ports."