The metaswitch way is that it will do it automatically for you if it thinks you're behind a NAT. So if you force nat, it will do the fast registration automatically. It's one line of config on the sip adjacency for the MaxUC application.
> On Jun 10, 2021, at 5:33 PM, Matthew Crocker <[email protected]> wrote: > > > The acme/oracle way of doing Hosted NAT Traversal is to set the expire time > down to 30 seconds and have the phones REGISTER every 30 seconds. The SBC > eats the registration so it doesn’t overload the switch. If the CGN NAT > drops the entry it gets recreated with the new registration in 30 seconds. > > We have had very good results with the acme/oracle approach > > From: VoiceOps <[email protected] > <mailto:[email protected]>> on behalf of Pete Mundy > <[email protected] <mailto:[email protected]>> > Date: Thursday, June 10, 2021 at 5:11 PM > To: VoiceOps <[email protected] <mailto:[email protected]>> > Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data > > CAUTION: This email originated from outside of Crocker. Do not click links or > open attachments unless you recognize the sender and know the content is safe. > > > Precisely. And those "NAT table entries" eventually time out. On CG-NAT they > often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over > UDP regularly keeps the NAT table entries refreshed and active and therefore > the UDP 'connection' open. I've come across firewalls with 30 second > timeouts, so we use 25 second keepalives (OPTIONS). > > Pete > > >> On 11/06/2021, at 8:24 AM, Alex Balashov <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Not to muddy the waters here with needless pedantry, but: > >> > >> While UDP may be "connectionless", the only way UDP, and in particular, > >> symmetric SIP signalling, can work through NAT is if a stateful firewall + > >> NAT gateway has some awareness (that is, state) of UDP "flows", or groups > >> of packets flowing between ports consistently in some kind of temporary > >> logical association--one might say, the endpoints have a "connection" of > >> sorts... > >> > >> -- Alex > >> > > On 6/10/21 4:07 PM, Peter Beckman wrote: > > uhhhh.... SIP here is UDP, no? > > There's no connection to close for UDP. > > The source port for UDP doesn't matter. It's not part of the whole > > conversation, unless your switch cares that all communications continue to > > come from the source port. It's connectionless. > > TCP 5060 isn't even listening on our switches. > > So, maybe you're doing SIP over TCP? > > On Thu, 10 Jun 2021, Mark Wiles wrote: > _______________________________________________ > VoiceOps mailing list > [email protected] <mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/voiceops > <https://puck.nether.net/mailman/listinfo/voiceops>_______________________________________________ > VoiceOps mailing list > [email protected] <mailto:[email protected]> > https://puck.nether.net/mailman/listinfo/voiceops > <https://puck.nether.net/mailman/listinfo/voiceops>
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
