SIP och NAT, Brandväggar och STUN

SIP och NAT, Brandväggar och STUN BAKGRUND Många kämpar med att ringa med SIP genom routers. Många av oss får problem och anledningen är enkel, SIP är inte avsett att användas genom brandvägg och NAT. Har nedan utgått från en egen inloggning till registreringsservern och ett efterföljande samtal. Har i loggen från dessa lagt in förklaringar och kommentarer. Det är inte så svårt att lära sig vad som sker och vet man detta kan sedan enklare veta vart man skall leta efter lösningen på problemen. Har inte kollat alla detaljer fullt ut och det kan finnas felaktigheter i detaljerna. Jag har använt ett program i datorn för att ringa och loggat vad som sker. Programmet heter X-Lite och är vanligt. Om ni inte upptäckt det kan man få fram en logg genom att högerklicka i programmets fönster och sedan välja loggen. Loggen försvinner när ni stänger programmet. INLOGGNINGEN När man startar X-Lite, eller sin telefon av annan typ, så sker en inloggning till operatörens så kallade registrarserver. En vanlig telefon är ju låst till en fysisk position vilket inte VoIP är. Man måste börja med att tala om för operatörens server var man finns = vilken IP-adress man finns på. Det är detta som sker vid registreringen. 2004 Xten Networks, Inc. All rights reserved. sipgate X-Lite release 1105c build stamp 16372 License key: CEFA25348AD84D8293D7506 Established SIP protocol listen on: 192.168.0.119:5060 På raden ovanför framgår att X-Lite nu börjat lyssna på min internadress, den bakom routern alltså. Delen innan kolon är själva adressen, delen efter kolon är portnumret som man lyssnar på. X-Tunnels is disabled since an X-Tunnels server could not be located. Discovered Full Cone NAT Firewall För att kunna veta ovanstående krävs att X-Lite använder STUN. För att helt kunna fastställa vilken typ av NAT man använder krävs två olika STUN servers. Mer om STUN nedan. För övrigt tror jag att jag har restricted port cone NAT. Mer om detta nedan. SIP: 192.168.0.119:5060 RTP: 192.168.0.119:8000 RTP är protokollet för överföring av ljud, sker här på port 8000 NAT: 213.110.232.116 Min externa adress på Internet PROXY#0: 217.10.79.23:5060 Operatörens serveradress, lyssnar på port 5060 SEND TIME: 3005626 Tidsangivelse, man kan se tiden mellan olika händelser Visar vilket håll paketet gått, i detta fall ut från mig till servern REGISTER sip:sipgate.co.uk SIP/2.0 Första ordet innebär att jag begär att få registrera mig 213.110.232.116:5060;rport;branch=z9hG4bK3EA72F5272054D48B0674FBA127C9DE7 From: Kalle Anka <sip:5112379@sipgate.co.uk>;tag=1895707065 5112379 min benämning hos operatören To: Kalle Anka <sip:5112379@sipgate.co.uk> Contact: "Kalle Anka" <sip:5112379@213.110.232.116:5060> Min IP-adress och vilken port jag lyssnar på CSeq: 9580 REGISTER Expires: 1800 2006-12-19 1

RECEIVE TIME: 3005714 Avsändare för detta paket är servern SIP/2.0 401 Unauthorized Av någon anledning blev jag inte godkänd, troligtvis för att jag inte gett användare/lösen 213.110.232.116:37639;rport=5060;branch=z9hG4bK3EA72F5272054D48B0674FBA127C9DE7 From: Kalle Anka <sip:5112379@sipgate.co.uk>;tag=1895707065 To: Kalle Anka <sip:5112379@sipgate.co.uk>;tag=968ada9c3ffba887db8ff01d701887bd.0f0e CSeq: 9580 REGISTER WWW-Authenticate: Digest realm="sipgate.co.uk", nonce="4587ac758bfbfd95e19fafec50dee344bf02da64" SEND TIME: 3005716 Så lätt ger jag mig inte, ett försök till! Paket från mig till servern REGISTER sip:sipgate.co.uk SIP/2.0 213.110.232.116:5060;rport;branch=z9hG4bKD4B75047C3AD46879CBB0518875111BF From: Kalle Anka <sip:5112379@sipgate.co.uk>;tag=1895707065 To: Kalle Anka <sip:5112379@sipgate.co.uk> Contact: "Kalle Anka" <sip:5112379@213.110.232.116:5060> CSeq: 9581 REGISTER Expires: 1800 Authorization: Digest username="5112379",realm="sipgate.co.uk",nonce="4587ac758bfbfd95e19fafec50dee344bf02da64",response= "b5ac3ae590ea8745707bc9fdcc8cfc18",uri="sip:sipgate.co.uk" RECEIVE TIME: 3005811 SIP/2.0 200 OK Denna gång gick det att registrera 213.110.232.116:37639;rport=5060;branch=z9hG4bKD4B75047C3AD46879CBB0518875111BF From: Kalle Anka <sip:5112379@sipgate.co.uk>;tag=1895707065 To: Kalle Anka <sip:5112379@sipgate.co.uk>;tag=968ada9c3ffba887db8ff01d701887bd.2d20 CSeq: 9581 REGISTER Date: Tue, 19 Dec 2006 09:05:14 GMT Contact: <sip:5112379@213.110.232.116:37639>;expires=1800 Registreringen är nu klar. Servern vet var jag kan nås och så här blir det tills jag ringer ut eller någon ringer mig. Observera ovan att port UDP 5060 användes både för att sända och för att ta emot. När man skickar ett UDP paket hålls den port man använt öppen ett tag även för inkommande paket. Kan vara upp till några minuter. Här har vi en felkälla som kan verka mystisk: Eftersom registreringen normalt går fort och kommunikationen sker på samma port så är port 5060, i detta fall, öppen för mottagning utan speciella åtgärder. Det kan gå att registrera sig men när någon senare försöker ringa till mig går inte detta. Efter några minuter stängs port 5060. När någon försöker ringa mig finns ingen öppen port och jag upptäcker inte ens att någon försöker ringa mig. Ovan har hela proceduren försiggått på vad jag kallar signalkanalen, själva överföringen av ljud går alltid på en annan port. 2006-12-19 2

NAT OCH BRANDVÄGG I ROUTERN Det normala för en hemanvändare är att man får en adress ut mot Internet men man har flera datorer som samtidigt skall ut på nätet. I dessa fall använder man en router med NAT. Varje intern enhet får en egen unik internadress, t.ex. 192.168.0.119 som min dator har i exemplet ovan. Dessa interna adresser finns i ett fåtal unika nummerserier och är därmed igenkända som interna. Hur gör man då för att kunna hålla isär trafiken till ett antal interna datorer som mot Internet skall samsas om en adress? Ett exempel: 192.168.0.119:5060 vill till 217.10.79.23:5060. En annan intern dator 192.168.0.120: 1732 vill till 4.123.8.23:80. Lösningen blir att båda ut på internet får samma IP-adress 213.110.232.116 men olika portnummer. NAT håller sedan koll på vem som är vem i en tabell och kan sedan skicka paket utifrån till rätt intern dator. Kommer inte ihåg vad N står för i NAT. AT står dock för Address Table. Det finns olika typer av NAT, det finns olika typer av brandväggar. Det går att skriva många sidor om bara det men nedan kommer jag att anta att vi har vad som finns i en typisk hyfsad modern router: Port restricted NAT and Stateful firewall. I praktiken innebär detta att för att en extern dator skall kunna kontakta en av mina interna, så måste den interna först ha kontaktat den externa datorn på den port den skickar tillbaks information på. Lång mening: Vi kan jämföra det med att ingen någonsin skulle kunna ringa oss om vi inte först ringt dem, kanske inte en så dum idee när man tänker på det! Kontakterna från yttervärlden måste alltså ner till portnivå vara initierade inifrån först. Detta är väsentligt men blir enklare med exempel på problem nedan. En varning här om definitionen; jag är inte säker på en sak, kan kanske definieras på olika sätt av olika tillverkare: Definitionen jag har ovan stämmer för TCP i allmänt bruk. Är dock inte lika säker på att man alltid för UDP kräver att det kommer från en redan initierad full adress (IP-adress och port) som man skickat till tidigare. Det kan vara så att man tillåter trafik in för UDP bara IP-adressen redan är känd. JAG RINGER ETT NUMMER Nedanstående är vad som sker på signalkanalen när jag ringer ett samtal. Själva ljudöverföringen kopplas sedan upp på helt andra portar än 5060 som används för att etablera och avsluta samtalet. Det är heller inte helt säkert att detta samtal är helt typiskt. Jag ringde ett nummer som är till för att testa, här föregås samtalet inte av någon ringsignal som man kan höra. Kan vara väsentligt vid felsökning, tror nämligen inte att vi får höra ringsignalen från andra sidan, den genereras på annat sätt tills man svarar i andra änden. Jag menar med detta att exemplet nedan kanske inte är helt typiskt för när signaleringen är klar och själva samtalet börjar. X-Lite är ju vanlig, prova själv om ni behöver kolla. SEND TIME: 3421032 Paket från mig till servern INVITE sip:50000@sipgate.co.uk SIP/2.0 50000 är numret jag ringer, jag INVITE till en session 213.110.232.116:5060;rport;branch=z9hG4bKA0D358034E0541FB9B5AAE944A0AE92F To: <sip:50000@sipgate.co.uk> Här känner X-Lite till min externa adress, via STUN antar jag. CSeq: 39697 INVITE Content-Type: application/sdp Content-Length: 318 v=0 o=5112379 3421004 3421031 IN IP4 213.110.232.116 s=sipgate X-Lite c=in IP4 213.110.232.116 t=0 0 m=audio 8000 RTP/AVP 8 0 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 2006-12-19 3

a=rtpmap:98 ilbc/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv Raderna ovan är värda en egen mässa, de är centrala för de problem vi får. Raden ovan, m=audio 8000 RTP/AVP 8 0 3 98 97 101, innebär följande; jag talar om att jag kommer att ta emot ljudet från andra parten på port 8000, förväntar mig protokollet RTP. Siffrorna mot slutet av raden, 8 0 3 98 97 101. Är en uppräkning av de codecs jag klarar. Raden ger även en prioritering avseende vilket codec jag helst vill använda, codec nummer 8 står först och det är det jag föredrar, prioriteringarna sedan i ordning nedåt. Det finns varianter av codecs. I raderna som följer specar jag vilka varianter jag menar, exempel a=rtpmap:0 pcmu/8000 innebär att codec 0 använder samplingfrekvensen 8000 Hz. Den codec som väljs är den som finns på bådas listor och ligger högst upp. RECEIVE TIME: 3421144 SIP/2.0 407 Proxy Authentication Required Svaret jag får är att jag måste autenticera mig innan vi kör 213.110.232.116:37639;rport=5060;branch=z9hG4bKA0D358034E0541FB9B5AAE944A0AE92F To: <sip:50000@sipgate.co.uk>;tag=968ada9c3ffba887db8ff01d701887bd.132c CSeq: 39697 INVITE Proxy-Authenticate: Digest realm="sipgate.co.uk", nonce="4587ae1596001ec725dff797fd01292857bb48b2" SEND TIME: 3421146 ACK sip:50000@sipgate.co.uk SIP/2.0 213.110.232.116:5060;rport;branch=z9hG4bKA0D358034E0541FB9B5AAE944A0AE92F To: <sip:50000@sipgate.co.uk>;tag=968ada9c3ffba887db8ff01d701887bd.132c CSeq: 39697 ACK SEND TIME: 3421153 Nu är jag kollad och kör samma information som ovan igen INVITE sip:50000@sipgate.co.uk SIP/2.0 213.110.232.116:5060;rport;branch=z9hG4bKF381F4C56D154382A7843B19DF505BE9 To: <sip:50000@sipgate.co.uk> CSeq: 39698 INVITE Proxy-Authorization: Digest username="5112379",realm="sipgate.co.uk",nonce="4587ae1596001ec725dff797fd01292857bb48b2",response ="340ede16bbde27220d172137a6ebbe16",uri="sip:50000@sipgate.co.uk" Content-Type: application/sdp Content-Length: 318 v=0 2006-12-19 4

o=5112379 3421004 3421031 IN IP4 213.110.232.116 s=sipgate X-Lite c=in IP4 213.110.232.116 t=0 0 m=audio 8000 RTP/AVP 8 0 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 ilbc/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv RECEIVE TIME: 3421299 SIP/2.0 100 trying -- your call is important to us Jag är godkänd och trying till vänster är att nu försöker vi ringa 213.110.232.116:37639;rport=5060;branch=z9hG4bKF381F4C56D154382A7843B19DF505BE9 To: <sip:50000@sipgate.co.uk> CSeq: 39698 INVITE RECEIVE TIME: 3421673 SIP/2.0 200 OK OK, vi kör, nu etablerar vi förbindelsen 213.110.232.116:37639;rport=5060;branch=z9hG4bKF381F4C56D154382A7843B19DF505BE9 Record-Route: <sip:217.10.79.23;lr=on> CSeq: 39698 INVITE User-Agent: sipgate asterisk Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:50000@217.10.79.35> Content-Type: application/sdp Content-Length: 289 v=0 o=root 31383 31383 IN IP4 217.10.79.35 s=session c=in IP4 217.10.79.35 t=0 0 m=audio 11030 RTP/AVP 8 0 3 98 101 Här talar servern om vilken port den kommer att använda, 11030 a=rtpmap:8 PCMA/8000 Här har vi ett problem, jag kommer inte att höra den andra a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:98 ilbc/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silencesupp:off - - - - SEND TIME: 3421681 ACK sip:50000@217.10.79.35 SIP/2.0 2006-12-19 5

213.110.232.116:5060;rport;branch=z9hG4bK1E3CA7981E9A436B8CC5FB21757A9959 Route: <sip:217.10.79.23;lr=on> CSeq: 39698 ACK SEND TIME: 3432390 Det här paketet kommer några sekunder senare, jag har avslutat samtalet BYE sip:50000@217.10.79.35 SIP/2.0 213.110.232.116:5060;rport;branch=z9hG4bK78BF59A0872F49EDA77A9CE641B218E8 Route: <sip:217.10.79.23;lr=on> CSeq: 39699 BYE RECEIVE TIME: 3432506 SIP/2.0 200 OK Uppfattat, klart slut från servern 213.110.232.116:37639;rport=5060;branch=z9hG4bK78BF59A0872F49EDA77A9CE641B218E8 Record-Route: <sip:217.10.79.23;lr=on> CSeq: 39699 BYE User-Agent: sipgate asterisk Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:50000@217.10.79.35> Ovan har jag markerat med grönt ett problem som är typiskt orsakat av NAT/brandvägg. Servern talar om, som information i ett paket, att den kommer att sända ljudet till mig på port 11030. Problemet är att NAT/brandvägg vet inte att något förväntas komma här och släpper inte igenom något! För att paketen som sänds till mig på port 11030 skall kunna nå fram måste jag initiera, öppna, porten genom att skicka något ut på denna port. Det har jag inte gjort. Resultatet i detta fall skulle ha blivit att den i andra änden kunde höra mig men jag inte dem. De hör dock mig, trafiken ut på port 8000 initieras ju innifrån. Man kan lösa detta genom att i routern köra port forwarding för vissa portar till en given intern IP-adress. Vilka portar skall man då öppna upp? Vill minnas att normen säger att man kan välja vilken port som helst mellan 1024 och 65535. Ofta begränsar de som gjort programmet/produkten detta område. Det finns ofta rekommendationer från operatören om vilka portar man behöver öppna i brandväggen/port forwarding. Dessa stämmer så länge man bara har kommunikation mellan deras grejer. Om man dock direkt via SIP skulle ringa en annan person så bestämmer hans enhet vilka portar som blir aktuella. Inte säkert det fungerar då. SIP ALG ALG står för Application Layer Gateway. I de senaste routers har det blivit vanligt att lägga in en SIP ALG i brandväggen. Denna läser då innehållet i paket som den bedömer har med SIP att göra. I exemplet ovan kan 2006-12-19 6

den alltså läsa inne i paketet att port 11030 skall öppnas och kan göra detta. SIP ALG kan även hålla port 5060, eller vad man valt signalkanalsporten till, att vara öppen. Är denna inte öppen går det inte att ringa till dig. Generellt sett är nog SIP ALG bra. I min router var det inbyggt utan ett ord om det i bruksanvisningen. Den kan dock också ge problem: I och med att man bara kan ha en port 5060 t.ex. öppen ut mot Internet går det inte att ha två SIP program i gång samtidigt, d.v.s. så länge de båda använder port 5060 för signalkanalen. I exemplet ovan kunde jag inte ta emot något ljud från mottagaren. I routerns log kunde jag hitta att SIP ALG stoppat paket ut från min dator. I min router är SIP ALG gjord för att man skall ansluta telefonen trådlöst via WLAN. Detta fungerar bra, jag har inte behövt gjöra något för att ringa ut via WLAN. Det kan dock ge andra svårdiagnostiserade problem. STUN Stun är ett sätt att hjälpa till att komma igenom NAT/brandväggar. STUN kräver kontakt med en, helst två, speciella servers. Genom att kontakta två olika servers kan STUN fastställa vilken typ av NAT man använder. Från servern kan NAT även få reda på vilken extern IP-adress som man har, skickas tillbaka till STUN klienten i datorn/telefonen. En annan viktig funktion för STUN är att hålla signalkanalen öppen. När man registrerar sig öppnar man ju port 5060 inifrån och den hålls öppen kanske några minuter därefter. Görs inget stängs den dock sedan och ingen kan ringa till mig. STUN anropar en server med jämna mellanrum för med hjälp av servern hela tiden hålla signalkanalen öppen. Är lite osäker på detaljerna här, STUN-serverns port är normalt annorlunda än signalportens. Skulle gissa att det finns olika implementeringar av STUN. Med hjälp av den information man får via sitt SIP program och det man får via STUN så finns möjligheterna att se till att man får föbindelse. För att ta exemplet ovan skulle man kunna låta STUN, eller själva SIP-programmet skicka ett paket till port 11030 hos servern. Gör man det så är ju sedan denna port öppen ett tag. Det finns dock routers som fungerar på ett sätt så att det inte går att lösa det med STUN. TYPISKA SYMPTOM NÄR DET ÄR NAT/BRANDVÄGG SOM GER PROBLEM - Det händer ingenting när man försöker registrera sig. Får man kontakt med servern men har fel inloggningsdata får man normalt besked om detta inom några sekunder. Man får dock samma symptom om man angivit fel adress till någon server. - Man får inga inkommande samtal men det går att ringa ut. - Det går inte att ringa ut. - Intermitenta problem, det fungerar ibland, ibland inte. - Man har ett program igång i datorn, typ X-Lite samtidigt som man kör en telefon. Täcker det mesta, eller hur! HUR LÖSER MAN ENKLAST PROBLEMEN DÅ? Har man ingen router och har en internetanslutning med flera IP-adresser så köper man ingen router, man köper en accesspunkt. Av någon anledning kallas de för accesspunkt och inte switch när man talar om WLAN. Telefonen får då direktkontakt med Internet vilket den är gjord för. Allt annan är halvmessyrer som ger bieffekter eller kostar pengar (det finns speciella brandväggar/routers som löser problemet, har inte kollat priserna men antar att de är dyrare än de massproducerade routers vi normal köper.) Har man bara en IP-adress mot nätet och måste ha en router så köp en avsedd för SIP. Skulle tro att de flesta moderna är det. Har man redan en router så går det säkert att få den att fungera. Försök dock hitta någon annan accesspunkt och prova därifrån. Helst en som man vet av någon annan att den fungerar. Det är det enklaste sättet att hitta felaktiga inställningar i telefonen. Ibland är det svårt att hitta beskrivningar över inställningarna. Fråga operatören, man kan inte få mer än nej. 2006-12-19 7