Post by Admin on Jul 26, 2017 9:52:29 GMT
SIP-Inspection i Brandväggar:
Vissa brandväggar kan ha något som kallas för SIP-Inspection, den kan ställa till med problem som att SIP paket ej släpps igenom och att ljudströmmen kontrolleras innan UDP strömmen släpps igenom, om kunden har den påslagen så kan det vara en god idé att stänga av den som test.SIP-ALG:
Vissa brandväggar kör med SIP-ALG (Application-Level Gateway) funktion och detta kan tyvärr leda till mer problem än önskat. En SIP-ALG kan uppmärksammas i REGISTER där intern och publik port inte stämmer överens, ALG funktionen kör med en port translation och i vissa brandväggar funkar detta väldigt dåligt och SIP paketen kan på så vis manipuleras av själva ALG funktionen. Detta kan bland annat leda till följande:
- Samtal inte kommer fram, INVITE blockas av brandväggen. - Ljudströmmen kopplas inte upp korrekt.
- Svarspaket når ej fram och man får fenomen som att det inte går att svara eller att telefonen inte slutar ringa osv.
Be kundens IT-leverantör inaktivera SIP-ALG om den fungerar dåligt, skulle brandväggen ändå inte släppa igenom SIP-trafiken, be kunden tillåta all trafik från Telavox nätrymd 80.83.208.0/20.Många brandväggar har möjlighet att logga SIP och man kan tydligt se om paket droppas i brandväggen som kommer från Telavox, det kan vara en god idé att be kundens IT-leverantör kontrollera brandväggsloggarna och se om några paket från Telavox blockeras.Intrution Prevention System:
Intrustion Prevention System (IDS ) är en applikation som monitererar nätverket för malicious activiy och policy violations. Där som denna applikation anser att något ser konstigt ut med SIP-paketen så kan det ställa till med problem om applikationen, likt SIP-ALG inte riktigt gör som man önskar.
Application Control:Application Control finns i många brandväggar och den kontrollerar alla paket samt applikationer som strömmar genom brandväggen. Denna bör inte övervaka SIP-paketen utan kan ställa till med problem där den lägger sig i sessionerna, om möjligt så ska den inaktiveras för SIP eller alternativt stänga av den. Be kund skapa en regel för alla UDP/TCP portar från det lokala nätet till Telavox 80.83.208.0/20. Denna regel ska ha en timeout på minst 3720 sekunder. Inga inkommande regler, specialare för SIP-ALG eller VoIP funktioner ska skapas utan endast det förstnämnda.
Session TTL i Brandväggar:
Många brandväggar har en meny där olika Session TTL kan ställas in, där inne kan det finnas TTL för SIP TCP och SIP UDP. Be kundens IT-leverantör ställa dem mot standard Register TTL på 3600 sekunder. Om Session TTL spökar i brandväggen så kan du få problem som att samtal bryts eller ljudströmmen stryps mitt under samtalet, oftast brukar detta ske vid samma tidpunkt in i samtalet. En liten work-around kan vara att sänka Register TTL till t ex 600 sekunder, inte lägre enligt överenskommet med Telavox. Sessionerna kopplas upp oftare och om kundens IT-leverantör inte lyckas lösa TTL problemen så kan detta vara en tillfällig fix.
DDOS Protection i HP Switchar:
Det finns en slags DDOS Protection på vissa HP Switchar av typen Pro Curve, det kan ställa till med SIP-problem och en undantag kan läggas upp i switchen.
DSTNAT och Port Forwarding:
Om kundens IT-leverantör frågar om dem kan lägga upp regler för DSTNAT av SIP-trafik så skall detta ej rekommenderas. Har kunden enbart en IP-telefon eller SIP-trunk så kan det vara en lösning på problemet. För kunder som kör med fler telefoner skulle NAT av trafiken ställa till det då alla telefoner ligger på en egen intern IP-adress och port. Detsamma gäller Port Forwarding, det skulle bli alldeles för många portar att hålla koll på.
OBS! Föreslå alltid att öppna upp allt mot Telavox nätrymd om brandväggen inte klarar av att hantera SIP korrekt.
Switchar och LAN kan påverka samtalskvalitén:
Om kunden hör av sig om dålig samtalskvalité trots att deras IT-avdelning meddelar att QoS är uppsatt korrekt i deras Firewall så kan det vara en god idé att be kunden se över sina switchar och annat i deras LAN. En dålig eller överbelastad switch kan också vara roten till problemet, en god grundregel är att börja från telefonen och jobba sig utåt. Byt först nätverkskablar, prova en annan port i switchen eller byt helt enkelt switch. Application Layer:
Vissa brandväggar kan ha något som kallas Application Layer, t ex Clavister. Problem kan uppstå om Application Layer, likt SIP-ALG inte sköter SIP-trafiken korrekt. Då kan det vara en god idé att öppna upp för vår nätrymd istället.
Vissa brandväggar kan ha något som kallas för SIP-Inspection, den kan ställa till med problem som att SIP paket ej släpps igenom och att ljudströmmen kontrolleras innan UDP strömmen släpps igenom, om kunden har den påslagen så kan det vara en god idé att stänga av den som test.SIP-ALG:
Vissa brandväggar kör med SIP-ALG (Application-Level Gateway) funktion och detta kan tyvärr leda till mer problem än önskat. En SIP-ALG kan uppmärksammas i REGISTER där intern och publik port inte stämmer överens, ALG funktionen kör med en port translation och i vissa brandväggar funkar detta väldigt dåligt och SIP paketen kan på så vis manipuleras av själva ALG funktionen. Detta kan bland annat leda till följande:
- Samtal inte kommer fram, INVITE blockas av brandväggen. - Ljudströmmen kopplas inte upp korrekt.
- Svarspaket når ej fram och man får fenomen som att det inte går att svara eller att telefonen inte slutar ringa osv.
Be kundens IT-leverantör inaktivera SIP-ALG om den fungerar dåligt, skulle brandväggen ändå inte släppa igenom SIP-trafiken, be kunden tillåta all trafik från Telavox nätrymd 80.83.208.0/20.Många brandväggar har möjlighet att logga SIP och man kan tydligt se om paket droppas i brandväggen som kommer från Telavox, det kan vara en god idé att be kundens IT-leverantör kontrollera brandväggsloggarna och se om några paket från Telavox blockeras.Intrution Prevention System:
Intrustion Prevention System (IDS ) är en applikation som monitererar nätverket för malicious activiy och policy violations. Där som denna applikation anser att något ser konstigt ut med SIP-paketen så kan det ställa till med problem om applikationen, likt SIP-ALG inte riktigt gör som man önskar.
Application Control:Application Control finns i många brandväggar och den kontrollerar alla paket samt applikationer som strömmar genom brandväggen. Denna bör inte övervaka SIP-paketen utan kan ställa till med problem där den lägger sig i sessionerna, om möjligt så ska den inaktiveras för SIP eller alternativt stänga av den. Be kund skapa en regel för alla UDP/TCP portar från det lokala nätet till Telavox 80.83.208.0/20. Denna regel ska ha en timeout på minst 3720 sekunder. Inga inkommande regler, specialare för SIP-ALG eller VoIP funktioner ska skapas utan endast det förstnämnda.
Session TTL i Brandväggar:
Många brandväggar har en meny där olika Session TTL kan ställas in, där inne kan det finnas TTL för SIP TCP och SIP UDP. Be kundens IT-leverantör ställa dem mot standard Register TTL på 3600 sekunder. Om Session TTL spökar i brandväggen så kan du få problem som att samtal bryts eller ljudströmmen stryps mitt under samtalet, oftast brukar detta ske vid samma tidpunkt in i samtalet. En liten work-around kan vara att sänka Register TTL till t ex 600 sekunder, inte lägre enligt överenskommet med Telavox. Sessionerna kopplas upp oftare och om kundens IT-leverantör inte lyckas lösa TTL problemen så kan detta vara en tillfällig fix.
DDOS Protection i HP Switchar:
Det finns en slags DDOS Protection på vissa HP Switchar av typen Pro Curve, det kan ställa till med SIP-problem och en undantag kan läggas upp i switchen.
DSTNAT och Port Forwarding:
Om kundens IT-leverantör frågar om dem kan lägga upp regler för DSTNAT av SIP-trafik så skall detta ej rekommenderas. Har kunden enbart en IP-telefon eller SIP-trunk så kan det vara en lösning på problemet. För kunder som kör med fler telefoner skulle NAT av trafiken ställa till det då alla telefoner ligger på en egen intern IP-adress och port. Detsamma gäller Port Forwarding, det skulle bli alldeles för många portar att hålla koll på.
OBS! Föreslå alltid att öppna upp allt mot Telavox nätrymd om brandväggen inte klarar av att hantera SIP korrekt.
Switchar och LAN kan påverka samtalskvalitén:
Om kunden hör av sig om dålig samtalskvalité trots att deras IT-avdelning meddelar att QoS är uppsatt korrekt i deras Firewall så kan det vara en god idé att be kunden se över sina switchar och annat i deras LAN. En dålig eller överbelastad switch kan också vara roten till problemet, en god grundregel är att börja från telefonen och jobba sig utåt. Byt först nätverkskablar, prova en annan port i switchen eller byt helt enkelt switch. Application Layer:
Vissa brandväggar kan ha något som kallas Application Layer, t ex Clavister. Problem kan uppstå om Application Layer, likt SIP-ALG inte sköter SIP-trafiken korrekt. Då kan det vara en god idé att öppna upp för vår nätrymd istället.