Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
beneaton
Contributor

Intermittent VOIP One Way Audio

Jump to solution

Hi,

I am seeing an issue with intermittent one-way audio / transmission on VOIP calls.
Happens every 1 in 6 or 7 calls I'd say.

If the issue happens mid-way through the call, logs show as normal/accept/matched to rule 47, etc.
The immediate call after that more often than now has OWT from the start - that shows in the logs as an accept, but with the protocol error:

" Firewall - Protocol violation detected with protocol:(RTP), matched protocol sig_id:(1), violation sig_id:(9), (500) "

The rule it matches with is just 
Source Network Grp - Destination Network Grp - Any - UDP_4000-60000 and UDP-16000-16511 - Accept - Log

Any help appreciated, on whether the above is related/the cause or where to start troubleshooting - Difficult to start with as there is no actual 'drop'.

Thanks,

Ben

1 Solution

Accepted Solutions
HeikoAnkenbrand
Champion
Champion

Hi @beneaton,

Issue description:

Telephone VoIP connections are terminated and can no longer be established. 

Issue debug:

On the firewall you see a typical issue with the following message if you start: # fw ctl zdebug drop

Issue message: fwconn_key_init_links (INBOUND) failed

Solution:

There are two different Servers on the SIP/RTP provider's side that take part in the process of establishing the SIP/RTP call:

  • Server for SIP (Management and control)
  • Server for RTP (Media and Voice Data)

Make sure that the UDP high ports from the internal RTP VoIP telephone system to the provider RTP server on the RTP provider's side are dropped by the rule base.

Take a look at this Articel. I had the same problem and could fix it with the following settings.

VoIP Issue and SMB Appliance (600/1000/1200/1400)

PS: This does not only affect SMB appliances.

View solution in original post

9 Replies
beneaton
Contributor
- If the OWT happens mid-call, logs are accept/no protocol violation alert
- If a call is made straight after a call like above, OWT is present from the start, logs are accept WITH protocol violation alert
- Using NAT
- Panasonic NSxxx
- Gamma SP
0 Kudos
Reply
PhoneBoy
Admin
Admin
Please provide some basic details about your environment like software/JHF version, whether NAT is involved, what rules you're using to aceept traffic, etc.
0 Kudos
Reply
beneaton
Contributor
Hi,

Check Point Cluster - R80.10
NAT is involved, yes.
The Rule accepting the traffic is
'a network/sipgrp' - ' another network/sip grp' - Any - UDP_4000-60000 and UDP_16000-16511 - Accept - Log
The log with the accept/alert has source port 16001, and destination service UDP/6167

No drops seen at all on Firewall
0 Kudos
Reply
HeikoAnkenbrand
Champion
Champion

Hi @beneaton,

Issue description:

Telephone VoIP connections are terminated and can no longer be established. 

Issue debug:

On the firewall you see a typical issue with the following message if you start: # fw ctl zdebug drop

Issue message: fwconn_key_init_links (INBOUND) failed

Solution:

There are two different Servers on the SIP/RTP provider's side that take part in the process of establishing the SIP/RTP call:

  • Server for SIP (Management and control)
  • Server for RTP (Media and Voice Data)

Make sure that the UDP high ports from the internal RTP VoIP telephone system to the provider RTP server on the RTP provider's side are dropped by the rule base.

Take a look at this Articel. I had the same problem and could fix it with the following settings.

VoIP Issue and SMB Appliance (600/1000/1200/1400)

PS: This does not only affect SMB appliances.

View solution in original post

Chris_Hrachowy
Participant

We had the same problem and could solve it with @HeikoAnkenbrandˋs solution.

Thank you

0 Kudos
Reply
Noam_Warhaftig
Employee
Employee

Hi,

I'm Noam from CP-R&D, owner of VoIP development.

I read your question and answers and I would like to jump in.

Security-wise it's not recommended to open a dedicated rule for high-ports, the SIP handler should open the ports dynamically be demand.

We inspect SIP control packets and decide what ip/port should be opened for every call.

From the look on your problem it seems to be related to NAT not being done properly on the payload, that's usually the root cause for one-way audio.

More than that, if RTP matches the rulebase instead of being open dynamically, it won't be NATted correctly.

If you would like to debug the configuration please contact me directly - noamwa@checkpoint.com

Thanks.

0 Kudos
Reply
Daniel_Taney
Advisor

If you all don't mind, I'd like to piggyback on this thread because it seems to be very pertinent to an issue we are having with our remote users right now. 

I have a case open with TAC and they also pointed me to sk65072. I had a few followup questions; which they haven't responded to yet. I know they are so insanely swamped right now, I figured maybe someone in this thread might be able to clarify them and free up some precious TAC cycles...

1.) Not to sound too dumb here, but when it says remove that list of SIC protocols from the rule base, it literally means just remove their usage in the Access Policy through which the affected traffic is flowing? 

2.) My next question feels equally as dumb, once I remove them from the Rulebase, how is the traffic going to be allowed? Is that where fw ctl set int voip_multik_enable_forwarding 0 comes into play?

I realize both of these questions sound super-basic, but I guess I never got a good foundation on how Check Point handles SIP and possibly how it differs from how most other traffic is dealt with?

I really appreciate any clarity you all may be able to provide!

-Dan

R80 CCSA / CCSE
0 Kudos
Reply
Daniel_Taney
Advisor

TAC responded and clarified a number of my confusions.

1.) The idea is to replace the referenced SIP services with custom ones. So, yes, they need to be removed, but you need to put custom ones in their place. (Makes total sense).

2.) The thing I wasn't picking up on was that the presence of ANY of those SIP services in the entire rule base affects the way SIP traffic is handled. It doesn't just pertain to the one access rule your traffic is matching on. This was where I was getting stuck because I had replaced services in the rules the traffic should be matching to, but it was still dropping. 

This happens because the presence of those "built-in" SIP services referenced in the SK in the rule base actually inserts fw early SIP NAT (sipnat) into the in-chain of the Gateway. Once that is in the chain, all SIP traffic is getting intercepted by it, regardless of how your services in the rule base are defined. 

Understanding all this now, I can confirm that once I replaced all instances of the built-in SIP services from this particular rulebase + installed policy the fw early SIP NAT (sipnat) vanished from the fw chain!

 

3.) So, I guess my only unresolved question is whether the voip_multik_enable_forwarding variable still needs to be set to 0. At the moment, the GW still has this variable set to 1.

R80 CCSA / CCSE
0 Kudos
Reply
Noam_Warhaftig
Employee
Employee

Hi Dan,

I understand that you try to disable SIP handlers but as I tried to say, it's not recommended.

If you have a problem with one-way audio, the best path is to debug it and understand what's wrong with the configuration (most cases it's a simple change).

If you use NAT you have to use the SIP handler as you need to NAT the SIP payload (SDP) as well as the IP headers.

Regarding voip_multik_enable_forwarding, this param defines if we direct all SIP connections to the global instance (CoreXL), so if you don't use the SIP handler you can disable it (set to 0) and let all instances deal with SIP for better performance.

To summarize, I suggest to open a ticket with TAC and try to solve the issue without disabling SIP handlers.

Cheers,

Noam.

0 Kudos
Reply