Netwerkvereisten en configuratie

Deze richtlijnen helpen om de verbinding met het Cloudoe-platform en de algemene kwaliteit en stabiliteit van de internetverbinding zo optimaal mogelijk te houden. De exacte invulling kan per omgeving verschillen, maar de uitgangspunten hieronder gelden in de praktijk als best practice.

Voor VoIP spelen relatief veel netwerkfactoren een rol in de gesprekskwaliteit en betrouwbaarheid, zoals NAT-gedrag, firewallfuncties en MTU/PMTUD. Niet alle effecten zijn direct zichtbaar, maar kunnen wel leiden tot klachten zoals mislukte gespreksopbouw of one-way audio.

In dit document worden daarnaast de benodigde poorten, IP-adressen en FQDN’s beschreven voor de verschillende Cloudoe-diensten. Waar mogelijk is het uitgangspunt: geen generieke inbound openstellingen, maar gecontroleerde outbound toegang en stateful return traffic.

Netwerk algemeen

In de meest gunstige situatie is er een apart VLAN of netwerk opgezet voor VoIP, waarbij het datanetwerk en het VoIP-netwerk elk een eigen poort op de router of firewall hebben met een eigen subnet. Voor de beveiliging wordt aangeraden een firewall te gebruiken die portscans kan detecteren en negeren (voorkomt spook gesprekken). VoIP-toestellen hebben geen algehele toegang tot het internet nodig, toegang tot DNS, NTP, het platform van Cloudoe en Device Provisioning is voldoende.

Inkomend hoeft er niets opengezet te worden. Inkomend hoeft er niets opengezet te worden, het gebruik van statische inbound NAT (1:1 NAT en/of DNAT/port-forwarding) wordt zelfs afgeraden. De benodigde port mappings worden namelijk automatisch door de firewall gegenereerd zodra een CPE een SIP-registratie uitvoert. De firewall maakt op dat moment automatisch een dynamische NAT/PAT mapping aan. Onze SBC’s houden vervolgens bij via welk publiek IP-adres en poortbereik de betreffende CPE bereikbaar is. Om te voorkomen dat die mapping bij inactiviteit dichtvalt, sturen de toestellen periodiek ‘keep-alive’ berichten. Zo blijft het toestel bereikbaar voor inkomende oproepen.

NAT en mediaverkeer

Het NAT-gedrag van de firewall of router is bepalend voor de bereikbaarheid en stabiliteit van de mediastromen (RTP). Wanneer een gesprek tot stand komt, moet de audio immers ongehinderd tussen het toestel en het platform kunnen vloeien.

Aanbevolen NAT-typen Voor een betrouwbare werking van zowel SIP- als RTP-verkeer wordt het gebruik van Loose NAT of Full Cone NAT sterk aanbevolen. Strikte of symmetrische NAT-configuraties vormen een risico: deze kunnen mediaverkeer blokkeren of resulteren in 'one-way audio' (waarbij slechts één partij de ander hoort).

Ondersteuning voor Symmetric Media Om de meeste NAT-scenario’s te overbruggen, ondersteunt het Cloudoe-platform symmetrisch RTP-gedrag (ook wel symmetric media genoemd). Dit houdt in dat het platform de uitgaande mediastroom pas start zodra het de eerste RTP-pakketten van de klantlocatie (de PBX of het toestel) heeft ontvangen. Het platform gebruikt die inkomende pakketten om te bepalen naar welk publiek IP-adres en welke poort de audio teruggestuurd moet worden. Hoewel dit veel NAT-problemen oplost, blijft Loose / Full Cone NAT de voorkeursoptie voor maximale compatibiliteit.

Aanbevolen configuratie:

• Schakel SIP ALG uit: Deze functie op routers en firewalls modificeert SIP-pakketten vaak op een onjuiste manier, wat leidt tot verbroken verbindingen of registratiefouten.

• Gebruik Loose NAT / Full Cone NAT: Dit zorgt ervoor dat de poortmapping voorspelbaar blijft voor verschillende bestemmingen.

