gigacampus » start page » sipintro

En introduksjon til SIP

Dette dokumentet gir en introduksjon til SIP. Vi forklarer også de sentrale DNS-mekanismene NAPTR, SRV og ENUM.

SIP

Session Initiation Protocol (SIP) er en standard beskrevet i IETF RFC. Det er egentlig en mengde RFC, over 100 stykker. Det heter seg at noe av det fine med standarder er at det er så mange å velge mellom, men for SIP så har det dessverre blitt slik at det er en såpass stor frihet i implementasjonen at man kan finne flere ulike SIP løsninger som i praksis ikke er så veldig kompatible med hverandre. Dette gjelder både utstyr som telefoner og programvare. I tillegg finnes det flere produkter på markedet som har lånt til dels kraftig fra SIP men har lagt til egne komponenter og i praksis gjort det til en proprietær løsning. Alt dette gjør at det er viktig at man er bevisst på at de produktene man satser på fungerer som forventet.

Til hjelp for både utviklere og brukere har det blitt utviklet noen initiativ for hvordan man bør implementere SIP.

  • SIPConnect: Dette initiativet I regi av SIP Forum har som mål å få standardisert måten utviklere og produsenter implementerer SIP I sine produkter. De har en lang rekke medlemmer blant produsenter og andre og har fått en del tyngde i SIP-verdenen. De har også ” SIPconnect Compliant Certification Program” som sjekker kompatibilitet innenfor retningslinjene. For sluttbrukere vil det være et poeng å kreve at utstyr og programvare følger spesifikasjonene i SIPConnect.

I tillegg har UNINETT noen utkast til UFS på temaet:

Kort fortalt så er SIP en signaleringsprotokoll som forhandler og etablerer kontakt mellom enheter kalt User Agent (UA). Det kan gå direkte mellom to UA eller via en Proxy som viser veien videre. Det kan også skje gjennom etapper hvor en enhet terminerer forbindelsen på hver sin side av seg selv ved å være en UA på hver side (Back-to-back UA – B2BUA). Når man er en del av en organisasjon, er det vanligste å bruke en Proxy slik at man kan få en adressering på formatet bruker@organisasjon.no for alle brukerne i den organisasjonen. Brukerne vil da registrere seg hos en Registrar som gjerne også holder rede på brukerens faktiske Lokasjon i nettverket. Uten en Proxy og Lokasjon så ville UA ha måtte bruke IP/Alias for til hverandre for å oppnå kontakt. Ved å bruke en Proxy i kombinasjon med en Registrar, kan man også legge til begrensninger ved bruken av enkelte tjenester, som f.eks..å kreve identifikasjon og tillatelse før en får ringe kostnadsbærende samtaler. En server med Proxy, Registrar og Lokasjon er ofte den samme enheten, spesielt i mindre organisasjoner.

  • User Agent (UA) – Der kommunikasjonen terminer. Som oftest klienten en bruker benytter. Det kan være programvare på PC eller et dedikert apparat.
  • Proxy – Sørger for ruting av SIP
  • Registrar – Sørger for autentisering og registrering av brukere
  • Lokasjon – Sørger for å holde rede på hvor i IP-nettet de ulike registrerte UA befinner seg.

Kommunikasjonen mellom UA går I dette eksempelet via en Proxy hos den respektive organisasjon men forutsetter at UA har registrert seg først.

Det er fullt mulig å kommunisere med en UA som ikke tilhører en organisasjon, altså direkte.

Dersom man skal ringe en ”bylinje” så er det bare et spørsmål om å få Proxy til å rute henvendelsen til en slik tjeneste dersom brukeren er autorisert til handlingen.

SIP handler også om å formidle direkte kontakt mellom partene i kommunikasjonen. Når UA har funnet hverandre så kan resten av SIP-kommunikasjonen gå direkte mellom dem uten å gå via Proxy. Dersom man imidlertid bruker funksjonen ”Strict Outbound Proxy” så er brukerne tvunget til å gå via Proxy hele tiden. Det kan også ha sine fordeler i enkelte sammenhenger.

Denne SIP protokollen etablerer kontakten og forhandler frem mulige kommunikasjonsformer, men det er viktig å merke seg at SIP ikke gjør selve kommunikasjonen over tjenesten som er forhandlet frem. Det er en kommunikasjon som blir satt opp som et resultat av forhandlingene og som bare vedlikeholdes av SIP. I SIP telefoni handler det om to separate RTP-strømmer som går den ene og den andre veien direkte mellom UA. Porten det sendes mot er forhandlet frem i SIP og kan variere innenfor et område som er definert i den enkelte UA. Dette har relevans for oppsett av brannmurer og filter.

Dette eksempelet viser hvordan RTP vil ta en direkte vei mellom UA

I tilfeller hvor vi opererer med en B2BUA, så vil den terminere RTP i seg selv for så å opprette en ny forbindelse frem til den andre UA. B2BUA vil i et slikt oppsett også kunne fungere som Registrar og Lokasjon og er ofte å se i konfigurasjoner der man kun ser på telefoni og ønsker en løsning i forbindelse med brannmurer e.l. Det er viktig å merke seg at en slik løsning setter kraftige begrensninger på hva man kan bruke SIP til og vil kunne representere et hinder mot ideen om en fremtidsrettet løsning dersom den ikke brukes riktig.

SIP kan gå både over UDP og TCP men UDP er mest vanlig. RTP går over UDP. Mens SIP har sine faste porter så kan RTP portene endre seg fra gang til gang. Det er ingen standard for hvilke porter dette skal være, men det har utviklet seg en anbefaling på hva det bør være og de fleste produkter har eller kan justeres til å bruke disse.

  • 5060 UDP SIP signaleringsport
  • 5061 TCP SIP signaleringsport
  • 16384-16485 UDP primær RTP mediestrøm
  • 49152-49162 UDP alternativ RTP mediestrøm

Så langt har det blitt presentert en ren SIP/RTP-modell som utgjør en viktig del av infrastrukturen. For å kunne kommunisere med parter som ikke bruker SIP/RTP, må vi ha en oversetter. Det kalles en Media Gateway (MGW). I telefoni finner vi som regel den mot telefonsentraler (PBX) og PSTN.

I dette oppsettet vil Proxy sørge for at UA har den nødvendige autorisasjon for å kunne kommunisere med MGW. MGW vil oppfattes som en UA som terminerer både SIP og RTP hos seg mens den på andre siden har en annen form for forbindelse mot f.eks. et ISDN-system. Dette kan altså være mot egen telefonsentral eller direkte på lokalt leide ISDN-linjer. Motsatt vei vil det hos MGW være en mekanisme for å finne ut hvor en PBX/PSTN originerende samtale skal for å nå UA. En MGW trenger ikke nødvendigvis kun ha SIP/RTP og ISDN men kan like gjerne ha H.323, SCCP (”Skinny” VoIP protokollen til Cisco) eller analoge linjer.

Med en MGW kan man altså knytte sammen den eller de telefonsentralene man måtte ha mot SIP. Det vil si at selv om det utstyret man ikke har støtter SIP, kan man få til en form for SIP støtte allikevel ut til andre former for telefoner ved å sette en MGW foran. Brukeren vil ikke merke noen forskjell i praksis bortsett fra en økning i mulige tjenester.

I en SIP infrastruktur kunne man ha satt opp statisk ruting mellom alle Proxy, men det er ikke skalerbar og veldig tungvindt. DNS er derfor en viktig støttespiller også for SIP når man skal finne frem til andre UA og tjenester.

NAPTR

NAPTR poster (RFC 3403) definerer hvilke protokoller som er tilgjengelig for en tjeneste hos en domene. Ved å foreta en spørring etter en NAPTR-post for domenedelen av adressen kan vi få svar på hva som støttes.

NAPTR poster er på formen “domain-name TTL Class NAPTR order preference flags service regexp target”

F.eks.:

"organisasjon.no. IN NAPTR 60 50 "s" "SIP+D2U" "" _sip._udp.organisasjon.no."

I denne sammenheng vil D2U bety UDP og D2T bety TCP. I tillegg har vi D2S som betyr SCTP.

SRV

SRV (RFC 2782) er neste operasjon. Dersom en NAPTR finnes, vet klienten hvilke protokoller som støttes og kan finne SRV basert på det. Dersom det ikke er noen NAPTR eller at NAPTR ikke brukes, baserer klienten seg på oppslag etter egne foretrukne protokoller. Som for NAPTR spør man i SRV etter domene. Svaret skal bli den konkrete adressen til tjenesten.

SRV poster er på formen: “_Service._Proto.Name TTL Class SRV Priority Weight Port Target”

F.eks.:

"_sip._udp.organisasjon.no 3600 IN SRV 10 10 5060 sip.organisasjon.no"

Denne adressen peker som oftest til organisasjonens primære SIP proxy som igjen eventuelt vil rute henvendelsen videre innover i sin organisasjon.

ENUM

ENUM (RFC 3761) er den siste viktige DNS komponenten. ENUM er en utvidelse av DNS som gjør det mulig å slå opp telefonnummer i E.164 format for å se om de finnes tilgjengelig på Internet.

NORID har skrevet mer E.164 og ENUM:

SIP.edu har en ”kokebok”:

ENUM er knyttet til et toppnivå som på verdensbasis foretrekkes å være e164.arpa. I Norge har dette fremdeles prøvestatus i påvente av utbredt bruk. Det er imidlertid ingenting i veien for å registrere seg i andre ENUM-trær. For UNINETT medlemmer er også nrenum.net tilgjengelig og når en del andre akademiske organisasjoner i Europa, og e164.org er tilgjengelig for hvem som helst. Det er imidlertid viktig at det er høy kvalitet på de registrerte innslag, noe som betinger et registreringssystem under god kontroll. Det er også ønskelig med så få trær som mulig, helst bare ett, da oppslag tar tid. Selv om det er bare litt tid så blir det mer en ønskelig dersom man skal sjekke flere.

Man slår opp et fullt kvalifisert E.164 nummer som da betyr at landskoden skal inkluderes. F.eks. nummeret til sentralbordet hos UNINETT er 73557900 så et fullt kvalifisert E.164 nummer blir +4773557900.

I DNS lagrer man et nummer eller nummerserie som et domene. Numrene oppføres ”baklengs” slik man gjør med domener.

   $ORIGIN 9.7.5.5.3.7.7.4.e164.arpa.
   $TTL 86400
   @       3600    IN      SOA     biff.uninett.no. hostmaster.uninett.no. (
   ; $Revision: 1.10 $
                                   2009010101 ; Serialnumber
                                   28800   ; Refresh, 8 hrs
                                   3600    ; Retry, 1 hr
                                   604800  ; Expire, 1 week
                                   86400 ) ; Minimum (& default) TTL, 1 day
   ; Name servers:
                           NS      biff.uninett.no.
                           NS      nn.uninett.no.
   ;
   ; Domain data:
   ;
   0.0                     NAPTR   10 10 "u"  "sip+E2U" "!^\\+*(.*)$!sip:\\4773557900@uninett.no!" .
   0.0                     NAPTR   20 10 "u" "smtp+E2U" "!^\\+*(.*)$!mailto:post@uninett.no!" . 
   1.0                     NAPTR   10 10 "u"  "E2U+SIP" "!^\\+*(.*)$!sip:\\4773557901@uninett.no!" .

For å begynne å bruke ENUM må man få delegert de DNS-soner som tilsvarer de nummerseriene man bruker. Dette gjøres via sin registrar eller via NORID på vanlig måte.

Det er viktig ikke å begynne å publisere ENUM-informasjon før man faktisk er nåbar på de kontaktadressene man publiserer. De finnes flere rundt om i verden som bruker ENUM og som stiller forventninger til at kontaktinformasjonen fungerer.

Det er anbefalt at man ikke registrerer en brukers adresse direkte mot et gitt nummer i ENUM men heller registrerer mot et Alias som håndteres av SIP Proxy. F.eks. å knytte nummeret +4773557900 til 4773557900@uninett.no fremfor ola.nordman@uninett.no. Dette gir lettere administrasjon med oppdatering i tilfelle nummeret overtas av noen andre og det gir bedre sikring mot mail-hamstring fra DNS til uønskede formål.

 
 
gigacampus/sipintro.txt · Last modified: 2011/05/19 19:00 by faltin@uninett.no

Viktig melding: openwiki.uninett.no

UNINETT OpenWiki er under utfasing. Wikier som er lite brukt er satt i kun-lese-modus. Ta kontakt med UNINETT for å åpne for skrivetilgang ved behov.

Group memberships: no groups