Sophos Firewall VoIP-problemen met SIP en RTP oplossen

VoIP-problemen achter een Sophos Firewall hebben vaak een diffuus effect: telefoons melden zich niet aan, gesprekken worden afgebroken, er gaat over zonder geluid of spraak is maar in één richting te horen. In de praktijk ligt de oorzaak zelden bij een enkele schakelaar. SIP-signalering, RTP-mediastream, NAT, firewallregels, UDP-time-outs of routing werken meestal samen.

Dit artikel beschrijft VoIP-probleemoplossing op Sophos Firewall als een gestructureerd proces. Bekende snelle oplossingen, zoals SIP Helper uitschakelen of een UDP-time-out verhogen, zijn slechts gecontroleerde tests. Bepaal eerst het pakketpad, de daadwerkelijk gebruikte firewall- en NAT-regels en analyseer SIP en RTP afzonderlijk.

SIP, RTP en symptomen begrijpen

Wat er door de firewall loopt bij VoIP

VoIP bestaat grofweg uit twee delen:

• SIP: regelt de registratie, het opzetten van gesprekken, het wissen van gesprekken en het onderhandelen over mediaparameters. Typische fouten zijn onder meer een mislukte registratie, het niet tot stand komen van oproepen of het weigeren van SIP-dialogen door de provider.
• RTP: transporteert de spraakgegevens tijdens het gesprek. Typische fouten zijn onder meer ontbrekende audio, eenzijdige audio of audio die na korte tijd afbreekt.

SIP loopt vaak via UDP of TCP 5060, terwijl gecodeerde SIP vaak over 5061 loopt. Maar dat is geen wet. Veel providers gebruiken hun eigen poorten, hun eigen proxyservers of aanvullende vereisten voor NAT-keepalives.

RTP maakt doorgaans gebruik van UDP-poortbereiken die zijn gespecificeerd door de provider, het telefoonsysteem of de eindapparaten. Voor een zuivere analyse heeft u de specifieke SIP-servers, RTP-poortbereiken en transportprotocollen van de provider of de PBX-documentatie nodig.

Sophos Firewall ondersteunt naast SIP ook H.323. Dit runbook richt zich op SIP-signalering en RTP. Als het telefoonsysteem daadwerkelijk H.323 gebruikt, moeten de H.323-service en de H.323 Helper afzonderlijk worden gecontroleerd; SIP Helper-instellingen zijn dan niet automatisch het juiste aangrijpingspunt.

Classificeer de symptomen correct

Voordat u wijzigingen aanbrengt, moet u het symptoom zo nauwkeurig mogelijk classificeren.

• Registratie mislukt: Controleer DNS, routing, firewallregel, NAT, providerreferenties of SIP-transport.
• Gesprek maakt geen verbinding: Controleer SIP-signalering, firewallregel, Application Control en mogelijke providerblokkeringen.
• Oproep werkt maar geen audio: Controleer RTP-poortbereik, NAT, retourroute, SD-WAN en SIP Helper.
• Audio is slechts in één richting hoorbaar: Controleer RTP-retourpad, NAT, routing, VPN en SD-WAN.
• Het gesprek wordt na 30, 60 of 120 seconden afgebroken: Controleer de UDP-time-out, NAT keepalive, sessievernieuwing en verwachtingen van de provider.
• Alleen inkomende oproepen werken niet: Controleer DNAT, firewallregel, bronnetwerken van de provider en delen van PBX-poorten.
• Slechts één WAN-lijn veroorzaakt problemen: Controleer de SD-WAN-route, het antwoordpad, de gateway en de IP-binding van de provider.

Deze classificatie voorkomt dat u de SIP-instellingen wijzigt, ook al ligt het werkelijke probleem in het RTP-retourpad of een SD-WAN-route.

De uitgangssituatie vastleggen vóór wijzigingen

Voordat u CLI-wijzigingen aanbrengt, moet u de huidige status documenteren:

