Inbound Calls, No Audio. Outbound Calls - OK. Displacing SonicWALL.

[JackPrendergast]

Hello,

I am in a sticky situation with a customer of mine.

We are displacing SonicWALL. The migration has been no problem minus the telephony system.

Due to this, the cutover has had to be rolled back multiple times.

Ill try keep this brief to aid assistance 🙂 

TAC case has been raised, but any technical advice would be wonderful. This is a particular unique setup with a Teams front end as a softphone client, with a SBC on site with the SIP trunks being on a different network delivered in by a 3rd party.

• SonicWALL works no problem.
• Outbound calls work no issues at all.
• Inbound calls connect, but no audio, at all regardless of direction can be heard.
• This is a Check Point 6000 cluster running R81.10 and fully patched.

SIP ALG has been disabled and enabled many times. Interestingly, outbound calls only work with the proper defined SIP object.

NAT Rules are all static, and not hide.

SIP Inspection settings have been changed not to change hide NAT source port regardless.

The topology is as follows

Microsoft Teams Public ->NAT-> SBC on Premise ->NAT-> Telephony Provider Network

• When calls outbound are established, I see the full SIP stream and audio stream in a packet capture.
• Inbound, I see the SIP messages and SIP OK message but never see any high UDP or any resemblance of RTP packets inbound on the WAN interface and subsequently nothing on the LAN towards the SBC.

Facts:

• Outbound is fine (so I dont believe its NAT)
• Inbound calls establish. No audio (Had similar issues with outbound until we used the 'SIP' object)
• R81.10 Cluster fully patched
• NAT Rules are all ok (As above. Calls establish/terminate fine. No RTP stream is seen in logs or packet capture)
• SIP service in rules has been removed and added. Makes no difference to inbound.
• No threat prevention enabled at this time.

Thanks all!

[G_W_Albrecht]

Did you contact TAC yet ?

[JackPrendergast]

TAC contacted. No response yet.

I have narrowed the issue to where I think it is.

SIP Session is OK - so lets ignore 5060 etc.

RTP is the issue. Between SBC and Microsoft Teams I can see the outbound RTP. Fixed source port, high UDP destination port

Nothing is coming back from Microsoft Teams as far as I can see on SmartConsole.

Due to having to roll back, no kernel debugs or packet captures to 100% verify the above.

Any advice on if you have seen inbound RTP streams being received but being chewed in the kernel (hence no SC logs)  would be welcome 🙂 

[Alex-]

You could check if they are dropped and received on the external internal with a. kernel debug.

cppcap -i <external interface>

fw ctl debug 0
fw ctl debug -buf 32768
fw ctl debug -m fw + drop conn
fw ctl kdebug -T -f > debugfile.txt
<Make Teams call>
fw ctl debug 0

[the_rock]

Well, I know in the old days of CP, one thing people would do is set protocol handler to none, but not sure if that made any difference for you.

Andy

 

[JackPrendergast]

This is the odd thing..

Outbound calls only work with the protocol handler set! Role reversal.

[the_rock]

Got it. I would follow voip ARTG sk (cant get it now, as support center is super slow), but if that does not help, TAC case I suppose...

Andy