<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic VOIP - One way audio / Tranmission - Protocol violiation in Firewall and Security Management</title>
    <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VOIP-One-way-audio-Tranmission-Protocol-violiation/m-p/75129#M11663</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I have seen a few questions like this asked, but OPs have either not replied or fixed their issue for their own specific environment.&lt;BR /&gt;&lt;BR /&gt;Customer is&amp;nbsp;&lt;SPAN&gt;getting VOiP one-way audio/transmission intermittently.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;1. It is probably 1 in every 6 or 7 calls that get affected during the call (I.e. Starts off fine)&lt;BR /&gt;2. If a call is made immediately after the call that has just had OWT in the call, the new call has OWT from the start.&lt;BR /&gt;3. A log entry for the call that connected and had OWT part-way through, shows no errors (but I assume this is likely because the log was generated when it accepted the traffic, and won't revise itself to reflect any noticeable issues?)&lt;BR /&gt;4. The call immediately after (which has the OWT from the get-go) is still an accept log, but has the Alert! and the same warning as posted in the OP's post - "Firewall - Protocol violation detected with protocol:(RTP), matched protocol sig_id:(1), violation sig_id:(9), (500)"&lt;BR /&gt;5. The log that gets alerted, shows the same Interface as all the other accepts (without Alert!) but the Interface arrow points UP not DOWN - Maybe a Red Herring, but thought worth mentioning&lt;BR /&gt;6. I have asked for a copy of their Rule that the accept log matched, which I'll add once I have it.&lt;BR /&gt;7. NAT is being used.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Or is it even just a case of that the CP FW is unlikely to be the cause of the OWT?&lt;BR /&gt;&lt;BR /&gt;I'm trying to help a customer get to the bottom of it, they are not pointing the finger at us/Check Point but we want a prove it one way or another.&lt;BR /&gt;&lt;BR /&gt;Thanks,&lt;/P&gt;&lt;P&gt;Ben&lt;/P&gt;</description>
    <pubDate>Thu, 13 Feb 2020 13:16:58 GMT</pubDate>
    <dc:creator>beneaton</dc:creator>
    <dc:date>2020-02-13T13:16:58Z</dc:date>
    <item>
      <title>VOIP - One way audio / Tranmission - Protocol violiation</title>
      <link>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VOIP-One-way-audio-Tranmission-Protocol-violiation/m-p/75129#M11663</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I have seen a few questions like this asked, but OPs have either not replied or fixed their issue for their own specific environment.&lt;BR /&gt;&lt;BR /&gt;Customer is&amp;nbsp;&lt;SPAN&gt;getting VOiP one-way audio/transmission intermittently.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;1. It is probably 1 in every 6 or 7 calls that get affected during the call (I.e. Starts off fine)&lt;BR /&gt;2. If a call is made immediately after the call that has just had OWT in the call, the new call has OWT from the start.&lt;BR /&gt;3. A log entry for the call that connected and had OWT part-way through, shows no errors (but I assume this is likely because the log was generated when it accepted the traffic, and won't revise itself to reflect any noticeable issues?)&lt;BR /&gt;4. The call immediately after (which has the OWT from the get-go) is still an accept log, but has the Alert! and the same warning as posted in the OP's post - "Firewall - Protocol violation detected with protocol:(RTP), matched protocol sig_id:(1), violation sig_id:(9), (500)"&lt;BR /&gt;5. The log that gets alerted, shows the same Interface as all the other accepts (without Alert!) but the Interface arrow points UP not DOWN - Maybe a Red Herring, but thought worth mentioning&lt;BR /&gt;6. I have asked for a copy of their Rule that the accept log matched, which I'll add once I have it.&lt;BR /&gt;7. NAT is being used.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Or is it even just a case of that the CP FW is unlikely to be the cause of the OWT?&lt;BR /&gt;&lt;BR /&gt;I'm trying to help a customer get to the bottom of it, they are not pointing the finger at us/Check Point but we want a prove it one way or another.&lt;BR /&gt;&lt;BR /&gt;Thanks,&lt;/P&gt;&lt;P&gt;Ben&lt;/P&gt;</description>
      <pubDate>Thu, 13 Feb 2020 13:16:58 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/Firewall-and-Security-Management/VOIP-One-way-audio-Tranmission-Protocol-violiation/m-p/75129#M11663</guid>
      <dc:creator>beneaton</dc:creator>
      <dc:date>2020-02-13T13:16:58Z</dc:date>
    </item>
  </channel>
</rss>