• Om welke telefoons, PBX of SBC gaat het?
• Melden eindapparaten zich rechtstreeks aan bij de provider of verloopt alles via een interne telefooncentrale?
• Welke SIP-servers en RTP-poortbereiken noemt de provider?
• Welke firewallregel verwerkt het VoIP-verkeer?
• Is Log firewall traffic ingeschakeld in deze regel?
• Welke NAT-regel is van toepassing op uitgaand en inkomend VoIP-verkeer?
• Zijn er meerdere WAN-lijnen, SD-WAN-routes of routegebaseerde VPN’s?
• Is het probleem zichtbaar geworden na een firmware-upgrade, providerwissel of PBX-update?

Firewallregels op Sophos Firewall testen helpt bij de regelanalyse. Voor de werkelijke pakketstroom is Packet Capture in WebAdmin meestal informatiever dan alleen een Policy Test. Wijzig globale CLI-waarden pas wanneer deze baseline en een reproduceerbare testoproep beschikbaar zijn.

Pakketpad, routing en kwaliteit controleren

Controleer firewallregels en NAT

NAT is vaak betrokken bij VoIP-problemen. De Sophos Firewall moet niet alleen SIP toestaan, maar ook de bijbehorende RTP-streams in beide richtingen correct vertalen en retourneren.

Deze punten zijn meestal relevant voor uitgaande telefoons of een interne PBX:

• passende firewallregel van de VoIP-zone of PBX-zone naar WAN
• passende SNAT- of MASQ-regel
• Inloggen op de firewallregel
• geen regel die te breed is of verkeerd gepositioneerd boven de VoIP-regel
• geen onverwachte Application Control-, IPS- of webfiltering op dit verkeer

Of een inkomende SIP-trunk DNAT nodig heeft, hangt af van het ontwerp van de provider. Op registratie gebaseerde trunks kunnen de bestaande uitgaande sessie gebruiken. Trunks die rechtstreeks op een openbaar adres worden afgeleverd, of gepubliceerde telefoonsystemen, hebben doorgaans een nauw afgebakende DNAT-regel nodig. De eisen van de provider of SBC-beheerder zijn bepalend.

Als DNAT nodig is, controleer dan ook deze punten:

• DNAT naar de interne PBX of SBC
• Firewallregel met geschikte doelzone en doelnetwerk
• Beperking tot bronnetwerken van providers, indien mogelijk
• alleen vereiste SIP- en RTP-poorten
• Logging en Packet Capture voor testen

Een NAT-regel staat geen verkeer toe, maar vertaalt alleen adressen of poorten. De aansluitingen worden uitgelegd in NAT op Sophos Firewall begrijpen. Als een PBX via internet bereikbaar moet zijn, is Publiceerserver via DNAT de betere basis voor de daadwerkelijke publicatie.

Analyseer RTP in beide richtingen

Als de oproep tot stand is gebracht maar er geen audio is, is SIP meestal niet langer het grootste probleem. Dan moet je controleren of RTP in beide richtingen stroomt.

Typisch proces:

1. Let op het RTP-poortbereik van de provider of de PBX.
2. Beperk Packet Capture tot het IP-adres van de PBX of telefoon en het RTP-poortbereik. Neem beide richtingen mee: het interne apparaat is afhankelijk van de pakketrichting de bron of de bestemming.
3. Voer een testoproep uit.
4. Controleer of UDP-pakketten van het interne apparaat naar de provider zichtbaar zijn.
5. Controleer of UDP-pakketten terugkeren van de provider.
6. Vergelijk NAT ID, Rule ID, In interface, Out interface en Gateway ID. Controleer bij ontbrekende pakketten ook Status en Reason; Violation duidt op een verworpen pakketstroom.

Als RTP alleen uitgaand zichtbaar is en niets terugkomt, kan het probleem bij de provider, het retourpad, NAT of een upstream-apparaat liggen. Als RTP terugkomt maar niet naar de PBX wordt doorgestuurd, zijn de firewallregel, DNAT, routing of zonetoewijzing waarschijnlijker.

Voor nauwkeurigere opnames of PCAP-export kan tcpdump via SSH nuttig zijn. Het proces wordt beschreven in Sophos Firewall tcpdump gebruiken voor logs en analyse.

SD-WAN, VPN en meerdere WAN-lijnen

VoIP is gevoelig voor asymmetrische paden. Als SIP over een WAN-lijn loopt, maar RTP over een andere lijn terugkeert of een op route gebaseerde VPN anders wordt gerouteerd, ontstaan ​​typische fouten zoals eenzijdige audio.

Een bug die is opgelost in SFOS 22.0 MR1 toont de typische verbinding: na een upgrade naar SFOS 22.0 GA kon VoIP-audio slechts in één richting werken via routegebaseerde VPN met SD-WAN-routering. In de praktijk betekent dit: SD-WAN moet altijd worden aangevinkt bij gebruik van VoIP via VPN of meerdere WAN-paden.

Belangrijke controlepunten:

• Heeft een SD-WAN-route toegang tot VoIP-verkeer?
• Worden SIP en RTP over dezelfde verwachte WAN-lijn gerouteerd?
• Zijn er specificaties van de provider met betrekking tot het bron-IP-adres of het openbare afzenderadres?
• Wordt er een routegebaseerde VPN-route met een XFRM-interface gebruikt?
• Komen retourroutes en NAT overeen met het gekozen pad?
• Toont Packet Capture verschillende gateways of interfaces voor heen- en teruggaande richtingen?

Voor Sophos-specifieke SD-WAN-opties past SD-WAN-routering van antwoordpakketten en systeemverkeer. Sophos Firewall IPsec Troubleshooting helpt ook bij IPsec-verbindingen.

Verkeersvorming voor VoIP

Traffic shaping kan VoIP stabiliseren wanneer lijnen krap zijn of grote uploads spraakpakketten verdringen. Het lost echter geen onjuiste NAT-regels, ontbrekende RTP-poorten en onjuiste retourroutes op.

Traffic shaping is vooral nuttig als:

• VoIP wordt slechter als de internetlijn onder belasting staat,
• Uploads of back-ups verstoren gesprekken,
• meerdere applicaties gebruiken dezelfde lijn,
• VoIP moet specifiek prioriteit krijgen.

De configuratie wordt beschreven in Application Traffic Shaping op Sophos Firewall. Voor VoIP moet u niet alleen na de implementatie snelheidstests controleren, maar ook echte testoproepen uitvoeren bij gelijktijdige belasting.

SIP Helper, UDP Timeout en DoS gecontroleerd testen

De volgende instellingen zijn niet beperkt tot één VoIP-regel. Test ze daarom pas nadat de oorzaak is afgebakend, met een gedocumenteerde baseline, een onderhoudsvenster en een duidelijk rollback-plan.

Controleer SIP-helper

De SIP Helper, ook SIP ALG genoemd, herkent standaard SIP op UDP 5060, vertaalt lokale adressen in de SIP-header en opent dynamisch het verwachte spraakkanaal. Controleer aan de hand van de werkelijke callflow of deze ingrepen passen bij het ontwerp van de provider en PBX. Sommige PBX-leveranciers eisen expliciet dat SIP ALG uitstaat; andere omgevingen hebben de Helper nodig.

Daarom is SIP Helper een nuttig testpunt, maar geen algemene permanente oplossing. Sophos documenteert de SIP-module als standaard ingeschakeld. Wijzigingen met load of unload blijven ook na een herstart behouden.

De opdrachten worden via SSH op Sophos Firewall uitgevoerd in 4. Device Console. Sta SSH-toegang alleen toe vanaf vertrouwde netwerken. De basis staat in Via SSH verbinden met Sophos Firewall.

Toon de actuele status voor en na elke wijziging met een alleen-lezen opdracht:

system system_modules show

Documenteer de uitvoer voor de vermelding sip. Zo blijft duidelijk of de Helper vóór de test was geladen en welke status na de rollback wordt verwacht.

SIP-module uitschakelen:

system system_modules sip unload

SIP-module weer inschakelen:

system system_modules sip load

⚠️ Deze wijziging moet worden doorgevoerd in een onderhoudsvenster of met duidelijk gedefinieerde tests. Na het uit- of inschakelen moeten de aanmelding, uitgaande oproepen, inkomende oproepen en audio in beide richtingen worden gecontroleerd.

Helpt de wijziging niet, herstel dan exact de vorige toestand:

• Was sip unloaded, gebruik dan system system_modules sip unload.
• Was de module op de standaard UDP-poort 5060 geladen, gebruik dan system system_modules sip load.
• Was de module op een aangepaste poort geladen, gebruik dan system system_modules sip load ports <previous_custom_port>. <previous_custom_port> moet de vóór de wijziging vastgelegde poort zijn.

Begin de test niet als een eerder gebruikte aangepaste poort niet met zekerheid bekend is. Een gewone load is dan geen exacte rollback, omdat die de Helper op de standaardpoort laadt.

Als de provider een aangepaste SIP-signaleringspoort gebruikt in plaats van UDP 5060, kan de Helper met precies die poort worden geladen:

system system_modules sip load ports <custom_port>

Vervang <custom_port> door de SIP-poort die de provider of PBX-fabrikant opgeeft, niet door een volledig RTP-poortbereik. De SIP Helper ondersteunt mediapoorten van 1024 tot 65535. Ligt een gebruikte mediapoort buiten dit bereik, dan kan de firewall het verkeer weggooien en verschijnt Invalid Traffic in het eventlogboek.

SIP via TCP heeft nog een beperking: de Helper ondersteunt geen SIP- of SDP-bericht dat over meerdere pakketten is verdeeld. Als Packet Capture precies dit patroon toont, moet het transport met de provider en PBX-fabrikant worden afgestemd. Overschakelen op SIP via UDP is alleen zinvol als beide kanten dit ondersteunen.

Controleer en pas de UDP-time-out aan

VoIP maakt vaak gebruik van UDP. Als NAT- of sessie-items te vroeg verlopen, kan het lijken alsof een registratie werkt, maar gesprekken vallen weg of inkomende oproepen bereiken de PBX niet betrouwbaar.

Sophos onderscheidt twee globale waarden:

• udp-timeout geldt voor UDP-verbindingen die nog niet als bidirectionele stream zijn herkend.
• udp-timeout-stream geldt voor gevestigde UDP-streams waarbij beide eindpunten verkeer via dezelfde poort tussen netwerksegmenten hebben verzonden.

In SFOS 22 accepteren beide waarden 30 tot 3600 seconden. Toon de huidige Advanced Firewall-waarden in Device Console:

show advanced-firewall

De actuele SFOS 22-help noemt 60 seconden als standaardwaarde voor UDP Timeout Stream en beveelt voor VoIP 150 seconden aan. De werkelijk weergegeven waarde en de specificatie van de provider blijven echter bepalend. Als Packet Capture en het afbreekmoment wijzen op een te korte stream-time-out, kan de gedocumenteerde waarde gecontroleerd worden getest:

set advanced-firewall udp-timeout-stream 150

Voer direct daarna opnieuw show advanced-firewall uit. Plaats dezelfde testoproep pas wanneer UDP Timeout Stream : 150 wordt weergegeven. Na de rollback moet dezelfde controle de eerder vastgelegde waarde tonen.

⚠️ udp-timeout-stream is geen optie van één VoIP-regel. De instelling beïnvloedt alle overeenkomende UDP-streams. Verhoog de waarde niet op goed geluk of willekeurig. Noteer vóór de test de oude waarde uit show advanced-firewall en herstel die met dezelfde set-opdracht als de test niet helpt.

Toonde de baseline bijvoorbeeld UDP Timeout Stream : 60, dan is de exacte rollback:

set advanced-firewall udp-timeout-stream 60

De waarde 60 is alleen voor die baseline juist. Toonde de firewall een andere waarde, neem die dan ongewijzigd over in de rollback-opdracht.

Als de provider of het telefoonsysteem NAT keepalive ondersteunt, moet deze instelling ook worden gecontroleerd. Een schone keepalive aan de PBX- of providerzijde is vaak beter dan een zeer hoge globale time-outwaarde.

Drempelwaarden voor UDP flood controleren

VoIP genereert veel UDP-pakketten. Als de drempelwaarden onder Intrusion prevention > DoS & spoof protection > DoS settings te laag zijn, kan de firewall legitiem SIP- of RTP-verkeer als UDP flood weggooien. Documenteer vóór een wijziging de actuele waarden voor Packet rate, Burst rate en Apply flag, evenals de drop counters.

Sophos noemt het tijdelijk verwijderen van de Apply flag voor UDP flood als diagnostische test. Dit verlaagt tijdens de test de DoS-bescherming en hoort daarom thuis in een onderhoudsvenster met een nauw afgebakende testcase. Als VoIP hierdoor verbetert, worden Packet rate en Burst rate aangepast aan de gemeten legitieme belasting en wordt Apply flag opnieuw ingesteld. Blijft het probleem ongewijzigd, herstel dan onmiddellijk de uitgangssituatie.

Een gerichte uitzondering voor bekende hosts of poorten kan veiliger zijn dan een globale uitschakeling. Spoof Protection en DoS-bescherming op Sophos Firewall legt uit hoe drempelwaarden en DoS bypass rules samenwerken. De bescherming mag na de test niet uitgeschakeld blijven.

H.323, VPN en conntrack als bijzondere gevallen

De volgende Sophos-aanwijzingen passen alleen bij een nauwkeurig bevestigd probleem. Ze wijzigen globale helper-, IPS- of VPN-instellingen of een actieve sessie en zijn geen algemene VoIP-tuning.

Bij H.323 kan de geladen Helper de oorzaak zijn als audio of video wegvalt of slechts in één richting werkt ondanks correcte firewall- en DNAT-regels. Documenteer eerst de beginsituatie met system system_modules show. Sophos noemt deze gecontroleerde test:

system system_modules h323 unload

Lees daarna de modulestatus opnieuw en herhaal dezelfde testoproep met audio of video in beide richtingen. Was h323 al niet geladen, dan heeft de opdracht geen nieuwe teststatus gecreëerd.

Was de module voor de test geladen en blijft het probleem bestaan, gebruik dan als rollback:

system system_modules h323 load

Het door Sophos daarnaast genoemde ontwerp met een transparante subnetgateway en proxy ARP is een ontwerpwijziging en geen universele volgende stap. Alleen het aangetoonde ARP- en routingpad bepaalt of Proxy ARP op Sophos Firewall bij deze topologie past.

Voor VoIP-problemen via een site-to-site-VPN of met IPS noemt Sophos twee globale instellingen. sip_preproc scant SIP-sessies op netwerkaanvallen en is standaard ingeschakeld. conn-remove-tunnel-up bepaalt of verbindingen bij het opkomen van een IPsec-tunnel worden verwijderd.

Correleer vóór een test het afbreken van het gesprek met een tunnelgebeurtenis. Lees de aanvankelijke IPS-waarde in Device Console:

show ips-settings

Als sip_preproc duidelijk als enable wordt weergegeven, kunt u de door Sophos gedocumenteerde test in een onderhoudsvenster uitvoeren:

set ips sip_preproc disable

Voer show ips-settings opnieuw uit en herhaal dezelfde testoproep. Uitschakelen vermindert de SIP-aanvalsinspectie wereldwijd. Helpt de test niet, dan is de exacte rollback voor de eerder afgelezen waarde enable: set ips sip_preproc enable; daarna moet show ips-settings weer enable tonen. Wijzig niets als de beginwaarde al disable is of niet eenduidig kan worden afgelezen.

Voor hetzelfde probleem noemt Sophos ook set vpn conn-remove-tunnel-up disable. De actuele SFOS 22-CLI-help documenteert echter geen bijbehorende leesopdracht en geen universele beginwaarde. Wijzig deze instelling daarom niet uitsluitend op basis van dit artikel. Sophos Support moet eerst de werkelijke waarde en de exacte rollback voor de geïnstalleerde build bevestigen. Globale VPN-instellingen veilig gebruiken legt het effect van de instelling uit.

Als een telefoon zich bij de PBX registreert met het firewall-IP in plaats van met het eigen adres, vergelijk dan eerst Log Viewer, Firewall Rule ID, NAT Rule ID en de helperstatus tussen een werkende en een getroffen telefoon. Een normale nieuwe telefoon- of PBX-sessie starten is veiliger dan conntrack aanpassen. Blijft een aantoonbaar onjuiste TCP-vermelding bestaan, dan noemt Sophos als laatste gerichte stap in de Advanced Shell:

conntrack -D --src <IP_ADDRESS_OF_PHONE> --dst <IP_ADDRESS_OF_PBX> -p tcp

Vervang de plaatshouders alleen door de geverifieerde adressen. Het commando verwijdert de bijbehorende actieve TCP-sessie en onderbreekt deze onmiddellijk; verbreed het niet en pas het niet aan voor UDP. Live Connections op Sophos Firewall legt uit hoe men de flow eerst onder Diagnostics > Connection list afbakent.

Laat de getroffen telefoon daarna opnieuw registreren. De test is pas geslaagd als Log Viewer het eigen IP-adres van de telefoon toont en een nieuwe testoproep werkt. Verschijnt het firewall-IP opnieuw, herhaal de verwijderopdracht dan niet; onderzoek NAT en het Helper-gedrag samen met Sophos Support.

Probleemoplossing en bewijsmateriaal

Praktische probleemoplossingsstroom

1. Documentsymptomen: registratie, oproepconfiguratie, audio, afbreektijd, richting.
2. Verzamel providergegevens: SIP-server, transport, RTP-poortbereik, NAT-vereisten.
3. Identificeer de firewallregel en NAT-regel.
4. Activeer het inloggen op de betreffende firewallregel.
5. Open Log Viewer en Packet Capture tijdens een testoproep.
6. Controleer of de SIP-signalering in beide richtingen loopt.
7. Controleer of RTP in beide richtingen werkt.
8. Als er meerdere WAN-lijnen zijn, controleer dan SD-WAN en retourpad.
9. Controleer de status van SIP Helper, test wijzigingen gericht en documenteer de resultaten.
10. Pas een UDP-time-out alleen bewust aan nadat de oude waarde is gedocumenteerd.
11. Controleer bij UDP-drops of kwaliteitsproblemen onder belasting de drempelwaarden voor UDP flood op een gecontroleerde manier.
12. Test na elke wijziging de registratie, uitgaande oproepen, inkomende oproepen en audio in beide richtingen.

Als er meerdere wijzigingen tegelijkertijd worden aangebracht, is de daaropvolgende oorzaak moeilijk te begrijpen. Eén test per wijziging is beter.

Verzamel bewijsmateriaal tijdens een testoproep

Een VoIP-test heeft alleen zin als de tijd, richting en pakketstroom overeenkomen. Vooral in providergevallen is de verklaring “Audio werkt niet” niet voldoende. Je hebt een kleine, reproduceerbare testcase nodig.

• Exacte tijd met tijdzone: Log Viewer, Packet Capture en providerlogboeken kunnen later eenvoudig worden vergeleken.
• Oproeprichting: inkomende oproepen, uitgaande oproepen en interne doorschakeling worden niet gemengd.
• Telefoonnummers of toestelnummers: Providers en PBX’s vinden het specifieke gesprek sneller.
• Intern IP-adres van PBX of telefoon: Packet Capture kan nauwkeurig worden gefilterd.
• Provider SIP-server en RTP-poortbereik: SIP- en RTP-analyse blijven gescheiden.
• Rule ID, NAT ID, In interface en Out interface: u kunt zien welke regel en welk pad daadwerkelijk zijn gebruikt.
• Eventlogboek en DoS-counters: Invalid Traffic of oplopende UDP-flood-drops helpen het Helper-poortbereik en de DoS-drempelwaarden af te bakenen.
• Resultaat per test: Registratie, belsignaal, oproepopbouw, audio links/rechts en beëindigingstijd blijven traceerbaar.

In het geval van sporadische fouten moet u ook een back-up maken van de relevante logs voordat deze worden overschreven. Voor een schoon houtpakket past Sophos Firewall logs voor support en analyse veiligstellen. Welk logbestand bij welke dienst hoort, staat beschreven in Sophos Firewall Troubleshooting: services en logs.

Veelvoorkomende fouten

• Alleen SIP-poort ingeschakeld, RTP-poortbereik vergeten: Het gesprek wordt opgezet, maar er ontbreekt audio.
• NAT-regel bestaat, maar geen overeenkomende firewallregel: Verkeer wordt vertaald maar niet toegestaan.
• Firewallregel zonder loggen: Probleemoplossing in Log Viewer blijft blind.
• SIP Helper gedeactiveerd of geactiveerd over de hele linie: Het probleem wordt willekeurig verplaatst in plaats van geanalyseerd.
• Aangepaste SIP-poort verward met het RTP-poortbereik: De Helper wordt op de verkeerde signaleringspoort geladen.
• UDP-time-out zeer hoog ingesteld: Globale UDP-sessies blijven onnodig lang open.
• UDP-flood-bescherming te streng of permanent uitgeschakeld: Legitieme spraakpakketten worden weggegooid of de bescherming blijft na de test onnodig beperkt.
• Meerdere WAN-paden zonder een duidelijke SD-WAN-regel: Eenrichtingsaudio of afgewezen verkeer door de provider wordt waarschijnlijker.
• Bronnetwerken van providers niet beperkt: De SIP-service is onnodig breed toegankelijk vanaf internet.
• Traffic shaping opgevat als vervanging voor NAT/routing: De spraakkwaliteit blijft slecht omdat de oorzaak elders ligt.

Wijzigingen gecontroleerd terugdraaien

Bij VoIP-wijzigingen moet altijd duidelijk zijn hoe ze worden teruggedraaid:

• oude waarden van udp-timeout en udp-timeout-stream gedocumenteerd als ze worden gewijzigd
• SIP-test met load, unload of een aangepaste poort en de gewenste eindstatus gedocumenteerd
• beginstatus van H.323 en sip_preproc gedocumenteerd en na een mislukte bijzondere test hersteld; conn-remove-tunnel-up ongewijzigd gelaten zonder bevestigde beginwaarde
• oorspronkelijke UDP-flood-drempelwaarden en Apply flags gedocumenteerd en na de test hersteld
• gewijzigde firewall- en NAT-regels vastgelegd met datum en reden
• testoproepen geregistreerd met richting en tijd
• Packet Capture of relevante logboeken bewaard voor supportcases

Als de verandering niet helpt, mag deze niet als een toevallige erfenis worden achtergelaten. Vooral VoIP-oplossingen worden anders later moeilijk te begrijpen.

Controlelijst

• Provider SIP- en RTP-informatie is beschikbaar.
• Firewallregel voor VoIP is geïdentificeerd en loggen is actief.
• NAT-regel komt overeen met de richting van het verkeer.
• SIP en RTP werden afzonderlijk gecontroleerd.
• Packet Capture toont de heen- en terugrichting.
• De status van SIP Helper is vóór en na de gerichte test gecontroleerd.
• Een aangepaste SIP-poort komt overeen met de specificatie van de provider of PBX en wordt niet verward met het RTP-poortbereik.
• UDP-time-out is alleen gewijzigd met een gedocumenteerde beginwaarde.
• De drempelwaarden voor UDP flood en de DoS-bescherming zijn na de test in een veilige eindtoestand gebracht.
• SD-WAN, VPN en meerdere WAN-lijnen zijn gecontroleerd.
• Traffic shaping wordt alleen gebruikt voor kwaliteitscontrole, niet als vervanging voor routing of NAT-correcties.

Veelgestelde vragen