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 <matt...@corp.crocker.com> 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 <voiceops-boun...@voiceops.org > <mailto:voiceops-boun...@voiceops.org>> on behalf of Pete Mundy > <p...@mac.geek.nz <mailto:p...@mac.geek.nz>> > Date: Thursday, June 10, 2021 at 5:11 PM > To: VoiceOps <voiceops@voiceops.org <mailto:voiceops@voiceops.org>> > 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 <abalas...@evaristesys.com > >> <mailto:abalas...@evaristesys.com>> 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 > VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org> > https://puck.nether.net/mailman/listinfo/voiceops > <https://puck.nether.net/mailman/listinfo/voiceops>_______________________________________________ > VoiceOps mailing list > VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org> > https://puck.nether.net/mailman/listinfo/voiceops > <https://puck.nether.net/mailman/listinfo/voiceops>
_______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