• Lokale SBC: Overweeg de inzet van een lokale Session Border Controller voor mediabeheer in complexe netwerkomgevingen of bij multi-tenant opstellingen.
  

MTU, Path MTU Discovery (PMTUD)

De MTU (Maximum Transmission Unit) bepaalt de maximale pakketgrootte die zonder fragmentatie over het netwerk kan worden verzonden. In VoIP-omgevingen zie je MTU/fragmentatie-problemen meestal tijdens de gespreksopbouw, met name bij grotere SIP-berichten zoals INVITE en 200 OK. Door extra headers en langere velden (bijvoorbeeld uitgebreide display names) kan de pakketgrootte toenemen en in uitzonderlijke gevallen boven de gangbare 1500 bytes uitkomen (of 1492 bytes bij PPPoE). PMTUD werkt doordat de verzender uitgaat van een maximale MTU; als een pakket onderweg te groot is, meldt het netwerk dit terug met een ICMP “Packet Too Big / Fragmentation Needed”-bericht, waarna de verzender kleinere pakketten gaat gebruiken. Sommige routers/firewalls gaan echter slecht om met (UDP-)fragmentatie of blokkeren deze ICMP-berichten, waardoor grotere SIP-pakketten niet (correct) worden doorgestuurd. Dit kan leiden tot het herkenbare fenomeen dat een toestel wel ‘online’ lijkt (bijvoorbeeld omdat de SIP registratie succesvol is), maar dat een INVITE het Cloudoe-platform niet bereikt of dat het antwoord daarop niet terugkomt, met mislukte gespreksopbouw als gevolg. Het Cloudoe-platform kan SIP-pakketten ontvangen die groter zijn dan 1500 bytes en deze defragmenteren; hiervoor is het wel noodzakelijk dat de router/firewall in de klantomgeving (en het netwerkpad richting internet) UDP-fragmenten niet blokkeert en/of PMTUD toestaat, zodat deze pakketten het platform ook daadwerkelijk kunnen bereiken. Voor ICMPv6 wordt geadviseerd de filterrichtlijnen uit RFC 4890 te hanteren, zodat IPv6-correctheid behouden blijft zonder onnodig inbound open te zetten.

Path MTU Discovery in een oogopslag.

ICMP-richtlijn voor PMTUD

• IPv4: accepteer ICMP Type 3 Code 4 (Fragmentation Needed) alleen als onderdeel van bestaande uitgaande sessies (stateful ESTABLISHED/RELATED of equivalent).

• IPv6: accepteer ICMPv6 Type 2 (Packet Too Big) alleen als onderdeel van bestaande uitgaande sessies (stateful ESTABLISHED/RELATED of equivalent, conform de intentie van RFC 4890).

• Belangrijk: dit betekent niet dat er generiek “ICMP van internet naar LAN” opengezet moet worden; vermijd “allow any ICMP inbound” en beperk tot related/established of een gerichte allow-list op de WAN-interface.

Praktische test: voor een snelle validatie van PMTUD kun je een online PMTUD-testpagina gebruiken: 

      http://pmtud.enslaves.us/

TCP MSS clamping (optioneel, alleen voor TCP):

MSS clamping is relevant voor TCP-verkeer (bijvoorbeeld SIP/TLS of provisioning via HTTPS) en heeft geen effect op UDP (RTP en SIP/UDP). Bij een lagere WAN-MTU (zoals PPPoE 1492) kan het nodig zijn de TCP MSS te verlagen zodat TCP niet afhankelijk is van fragmentatie of PMTUD. Richtwaarde: clamp MSS op 1452 bij PPPoE/IPv4 (1492–40) en op 1432 bij PPPoE/IPv6 (1492–60).

Poorten en FQDN's

 

SIP(s)/(s)RTP: 

 Rood is gereserveerd voor toekomstig gebruik.

Platform: 

Device Provisioning:

Unity:

Webex for BroadWorks: