Tag-arkiv: Router

firewall

SIP gennem firewall

firewall
Billede af purpleslog

Begreber

SIP UA (User Agent) er en enhed som kan telefonere via SIP protokollen. Den har både Server og Client funktioner, derfor valgte man udtrykket User Agent.
ATA (Analog Telephone Adapter) er er SIP UA, hvor man kan tilkoble en analogtelefon. ATA’en kan være en selvstændig enhed på nettet, men den kan også være indbygget i en router.
IP-telefon er en SIP UA med hele telefondelen indbygget
SoftPhone er en IP-telefon man kan installere på en computer

TCP/IP konfiguration

For at kunne kommunikere TCP/IP, så har alle enheder behov for følgende parametre, som måske kan hentes automatisk via DHCP:

  • Egen IP adresse
  • Netmask
  • Default Gateway adresse
  • DNS 1 – Navneserver 1
  • DNS 2 – Navneserver 2

Det er en forudsætning i det følgende, at der ikke er fejl i at blive koblet op på nettet.
Har man to routere efter hinanden, så må der ikke her være to subnet med ens IP adresseområde, eller med overlap i adresser. Det vil give problemer i at kommunikere mellem internettet og det lokalnet, der ligger fjernest fra internettet.

Offentlig IP / Privat IP

Den mindst komplicerede måde at køre SIP er en SIP UA der kører direkte på en offentlig IP adresse, fx hvis det er en SIP ATA i routeren, og man har fast offentlig IP fra internetudbyderen, for her kræves ingen særlig foranstaltning, og her behøver man ikke at spekulere på porte. Det der gør løsningen mindst kompliceret er, dels den offentlige IP adresse, og dels at SIP UA’en kører direkte med denne adresse. Det er også med offentlig IP man kan spare mest på datatrafik over internettet, bl.a. fordi SIP datapakkerne kan fylde mindre, og fordi der ikke er behov for tomgangstrafik. Nogle kalder også offentlig IP adresse for Global IP, det er adresser man kan adressere direkte på internettet.

Vi har alle en offentlig IP adresse, men eventuelt er det en vi deler med andre, og deler vi den med andre, så er det at vore porte måske kan drille. Til fejlsøgning får vi derfor brug for at vide noget om vores IP adresse.
Ved opslag på myip.dk kan man se, hvilken offentlig IP man har. Om man deler den offentlige IP med andet eller andre kan afgøres ved at se, hvilken IP adresse SIP UA’en har. Hvis man deler den, så kaldes adressen man har for privat IP, og privat IP adresser ligger normalt indenfor følgende tre områder:

  • 10.0.0.0 – 10.255.255.255
  • 172.16.0.0 – 172.31.255.255
  • 192.168.0.0 – 192.168.255.255

Drejer det sig om en SoftPhone, da kan man sammenligne den offentlige IP adresse med computerens IP adresse. Kører man med Windows 2000, NT eller XP, så kan man finde IP adressen den har ved i DOS at skrive kommandoen ipconfig /all. Kører man med Windows 95 eller 98, da er kommandoen winipcfg. Ellers, hvis det drejer sig om en IP-telefon, eller en ATA, for at finde IP adressen den har, da følg dokumentationen for denne.
Denne løsning (NAT), hvor én IP adresse på routerens WAN side deles af mange IP adresser på routerens LAN (lokalnet) det fungerer også som en del af routerens firewall, og det er her vi måske kan have problemer. NAT står for Network Address Translation – omsætningen fra én IP til mange privat IP.

Traversal for NAT

NAT Traversal er en fælles betegnelse for løsninger til at komme igennem NAT firewall. Alterantive er fx

  • STUN sammen med NAT traversal trafik
  • Outbound SIP Proxy
  • SIP-path-through routere

Man møder også benævnelser som SIP gateway til NAT. Det er ofte løsninger man kan adressere som Outbound SIP proxy, eller løsninger der transparent lader SIP slippe igennem NAT.

STUN og NAT traversal trafik

Ligger SIP UA’en i routeren, så har routeren normalt indbygget adgang igennem egen NAT firewall. Man har derfor ikke i det tilfælde brug for STUN og NAT traversal trafik for at komme igennem firewallen. Men der kunne måske være endnu en router med NAT foran, hvor STUN og NAT traversal trafik kunne være nødvendigt, en løsning, hvor routeren, vi har med at gøre her, kører på privat IP.
For de fleste IP-telefoner eller ATA’er sker forbindelsen til internettet via en router. I mange tilfælde skabes den rette forbindelse ved hjælp af STUN og NAT traversal trafik.
Vi vil også forsøge at afdække undtagelser og specielle situationer.

STUN

STUN er et værktøj til at afklare port forholdene i en NAT Firewall router. Foruden at afklare firewall type, så finder STUN den lokale IP adresse og den offentlige IP adresse, og den finder frem til hvilke porte der skal adresseres, når der sendes fra internettet. STUN sikrer at informationen lægges med i SIP datapakkerne. Symmetrisk NAT er speciel, derfor er det ikke nok med STUN, og (ud over NAT traversal trafikken) STUN kan ikke forliges med alternative traversal løsninger. Det kommer vi nærmere ind på senere. Med STUN aktiveret så vil STUN ofte notere, hvilken type NAT firewall man har, også om det er symmetrisk NAT. Fx vil Grandstream produkterne vise det øverst på Status siden, og Sipura produkterne, samt X-Lite, vil vise det først i diagnostic loggen. Men man får kun informationen, når man har STUN aktiveret. I forbindelse med fejlsøgning af SIP er det godt at vide, hvilken type NAT man eventuel har med at gøre, og det ændrer sig jo ikke, selv om man bagefter igen frakoble STUN. Hvordan man med Sipura laver log er forklaret i Sipura FAQ. Se også om STUN og NAT-typer hos voip-info.org.
Har man SIP UA direkte mod fast offentlig IP, da er der ikke behov for STUN, men her skader det heller ikke at den er aktiveret. At køre med STUN koster kun lidt ekstra trafik på inetrnettet.
Har man en SIP UA, der kører mod flere forskellige SIP proxy servere, så kunne man måske spekulere over, hvilken STUN server man skal vælge. De er næsten ens, så bare vælg en af dem.
I de fleste UA’er aktiverer man STUN ved i et konfigureringsfelt, at lægge adressen på STUN serveren, fx stun.musimi.dk. I nogle UA’er, fx Sipura, skal man så også vælge STUN Enable: yes.

NAT traversal trafik

De fleste SIP løsninger kan holde vejen til internettet åben ved at have noget tomgangstrafik kørende, så routeren ikke timer ud og lukker de åbne porte igen. Tomgangstrafikken kaldes ofte for NAT traversal traffic, eller NAT Keep Alive. NAT traversal trafik er ikke løsningen for routere af symmetrisk NAT-typen.

Man kan anvende NAT traversal trafik sammen med STUN, men også i andre sammenhæng, hvor portene ellers timer ud og lukker.

Har man SIP UA direkte mod fast offentlig IP, da er der ikke behov for NAT traversal trafikken, det skader heller ikke at den er aktiveret, men det koster en del ekstra trafik på internettet.
Noget specielt for Grandstream produkterne er at man tilkobler NAT traversal trafik ved at vælge NAT Traversal: yes. Det lyder sådan set logisk nok, men derefter er der et felt, hvor man noterer adressen på STUN serveren. Idéen er sandsynligvis, at man ofte anvender begge dele sammen, men lader man feltet for STUN være tom, og stadig vælger NAT Traversal: yes, så kører man med NAT traversal uden brug af STUN.

Fjernanalyse af firewall forhold – “Server Side NAT Traversal”

Nogle udbydere af IP-telefoni har en løsning som analyserer de datapakker man sender til serveren, og kompenserer, hvis det er nødvendig. Kører man mod en sådan løsning, så behøver man normalt ikke selv at køre med STUN eller NAT traversal trafik, man kan betragte det, som en alternativ løsning, der blot ligger på serveren. Hvis det her er nødvendig med tomgangstrafikken, så vil serveren generere dette. Normalt er en sådan løsning så intelligent, at bruger man selv STUN og NAT traversal trafik, så vil serveren ikke også generere tomgangstrafikken. Er der problemer med porte, fx lyden, så prøv at slå din egen STUN fra. – Fx findes dette ofte i SER SIP server løsninger. Et eksempel herhjemme er Musimi.

Outbound SIP Proxy

Outbound – her med betydningen vejen ud. Outbound SIP proxy er en NAT traversal løsning, som hvis den findes, oftest etableres i forbindelse med en fælles firewall mellem intranettet og internettet. Udtrykket proxy betyder stedfortræder, Outbound SIP proxyen er SIP UA’ernes stedfortræder mod internettet og omvendt. Den sikrer en korrekt omsætning af IP adresser og porte mod de to net, og skaber forbindelsen udenom firewallen. Ligeledes, som for andre SIP traveral løsninger, anvendes ikke STUN sammen med Outbound proxy.
En Outbound Proxy på internette, fx sammen med SIP proxy serveren, vil ofte være en omvej for kommunikationen, og de fleste udbydere af IP-telefoni har ikke nogen Outbound SIP proxy server. En sådan løsning kan sammenlignes med “Server Side NAT Traversal”, hvor man blot her specifiserer Outbound SIP proxyen for at aktivere funktionen. Sandsynligvis vil en Outbound SIP proxy på internettet også altid tage RTP media stream (lyden) ind over sig. – FWD er et eksempel, hvor de har Outbound SIP proxy.
Outbound SIP proxy kan sandsynligvis ikke klare symmetrisk NAT, med mindre det er en løsning bygget sammen med pågældende firewall.
Ofte aktiverer man brugen ved i sin SIP konfiguration, at lægge adressen i feltet for Outbound SIP proxy.

SIP-path-through routere

Nogle routere har en NAT traversal, så data til telefonien transparent slipper igennem routerens NAT firewall, men det er ikke altid at løsningen er implementeret fejlfrit, man må i det tilfælde forsøge om problemerne rettes ved at hente seneste firmware version hos producenten, eller forsøge at slå funktionen fra.
Denne særlige løsning til SIP kaldes ofte for SIP-path-through, SIP-aware, eller Application Level Gateway (ALG) for SIP through NAT. Tilsvarende løsning, med transparent SIP-path-through, findes også til de store routere, fx hvor internetudbyderen kører med privat IP, dem behøver vi normalt ikke at tage speciel hensyn til. SIP er en applikation-layer protokol, dvs. at der på applikationsniveau også ligger adresseinformationer, og det er det SIP-path-through forsøger at tage højde for, så det fra internettet ser ud som om routeren selv er SIP UA’en. Med dette aktiv i routeren er det ikke sikkert at man kan lave en effektiv port forwarding for sin SIP, og det burde så heller ikke være nødvendig, når SIP-path-through virker. Hvis man har en router med SIP-path-through, så må man ikke bruge STUN, fordi SIP-path-through og STUN konflikter, og der er ikke behov for NAT traversal trafik.

Der har været mange forskellige problemer forårsaget af SIP-path-through, ofte at det virker, men er ustabilt, fx i Zyxel 650R-31 routeren.

Nogle SIP-path-through routere kan også adresseres som Outbound SIP proxy. Dvs. man kan adressere den som Outbount SIP proxy, men den virker også selv om man ikke gør.

Som det måske allerede er synligt, så kan det blive ret kompliceret, hvis man har en løsning med router bag ved router og her fra lokalnettet vil køre SIP. Er den ene router med SIP-path-through, som ikke kan forliges med STUN, og den anden router en løsning, der bedst klares med STUN, så bliver det hele noget teknisk at løse. Men det kunne måske løses ved at slå SIP-path-through fra, eller ved at lave port forwarding i routeren, der ikke har SIP-path-through. Opskriften er ofte først at simplificere løsningen, og her få det til at virke, og så bygge videre på netværket, hvis det er nødvendigt.

SPI

SPI står for stateful packet inspection firewall, sikkerhedsløsninger der undersøger indholdet af det der går gennem en router. I nogle routere kan SPI være implementeret, så det konflikter med SIP, men det er efterhånden sjældent. Hvis din SIP driller, og hvis du kan slå SPI fra, så kunne du eventuel prøve. Det ville være bedst for sikkerheden, at man kan beholde SPI. Måske kan man opgradere sig ud af problemet.
Nogle router producenter kalder løsningen for Packet Filtering, eller andre udtryk med fx ord som filtering, protection eller inspection.

Port opening – Er routeren åben mod lokalnettet?

Normalt er der åbnet mod lokalnettet når vi fx vil surfe på internettet, men det er ikke sikkert at alle porte mod lokalnettet er åbne, fx måske ikke dem vi skal bruge til IP-telefonien. For at finde ud af om det er routeren der ikke vil lukke signalerne ud på internet, må du læse lidt om din router i manualen. Normalt for NAT routere er at næsten alle porte pr. default er lukket for adgang fra internettet, men de fleste har alle porte åbne, når man adresserer fra lokalnettet ud mod internettet, men ikke alle har, her er det nødvendig at åbne de porte der skal anvendes, med mindre routeren har SIP-path-through. De lukkede porte fra internettet, det er det NAT traversal trafik og STUN normalt løser.
Hvis det er nødvendigt at åbne porte mod lokalnettet så vil STUN ikke kunne afklare firewall type før porten til STUN er åbnet, det er oftest port UDP 3478, som STUN bruger. Med andre ord, hvis STUN ikke kan afklare firewall type, så kunne det være et tegn på, at der muligvis er behov for at åbne de anvendte porte. Årsagen til at STUN ikke kan afklare NAT type kunne dog også være, at der er flere forskellige typer NAT efter hinanden.

Er port forwarding nødvendig for mig?

Normalt vil STUN og NAT traversal sikre at telefonsignalerne kommer gennem routeren. Med Full Cone NAT Firewall-routere kan der kun være behov for port forwarding, i situationer med flere routere, eller hvis man vil spare NAT traversal trafikken. For Restricted Cone, og Port Restricted Cone, kan der være behov for port forwarding til fx RTP (lyden). Behovet her kunne ytre sig ved at man måske godt kan få lyd, når der ringes via fastnettet, men ikke når to, der kører IP-telefoni, forsøger at tale sammen.
Routere med symmetrisk NAT er specielle, og her vil der normalt være behov for port forwarding.
Se også om STUN og NAT-typer hos voip-info.org.
Find ud af mere om port forwarding mm. her: Portforward.com, Hvad er port forwarding? og hvad er port triggering?. Leadtek beskriver port forwarding her: Leadtek.

Port forwarding – er at åbne porte i begge retninger

De mest almindelige porte kan man ofte åbne ved at klikke det af i routerens brugerflade. Det vil være til fx Web-server, FTP-server eller Telnet-server. Når vi kommer til de porte vi skal bruge, så skal vi ofte ind i en tabel med Port Forwarding, eller Port Redirection, hvor vi vælger, hvilken port, eller port range, og om det er TCP eller UDP, og hvilken intern IP adresse det skal forwardes til. Ofte er det kun nødvendig for SIP og RTP media portene.
Det er vigtigt at SIP UA’en man peger på med port forwarding hele tiden beholder samme IP adresse, for ellers peger man jo forkert, når den får en ny IP adresse. I nogle routere kan man låse IP adressen ved hjælp af SIP UA’ens MAC adresse, i andre kan det være nødvendig med statisk IP for SIP UA’en.
Det man gør med port forwarding er, at alle IP adresser på WAN siden har en bestemt port åbnet mod en bestemt IP adresse på LAN siden, og man definerer også, hvilken port det er her på LAN. Det kunne også være et område af porte man åbner på den måde. Et eksempel, med én port: Alle på WAN, port UDP 5060, har forbindelse med 192.168.0.102 port UDP 5060. Der er nu helt åbent fra 192.168.0.102 mod alle IP adresser på WAN siden via port UDP 5060, og alle IP adresser på WAN siden har nu også helt åben forbindelse til 192.168.0.102 via port UDP 5060. Når man fra WAN siden adresserer UA’en på LAN så adresserer man den IP adresse som WAN siden har, det kunne så eventuel være en offentlig IP adresse.
Nogle producenter har fundet på at lave port triggering, hvilket vil sige at der først sker en port forwarding efter en port har været åbnet fra lokalnettet. Det er sandsynligvis lige så godt som anden form for port forwarding.
Har man lavet Port Forwarding, så er det ikke nødvendig også at lave Port Opening.
I de fleste løsninger med port forwarding er der ikke behov for STUN. Med der kunne være et behov for STUN grundet flere NAT firewalls. Her er det også nødvendig med port forwarding for STUN. Er der problemer med lyden så kunne det skyldes at man ikke overholder dette.
Der er flere fordele ved at lave port forwarding, så behøver man fx ikke NAT traversal-trafik (tomgangstrafik) til at holde portene åbne, og sidder routeren på en offentlig IP adresse, så kan man sandsynligvis lave en konfiguration, så RTP media stream ikke nødvendigvis skal gå ad omvejen via en RTP proxy. Dette kan give bedre lyd, når to der kører med IP-telefoni taler sammen. Om man kan opnå den fordel afhænger af om der er flere NAT routere mellem SIP UA’en og internettet (den offentlige IP adresse). Det afhænger også af løsningen hos VoIP udbyderen. Fx en Asterisk server vil altid tage lyden over serveren. Hos Musimi kan man selv vælge, om man vil bruge RTP server.
Ellers siger man ofte at port forwarding er sidste udvej for at få IP-telefonien til at virke.

Hvilke porte drejer det sig om?

NTP (uret/tidsinformationen på internettet), det har vidst alle routere åbnet for i forvejen. Med port forwarding er der ofte kun behov for at lave dette for SIP og RTP. Men ved almindelig port åbning for lokalnettet, så kan der også være behov for STUN.
Sipura SPA: UDP 5060-5061 (SIP), UDP 16384-16482 (RTP MEDIA), UDP 3478 (STUN), UDP 123 (NTP)
Grandstream: UDP 5060 (SIP), UDP 5004-5007 (RTP MEDIA), UDP 3478 (STUN), UDP 69 (TFTP), UDP 123 (NTP).
X-Lite: UDP 5060 (SIP), UDP 8000-8005 (RTP MEDIA), UDP 3478 (STUN)
X-Pro: UDP 5060 (SIP), UDP 8000-8011 (RTP MEDIA), UDP 3478 (STUN)

Flere SIP UA’er

Har man flere SIP UA’er på samme lokalnet så er der sandsynlighed for at de kan ‘stjæle porte’ for hinanden. Her skal man ofte ændre i konfigurationen så de har hver deres SIP port/porte. Samt RTP porte, hvis man skal kunne tale i begge samtidig. Ved port forwarding er det er tydeligt, at samme port kun kan bruges til en opgave. Behovet for separate porte er der sandsynligvis ikke, hvis man kører via en SIP-path-through router.
Der findes også enkelte internetudbydere, som tilbyder privat IP, hvor brugerne kan ‘stjæle porte’ for hinanden, fx nogle Arrownet fællesantenne løsninger. Her er løsningen også at vælge sig nogle porte i sin SIP enhed, som ikke andre bruger, eller at få offentlig IP. En anden løsning kunne selvfølgelig være at internetudbyderen fikser det problem, for det er jo svært som bruger at gætte, hvad andre anvender, på hans net.
Grandstream har en lille feature her, for man kan vælge Use random port: yes – så prøver den sig frem, med hvilke porte der kan bruges. Men det går ikke at køre med det, hvis man har lavet port forwarding.

Firewall i computeren

Kører man med SoftPhone da skal man også være opmærksom på at en sikkerhedsfirewall i computeren kan have lukke for de anvendte porte.

Switch kontra router

Nogle internetudbydere, fx Stofanet familieopkobling, tilbyder flere privat IP adresser, og her kunne man bruge en switch i stedet for en router.
Der er et adgangs- og sikkerhedsaspekt i en sådan løsning. Hvis man overvejer den løsning, så må man være klar over at der måske kan være problemer med adgang fra computeren til konfigurationssiderne i IP-telefonen, eller ATA’en, og har man adgang her, så har sandsynligvis også mange andre adgang fra det subnet man er koblet op imod. Fx en Sipura SPA-2000 bør her beskyttes med både admin og user login.
Det anbefales at vælge en router løsning. Selv om det måske synes lidt teknisk med en router, så er det her man har mulighed for at få styr på det hele. Det giver langt større sikkerhed, og man kan dele alt lokalt.

Allways-On

I internetopkoblinger, hvor der afregnes efter trafik mængde, kan man møde løsninger, der kobler ned, når der ikke er trafik. Metodikken findes også som en mulighed i visse routere. Hvis man altid skal kunne modtage telefonkald, så er det nødvendigt, at man har forbindelse til internettet hele tiden.
Hos Stofanet kan man vælge Allways On via opsætningen signon.stofanet.dk.

Lyden der mangles mod en selv

Ifølge SIP standarden så skabes der direkte forbindelse mellem A og B som taler sammen (via RTP media stream). Routere af typen Full Cone NAT Firewall kan dette, men ikke de øvrige firewall typer. Man vil typisk opleve problemet ved kald mellem to som begge kører med IP-telefoni. Løsningen kunne være at etablere port forwarding for RTP, men det kunne også løses ved altid at få lyden via en RTP server. Asterisk servere tager altid lyden ind over sig. Hos Musimi kan man til eller fravælge brug af RTP server. – Prøv også at fravælge STUN.

UPnP-firewall

Microsoft lagde en gang op til en standard, UPnP (Universal Plug and Play), hvor firewallens porte kan styres fra udstyr på lokalnettet, og mange router producenter har fulgt trop med at implementere dette i deres firewalls. Det er praktisk, hvis man fx skal anvende lyd og video kommunikation via Messenger, men der skal også følge en lille advarsel med når man anvender UPnP, idet man dermed mister føling med, hvilke porte der står åbne. UPnP gør portstyringen transperant for brugerne, og portstyringen udgør hele sikkerheden i en firewall. Jeg ville ikke turde køre med UPnP, fordi det ødelægger den sikkerhed vi har i en hardware firewall. Det siges så også, at Microsoft selv har indset dette, og at Microsoft har planer om igen at droppe UPnP. – Når alt dette er sagt: Det kunne jo være at du har en SIP UA, og en router, der understøtter UPnP, så du kunne vælge at køre uden STUN og uden NAT traversal trafik, men i stedet blot kunne slå UPnP til. Men der er vidst langt imellem disse løsninger til SIP.
Man kunne forholdsvis let bygge en kommandofil, som via UPnP laver portforwarding af de anvendte porte. Men det ville i mange tilfælde være mere praktisk, i stedet at lægge permanent forwarding ind i routeren.

VPN som omvej

Har man ikke mulighed for at få lavet det der skal til, i routere, imellem det lokalnet man kører på, og internettet. Så er der set løsninger, hvor man kører VPN igennem det hele, og ud til en service på internettet, hvor man fx rammer en Outbound SIP proxy, eller SIP proxy. Har man overvejelser i den retning, så skal man måske også se på sikkerhedsregler for lokalnettet man kører på. Er der fx lukket for SIP fordi man ikke må?
Det er en lidt nørdet NAT traversal løsning. Man får en omvej for lyden, og det kan måske være svært at finde en service til dette på internettet. Men teknisk, så er det en mulighed.

DMZ

DMZ er en udmærket midlertidig løsning til test formål. DMZ åbner alle porte, eller næsten alle, mod en bestemt intern IP adresse. Man kan sige at DMZ er en voldsom stor port forwarding. Det er for meget at køre med DMZ til hverdag, fordi det begrænser, hvad de øvrige enheder på lokalnettet kan bruge internettet til, når man kun har en IP adresse mod internettet. DMZ kan være lidt forskelligt fra router til router, så læs dokumentationen til din router.

Intranet

Virksomhedsrouter ligger lidt udenfor emnet, men en sådan løsning kan ofte håndtere flere IP adresser på WAN siden, og de kan så permanent have en DMZ subnet med web server, mail server mv., og så samtidig bruge en anden IP adresse med alle porte mod lokalnettet/intranettet. I disse kan firewallen også være af proxy typen, der gør det nødvendig med en firewall SIP gateway, for at kunne køre SIP mellem intranettet og internettet. Det kunne være en Outbound SIP proxy, eller en SIP path-through løsning sammen med firewallen.

STUN, TURN, og ICE

Som vi har set, så klarer STUN ikke alle NAT firewall situationer, specielt ikke symmetrisk NAT, der er den mest restriktive firewall, og netop derfor løsningen som findes i mange professionelle firewalls.
For at nå hen mod universalløsningen til NAT traversal er der flere udbygninger til STUN, og alternative standarder på vej. Her er det sandsynligvis mest interessant at følge TURN (Traversal Using Relay NAT) og ICE (Interactive Connectivity Establishment).

IAX/IAX2

Nogle udbydere af IP-telefoni tilbyder kommunikation via IAX/IAX2, som en alternativ til SIP. IAX kan også ses som en måde at løse port problemer. At kommunikere via IAX fordrer en User Agent der understøtter dette. Som eksempel kan nævnes SoftPhone Firefly fra Virbiage.

Andre årsager end porte

Her var der fokuseret på problemer med porte, fordi det udgør en stor del af de fejl man kan løbe ind i, og fordi det måske er et område, som trænger til afklaring.
Ser man på fejlsøgning generelt, så kan der også være andet, som driller. Fx at der i et kald ikke kan findes en fælles codec, så lyden mangler. Der kan være fejl i SIP konfigurationen, så man peger forkert, eller fx bruger forkert password til authenticate login. Man kunne have en dial plan, som ikke lige gør, som forventet.
Endvidere kunne der være fejl i kabler og udstyr, og mest sandsynligt, at det ikke er sat rigtigt op.
I forbindelse med at starte med IP-telefoni, så ændrer mange i deres opkobling mod internettet, fx ved at indskyde en ny router. Her glemmes ofte, at man nu skal tilbage til internetudbyderens vejledning for opkobling mod internet. Måske er problemet her blot, at man skal have registreret en ny MAC-adresse i DHCP serveren hos internetudbyderen.

Et par konfigurationseksempler

1) Vil man, teste lidt af hvert til IP-telefoni, så kunne følgende måske være det rigtige valg. En offentlig IP adresse fra internetudbyderen, og en Intertex router med NAT Traversal, men ikke nødvendigvis med SIP ATA funktion, dvs. man kan ikke her tilslutte en analogtelefon direkte.
Med denne løsning kan der sættes SIP UA’er på lokalnettet uden at køre med STUN, og uden NAT traversal trafik. Det er hurtigt og let at skifte mellem forskellige IP-telefoni løsninger på lokalnettet, og man kan have flere UA’er koblet op samtidig. På grund af NAT Traversal i routeren kan man anvende de default porte som SIP UA’erne har, dvs. fx flere der samtidig bruger UDP 5060 til SIP. Og på grund af NAT Traversal i routeren så fungerer alt, som om hver UA sad direkte på den offentlige IP adresse, så der er ikke behov for RTP proxyen hos VoIP udbyderen. Intertex routerne har endvidere en god Trafic Shaping QoS, der både gør noget for at give talen prioritet i downstream og upstream.
2) For andre, der blot vil op og køre IP-telefoni med en simpel løsning, ville jeg nok anbefale at man valgte en router med SIP ATA indbygget i routeren, og en offentlig IP adresse, hvis det ikke er for dyrt. Her ville det så være mindre vigtigt, om der er SIP-path-through i routeren. Måske kunne det være en Sipura SPA 2100, eller en Fritz!Box.
For mig er eksempel 1 idealløsningen, men man skal faktisk se på mange behov for at kunne pege på noget, som måske er det helt rigtige for andre. I eksempel 2 – SPA 2100, kan kun styre QoS i upstream, og her frådser den i skrivende stund lovlig meget med båndbredden, hvis der virkelig skal gives prioritet.

Sipura specifikt – STUN og NAT traversal

Sipura produkterne får her lidt særlig opmærksomhed

Under fanebladet Line 1 og/eller 2 -> NAT Settings

NAT Mapping Enable: yes
med yes fortæller man, at der vil ske en port ændring på grund af NAT. Kører man med SIP-path-through router, eller med port forwarding, eller dirket på offentlig IP, uden NAT imellem, så skal man vælge no.

NAT Keep Alive Enable: yes
med yes er NAT traversal trafikken slået til

NAT Keep Alive Msg: $NOTIFY
indholdet i NAT traversal datapakkerne bliver en SIP Notify, og det er normalt, at man har det. På Sipura.com nævnes, at man, for at mindske trafikmængden, kunne lade feltet være blank, så er det små pakker, uden indhold, der sendes. At sende Notify, er valgt som default, her en man sikker på at SIP standarden følges. Men det vil normalt være ok, at lade feltet være blank.

NAT Keep Alive Dest: $PROXY
her fortæller man at adressen på disse NAT traversal pakker skal være Proxyen, som er specificeret under afsnittet Proxy and Registration

Under fanebladet SIP -> NAT Support Parameters

STUN Enable: yes
her slår vi STUN til

STUN Server: stun.musimi.dk
her lægger vi adressen på STUN serveren, og informationen må gerne ligge der, selv om vi ikke bruger den. Porten hos STUN serveren, kunne man også specifisere med, fx stun.musimi.dk:3478, men da port 3478 er default for STUN, så er det ikke nødvendig at nævne den. – Default port numre kan ses hos IANA.

STUN Test Enable: yes
med yes giver Sipura SPA flere informationer i loggen til test formål. Under almindelig drift kan den lige så godt være sat til no. Hvordan man laver log er forklaret i Sipura FAQ.

NAT Keep Alive Intvl: 15
her fortælles hvor ofte NAT traversal datapakkerne skal sendes. 15 sek. interval er ok for de fleste routere, men det er set for enkelte routere, at den skulle ned på 12 for at holde portene åbne. I en del routere kan man sætte Session timer (kaldes også for Connection timeout eller Inactivity timeouts), og for nogle er det delt op i fx TCP og UDP, og det er tiden for UDP, man skal fokusere på.

Med de øvrige parametre under NAT Support Parameters, og enkelte under fanebladet Line, kunne man, i stedet for at anvende STUN, selv gå ind og forme SIP datapakkerne. Der findes en vejledning for dette et eller andet sted på sipura.com.

Når hjælp søges til fejlfinding af porte

Beskrivelsen her er tænkt som hjælp til fejlsøgning. Skal andre hjælpe dig med at styre hen mod problemløsningen, så kan et godt forarbejde også være afgørende, og det er faktisk noget af det samme:
Det kan sandsynligvis give nogle idéer til løsning, hvis du oplyser, hvilken internetopkobling du har, og hvad det er for udstyr du bruger. En god beskrivelse af hele din konfiguration. Det er vigtigt at vide, hvilke symptomer du oplever, og hvilken VoIP service du kører op imod. Det er også vigtigt at vide om din UA kører med en fast offentlig IP adresse, eller om den har en privat IP adresse.
Kører din UA med en privat IP adresse, da er det vigtigt at vide, hvilken type firewall der sidder i din NAT, mellem din offentlige IP adresse og din privat IP adresse, og hvilken NAT traversal der anvendes. Er der lavet port forwarding, da er det også vigtigt præcist at vide hvilke porte er der lavet port forwarding for, og hvilken UA du bruger.

Opret faxmodtager og telefonsvarer på din router

AVM er netop kommet med ny firmware til mange af deres Fritz!boxe.

Opret fax og telefonsvarer på din Fritz!box
Opret fax og telefonsvarer på din Fritz!box - Billede af Robert Brook

Jeg har omtalt den på Voipsnak, men her vil jeg komme med en lille guide til hvordan man bruger de nye services. Med denne firmware kan man modtage fax pr. mail og sætte sin router op til at agere telefonsvarer.

Her får du en guide i tre trin, som viser dig hvordan du sætter det op.

Opret Push service

Push service er din mulighed for at modtage mails med system meddelelser. Det handler om oppetid, opkaldsoversigt og hvilket codec de forskellige opkald benytter. Du skal starte med at oprette denne for at kunne modtage faxen og telefonsvarens beskeder pr. mail.

1. Åben din browser og gå til fritz.box
2. Gå til Settings -> System -> Push service
3. Indtast dine mailoplysninger. For en gmail, som jeg bruger er det alle standardoplysningerne (husk at skrive mail helt ud), men for smtp server i advancerede indstillinger skal man indtaste smtp.gmail.com:465
4. Kør en test, og nu skulle det gerne virke.

Opret Faxmodtager

Du kan sætte din Fritzbox op til at kunne modtage fax, enten således at det bliver sendt til din mail, eller således at det bliver lagt ned på en ekstern harddisk, som du kan tilknytte din Fritz.

1. Gå til Settings -> Telephony -> Telephony devices og klik på Configure New Device
2. Vælg Fax reception under den overskrift der hedder Integrated in the FRITZ!Box
3. Derfra skulle det være ligetil.

Opret telefonsvarer

Guide til Fritzens telefonsvarer
Guide til Fritzens telefonsvarer

1. Gå til Settings -> Telephony -> Telephony devices og klik på Configure New Device
2. Vælg Answering machine under den overskrift der hedder Integrated in the FRITZ!Box
3. Derfra skulle det være ligetil.
4. Løft røret og tryk **600 for at komme ind i telefonsvarer menuen
5. Tryk 5 og dernæst 1 og så 8 for at optage besked
6. Når beskeden er slut, så klik på 1.

Det er jo egentlig ligetil, når bare man ved hvor man finder telefonsvaren og faxen, men dem har AVM valgt at gemme godt af vejen. Det er synd, for det er lækre features.

NB. det virker pt. kun til disse routere:
FRITZ!Box Fon 5124
FRITZ!Box Fon WLAN 7140
FRITZ!Box Fon WLAN 7170
FRITZ!Box Fon WLAN 7270