Speaking in general terms not specific Perimeta and Broadsoft, to this can be addressed at the TCP, TLS, and SIP levels with various methods of keep-alive traffic. TCP keep-alive is an optional feature which only needs to be supported by one peer; the other peer simply ACKs the packet like any other. Check if you can enable this on the server side instead of relying on the endpoint. If TLS is an option, that has it's own heartbeat separate from TCP keep-alive. At the SIP level, in our experience OPTIONS polling from the server is sufficient to keep a NAT pinhole open over UDP, and should work similarly for TCP. When enough OPTIONS polls time out, we tear down the registration. This isn't foolproof, as calling to the endpoint will be down until it's next successful registration, but has less overhead than constantly processing registrations. Regards, *Calvin Ellison* Voice Services Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com <http://www.voxox.com/> * 9276 Scranton Rd, Suite 200 San Diego, CA 92121 [image: Voxox] On Thu, Dec 17, 2015 at 11:43 AM, David Sarvai <dsarvai at dscicorp.com> wrote:

Group:

I am trying to complete a conversion from Acme Packet/Oracle SBC to Metaswitch Perimeta SBC. We found late during the cutover process that Polycom/Metaswitch hasn?t implemented a common TCP strategy to keep firewall TCP sessions/connections alive. Has anyone in the group successfully implemented a TCP strategy and if so, am I missing anything?

With the ACME topology, all phones do the following regardless of protocol to maintain pinholes through firewalls:

1 SEC Phone -> Register -> Firewall -> SBC -> Register -> Broadsoft

1 SEC Phone <- Register (expire 60 Seconds) <- Firewall <- SBC <- Register (Expire 1 Hour) <- Broadsoft

60 SEC Phone -> Register -> Firewall -> SBC

60 SEC Phone <- Register (expire 60 Seconds) <- Firewall <- SBC

Polycom: Requires use to frequent SIP registration (maintained by Perimeta) to keep SIP pinholes through firewalls alive.

Metaswtich: Requires TCP clients (Polycom) to maintain pinholes using native TCP keepalive syn/ack messages.

Polycom?s implementation of ?TCP keepalives? is only applicable if the phone is using TLS. There is no such setting for non-tls TCP based traffic. So the phone will establish a TCP connection to the SBC, and then site dormant if no registration/call/subscription messages traverse. The firewall will close its ports, and the phone will lose connectivity.

Metaswitch has a fast-nat feature, which is used to shield switches from UDP based registrations. When enabled, fast-nat modifies the endpoint expire timer to allow the endpoint to re-register (keeping the firewall session alive). For UDP, this works correctly, and the SBC responds to the endpoint with a 200OK. But for TCP, the SBC passes the re-registration attempt back to the switch.

TCP Metaswitch Example with fast-nat:

1 SEC Phone -> Register-> Firewall -> SBC -> Register -> Broadsoft

1 SEC Phone <- Register (expire 60 Seconds) <- Firewall <- SBC <- Register (Expire 1 Hour) <- Broadsoft

60 SEC Phone -> Register-> Firewall -> SBC -> Register -> Broadsoft

60 SEC Phone <- Register (expire 60 Seconds) <- Firewall <- SBC <- Register (Expire 1 Hour) <- Broadsoft

My question to the group, is has anyone implemented TCP based registration using Perimeta and Broadsoft?

Dave

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops