<?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 Re: sip trunk in General Topics</title>
    <link>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196849#M33008</link>
    <description>&lt;P&gt;we are using R81.10 take 66 are we affected?&lt;/P&gt;</description>
    <pubDate>Wed, 01 Nov 2023 21:26:16 GMT</pubDate>
    <dc:creator>knassif</dc:creator>
    <dc:date>2023-11-01T21:26:16Z</dc:date>
    <item>
      <title>sip trunk</title>
      <link>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196844#M33005</link>
      <description>&lt;P&gt;we are having an issue where i'm using a auto nat of an object that NATS to the internet on a public IP address for a sip trunk cube router that connects to a provider, the provider is still seeing the RFC1918 IP address of the cube router and not the public NAT that it autonats to, what could be the issue here and what can be done to fix it. we dont have application layer blade , only firewall blade.&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 20:38:46 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196844#M33005</guid>
      <dc:creator>knassif</dc:creator>
      <dc:date>2023-11-01T20:38:46Z</dc:date>
    </item>
    <item>
      <title>Re: sip trunk</title>
      <link>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196845#M33006</link>
      <description>&lt;P&gt;Depending on what version and HF you are running, that is a known issue with SIP and auto NAT. The fix would be to use a manual NAT rule.&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 20:55:59 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196845#M33006</guid>
      <dc:creator>CaseyB</dc:creator>
      <dc:date>2023-11-01T20:55:59Z</dc:date>
    </item>
    <item>
      <title>Re: sip trunk</title>
      <link>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196849#M33008</link>
      <description>&lt;P&gt;we are using R81.10 take 66 are we affected?&lt;/P&gt;</description>
      <pubDate>Wed, 01 Nov 2023 21:26:16 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196849#M33008</guid>
      <dc:creator>knassif</dc:creator>
      <dc:date>2023-11-01T21:26:16Z</dc:date>
    </item>
    <item>
      <title>Re: sip trunk</title>
      <link>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196918#M33030</link>
      <description>&lt;P&gt;&lt;A href="https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/R81.10/R81.10-List-of-all-Resolved-Issues.htm?tocpath=_____4" target="_self"&gt;R81.10 Fixes&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It doesn't look like it from the notes, but it wouldn't hurt to try the manual NAT rule. I've seen VoIP NAT issues appear multiple times in the fixes over the last couple years. We are not experiencing this issue on R81.10 Take 110 using manual NAT for SIP.&lt;/P&gt;</description>
      <pubDate>Thu, 02 Nov 2023 14:35:08 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196918#M33030</guid>
      <dc:creator>CaseyB</dc:creator>
      <dc:date>2023-11-02T14:35:08Z</dc:date>
    </item>
    <item>
      <title>Re: sip trunk</title>
      <link>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196956#M33032</link>
      <description>&lt;P&gt;just tried manual NAT's still did not work&lt;/P&gt;</description>
      <pubDate>Thu, 02 Nov 2023 18:10:18 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/sip-trunk/m-p/196956#M33032</guid>
      <dc:creator>knassif</dc:creator>
      <dc:date>2023-11-02T18:10:18Z</dc:date>
    </item>
  </channel>
</rss>

