<?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: Is it possible to keep SIP calls from dropping when failing over between ISPs, or using ECMP? in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/is-it-possible-to-keep-sip-calls-from-dropping-when-failing-over/m-p/196137#M58467</link>
    <description>&lt;P&gt;Hi &lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/48353"&gt;@uvdes&lt;/a&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;When the firewall fails over, an existing session has been synced to the secondary member so it can pick up mid-session&lt;/P&gt;
&lt;P&gt;when PBF fails over, an existing session cannot continue as the routing/src-dst-zones/NAT will all change, so a new session needs to be created over the new path&lt;/P&gt;</description>
    <pubDate>Mon, 22 Jan 2018 08:05:02 GMT</pubDate>
    <dc:creator>reaper</dc:creator>
    <dc:date>2018-01-22T08:05:02Z</dc:date>
    <item>
      <title>Is it possible to keep SIP calls from dropping when failing over between ISPs, or using ECMP?</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/is-it-possible-to-keep-sip-calls-from-dropping-when-failing-over/m-p/196091#M58463</link>
      <description>&lt;P&gt;I've heard of some SD-WAN providers that claim their devices will allow ISP aggregation and failover between ISPs without dropping SIP calls when one ISP goes down.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Is this achievable without putting a SD-WAN device between our firewalls and the ISPs?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;At our site we have two ISPs, and currently are using PBF and monitoring to fail over between the two. We may start using ECMP if we get a fast backup connection.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Right now if we fail over the SIP calls drop, and then we can re-establish them on the second ISP. On the other hand, failing over between the firewalls creates a few seconds of silence, but everything then works again without having to call out.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Does anyone know if it is possible to retain SIP calls if the ISP being using for the SIP calls goes down? It isn't often that our primary does down, but would be great to provide the capability if possible.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks much experts!&lt;/P&gt;</description>
      <pubDate>Sun, 21 Jan 2018 19:53:13 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/is-it-possible-to-keep-sip-calls-from-dropping-when-failing-over/m-p/196091#M58463</guid>
      <dc:creator>uvdes</dc:creator>
      <dc:date>2018-01-21T19:53:13Z</dc:date>
    </item>
    <item>
      <title>Re: Is it possible to keep SIP calls from dropping when failing over between ISPs, or using ECMP?</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/is-it-possible-to-keep-sip-calls-from-dropping-when-failing-over/m-p/196137#M58467</link>
      <description>&lt;P&gt;Hi &lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/48353"&gt;@uvdes&lt;/a&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;When the firewall fails over, an existing session has been synced to the secondary member so it can pick up mid-session&lt;/P&gt;
&lt;P&gt;when PBF fails over, an existing session cannot continue as the routing/src-dst-zones/NAT will all change, so a new session needs to be created over the new path&lt;/P&gt;</description>
      <pubDate>Mon, 22 Jan 2018 08:05:02 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/is-it-possible-to-keep-sip-calls-from-dropping-when-failing-over/m-p/196137#M58467</guid>
      <dc:creator>reaper</dc:creator>
      <dc:date>2018-01-22T08:05:02Z</dc:date>
    </item>
  </channel>
</rss>

