Gruppe 3 (ITM30408)
Fra Hiofwiki
Hjemmeside for gruppe 3
- Oblig 4 (les under)
Her kommer et sammendrag av SIP-presentasjonen vår:
INTRODUKSJON
SIP er en protokoll på applikasjons laget som brukes til og sette opp, endre og avslutte en forbindelse mellom to noder. En slik forbindelse kalles en sesjon. En slik sesjon kan typisk inneholde lyd, bilde eller annet multimedia innhold. Da SIP befinner seg på applikasjonslaget er den også designet for og være uavhengig av det underliggende transport laget, noe som vil si at den kan kjøres på både TCP og UDP.
SIP er basert på en HTTP liknende request/response modell. I all enkelhet betyr det at det først sendes en request til en node, mens noden som mottar denne requesten sender et svar tilbake til denne avsenderen. Disse requestene og responsene er i likhet med HTTP tekstbaserte som gjør de lesbare.
SIP brukes vanligvis til og opprette en forbindelse for overføring av lyd og eventuelt bilde mellom 2 brukere. SIP brukes i de aller fleste tilfeller sammen med andre eksisterende protokoller, dette fordi den bare er involvert i signalflyten mellom nodene i sesjonen. SDP (Session description protocol) brukes for og beskrive innholdet man ønsker og sende, f.eks hviken codec som brukes. For og bære mediestrømmen er det RTP protokollen som blir brukt. Denne RTP strømmen er en direkte link mellom de 2 nodene som "snakker" sammen.
SIP har 5 funksjoner for oppretting og avslutting av en "samtale":
• Bruker lokasjon • Bruker tilgjengelighet • Bruker muligheter/opsjoner • Sesjon oppsett (ringing) • Sesjon endring(endre parametre, avslutte samtalen)
SIP er en peer-to-peer protokol og krever dermed veldig lite sentralisering og er veldig skalerbar. Men for at et SIP nettverk skal fungere i praksis er det avhengig av proxy servere. Disse proxy serveren hjelper blant annet til med og rute requests som f.eks INVITE til den riktige brukeren.
Det vanligste stedet og møte SIP protokollen i bruk er i IP-Telefoni og VoIP sammenheng, det finnes mange løsninger for disse områdene som tar i bruk SIP, en av disse løsningene er Asterisk som vi fikk en kort innføring i på gjesteforelesningen.
FORFATTERE
Henning Schulzrinne - Columbia U.
Professor and Chair in the Dept. of Computer Science; also with the Dept. of Electrical Engineering at Columbia University (Contact Info) Hans research interesser er Internet real-time og multimedia services og protocols, mobile systemer, modelering og analyse av computer-communication nettverk, opperativ systemer, network sikkerhet.
Jonathan Rosenberg - dynamicsoft
Han jobbet tidligere i Service Provide Technology gruppen som satt direktiver for for VoIP produkter. Før det var han sjef over Dynamicsoft, som er en softwarebedrift.
Gonzalo Camarillo - Ericsson
Han jobber i Advanced Multimedia Research Laboratory, som er en del av NomadicLab, hos Ericsson i Finland. Hans research interesser er blant annet signallering, multimedia applications, transport protocols, og nettverk sikkerhet.
A. Johnston - WorldCom
For en tid var Worldcom (WCOM) USA´s andre største long distance telefonselskap (AT&T var det største).
J. Peterson - Neustar
Neustar er en ledende forsørger av nødvendig clearinghouse tjenester til kommunikasjon- og internettindustriene. A clearing house is an institution that collects and distributes information. (Wikipedia)
R. Sparks - dynamicsoft
Dynamicsoft SIP stack var industriens ledende SIP protokollstack. Dynamicsoft SIP stack hadde tjent dets rykte som den meste scalable, robust og fleksibel SIP protokollstacken som da var tilgjengelig.
Mark Handley - ICIR
Han er forfatteren av 22 Internett standarddokument (RFCs), samt Session Initiation Protokollen (SIP), som er hovedmåten signalliseringen innen telefonien blir gjennomført i fremtidig Internett-Basert telefonnettverk.
E. Schooler - AT&T
AT&T er en av de største telekommunikasjonene selskapene i verdenen. Vi byr kommunikasjonsprodukter og tjenester som seg strekker fra hurtiginternetttilgang, wireless, avanserte IP og networking løsninger, hjem underholdning og lokal og lang avstandtjeneste.
ANATOMIEN I EN SIP-SESJON
INVITE - solfrid sender en forespørsel til lindi, med invitasjon om å være med i en samtale.
proxy server - ruter etterspørselen fra klienten (deg og meg) ved å videresende etterspørselen til alle servere. har en tabell som han slår opp i, og finner ut til hvilken server han skal sende forespørselen slik at den kommer fram til mottakeren som står i headeren. hjelper til med å opprette en session.
100 TRYING - jobber med saken.
180 RINGING - summetone.
200 OK - tar telefonen
ACK - Solfrid bekrefter at hun har fått svar på INVITE forespørselen. (bare 2xx meldinger)
RTP MEDIA SESSION IN PROGRESS - en strøm - samtalen pågår.
BYE - fjerner samtalen, legger på.
INVITE header
INVITE sip:lindi@hiof.no SIP/2.0
Via: SIP/2.0/UDP pc33.online.no;branch=z9hG4bKkj
To: Lindi <sip:lindi@hiof.no>
From: Solfrid <sip:solfrid@online.no>;tag=88sja8x
Max-Forwards: 70
Call-ID: 987asjd97y7atg
CSeq: 986759 INVITE
Disse header feltene er påbudt i alle SIP-forespørsler:
Via: Protokollens navn og versjon. en parameter som identifiserer transaksjonen. brukt av både client og server.
To: displaynavn som sees av den som mottar samtalen. Tagen er en generell mekanisme for å identifisere dialogen.
From: valgfritt display navn og en adresse. Dersom det ikke ligger med noe displaynavn, bør UAC bruke displaynavnet "Anonymous".
Max-Forwards: For å forhindre at en forespørsel går i loop et sted, og dermed kan henge seg opp. Det legges til en verdi som BØR være 70. for hvert "hopp" synker verdien med 1.
Call-ID: En unik identifikasjon til en gruppe sammen en serie av beskjeder. Denne må være den samme for alle forespørsler og svar sendt av de UA som er med i samtalen. Alle beskjeder som jeg og lindi sender til hverandre har den samme Call-ID.
CSeq: en måte å identifisere og bestille transaksjoner på. Inneholder et sequence nummer og en metode. Metoden må være lik den metoden CSeq er en del av.
RE-INVITE - dersom man har en telefonsamtale, men ønsker å også sende videooverføring i den samme samtalen, kan man sende en ny INVITE inne i den dialogen som allerede er oppe. dette kalles RE-INVITE. Dette kan man bare gjøre dersom det har blitt satt opp en suksessfull dialog mellom de to brukerne.
CANCEL - hvis jeg ønsker å avslutte forsøke på å få tak i lindi, før samtalen er satt opp, sender jeg en CANCEL.
OPTIONS - Spør etter hva en klient støtter, hvilken muligheter den har. f.eks hvilke metoder som er støttet, hvilken content type, codecer osv.
REGISTER - registrerer adressene i til-headeren i SIPserveren. legger de i den tabellen som slår opp adresser.
RESPONSKODER / STATUSKODER
1xx --> Prosessen i en etterspørselen 100 og oppover --> er testing ringing, progresjonen osv
2xx-meldingene sier OK. Den var mottatt, forstått og akseptert av mottakeren. --> sukess!
3xx --> Videresending. Hvis brukeren bestemmer seg for å videresende.
3xx --> gir informasjon om brukerens nye location, eller om alternative tjenester som kan friste.
F.eks:
300 --> Flervalg, "multiple choices". Adressen i etterspørselen fører til flere valg, som har hver sin spesielle adresse (location). Brukeren kan velge et ønsket kommunikasjons-end point (endepunktet) og fører etterspørselen til den adressen.
301 + 302 --> Brukeren kan ikke lenger bli funnet i den adressen som er i etterspørselen. flyttet permanent og flyttet midlertidig
4xx --> Klient error. Etterspørselen feilet. Etterspørselen inneholder feil eller mangler noe (dårlig syntaks), eller den ikke kan bli gjennomført på denne serveren.
4xx --> Klienten bør ikke prøve igjen med den samme etterspørselen uten å modifisere (f.eks. legge til passende autorisasjon). Men, den samme etterspørselen til en annen server kan gå ann.
F.eks:
- 401 --> Etterspørselen krever bruker-autentiikasjon.
- 403 --> Forbidden
- 404 --> Not found
5xx --> Server error. Severen klarte ikke å fullføre en tilsynelatende gyldig etterspørsel.
F.eks:
- 500 --> Indre Server Error . Serveren møter på en uventet tilstand som hindrer den fra å gjøre ferdig etterspørselen. Klienten KAN vise fram den spesielle erroren og KAN prøve etterspørselen på nytt etter noen sekunder.
6xx --> Globale feil. (Denne responsen indikerer at serveren har definitivt informasjon om en spesiell bruker, ikke bare en spesiell instans indikerer i etterspørsel-adressen.)
F.eks:
- 606 --> "Not acceptable". Brukeren ble suksessfult kontaktet, men noen problemer med beskrivelsen av session'en, som f.eks medien den skulle spilles i, båndvidden, gjorde at etterspørselen ikke ble godkjent. Det kan være at den ene parten ikke klarer å støtte den båndvidden som er beskrevet.
HISTORIEN
SIP dukket opp på midten av 1990-tallet. Av research fra Henning Schulzrinnes. Han hadde også med seg et research team of Associate Professor på Department of Computer Science på Columbia Universitetet.
Henning var en med-forfatter av RTP og RTSP --> - RTP (Real-time Transport Protocol) - overføring av realtime data via internett - RTSP (Real time streaming protocol) - kontrollering av streaming audio-visualt innhold over nettet.
Hennings hensikt var å definere en standard for Multiparty Multimedia Session Control (MMUSIC). I 1996 la han fram et forslag til IETF (Internet Engineering Task Force) som inneholdt nøkkel-elementene til SIP.
I 1999 fjernet Shulzrinne diverse komponenter angående media-innhold i en ny rapport, og IETF utga den første SIP spesifikasjonen, RFC 2543.
Mens noen selgere utrykket bekymring for at lignende protokoller (som H.323 og MGCP) kunne risikere deres investeringer i SIP tjenestene, så fortsatte alikevell IETF deres arbeid og gav ut SIP-spesifikasjonen RFC 3261 i 2001.
Med RFC 3261 ble det signalisert at det fundamentale/grunnleggende var på plass. Siden det har det kommet flere forbedringer på områder som bl.a. har med sikkerhet, og autentisering å gjøre i flere RFC'er. F.eks: RFC 3262 - behersker reabiliteten av foreløpige responser RFC 3263 - lager regler for å lokalisere SIP proxy servere 3264 - offer/answer modell 3265 - bestemmer spesielle event notifications
Så tidlig som 2001, begynte selgere å lansere SIP-baserte tjenester. Entusiasmen for protokollen idag er økende.
PROTOKOLLER
SIP, PRIM OG APEX ER TRE PROTOKOLLER I IETF’S WORKING GROUP.
PRIM OG APEX er begge designet spesifikt for behovet for IM (instant messaging) hvor SIP vil trenge utvidelser for å oppnå de kravene IMPP working group krever.
UTVIKLING
ENUM ENUM står for ”T-e-lephone Nu-mber M-apping”. Bakgrunnen for denne ”forkortelsen” ligger i ønsket om å kunne være tilgjengelig med samme nummer verden over - og gjennom rimeligste og beste rute. - ENUM nyttig for utvikling av SIP Den konkrete planen er imidlertid å bruke ENUM til å legge telefontrafikk fra betalbar ISDN til IP-telefoni. – ENUM er et konvergensverktøy for å koble tradisjonell telefoni med IP-telefoni på en sømløs måte. Det fungerer som bindeledd mellom SIP-infrastrukturen (SIP infrastruktur. SIP-brukere trenger tjenere eller proxy'er for å registrere seg og tjeneren vil formidle hvor brukerne er. SIP er en lettvekts protokoll og krever ikke mye av tjenerene fordi den bare er i bruk i oppkoblingsfasen.) og telefonnummerstrukturen og gjør oss i stand til å foreta skalerbar ruting på en billig måte. Med ENUM er det slik at den enkelte registrerer seg selv i DNS.
ENUM kobler et telefonnummer opp mot en internett adresse som registreres i DNS-systemet. Eieren av et ENUM-nummer kan dermed offentliggjøre hvor samtaler skal rutes gjennom en DNS-oppføring. Dessuten er det mulig å opprette forskjellige ruter for forskjellige typer anrop - for eksempel en egen rute for faksmaskiner. ENUM krever imidlertid at den som utfører anropet støtter teknologien.
Et ENUM-nummer registreres på omtrent samme måte som et domene. Mange registratorer og tilbydere av VOIP-tjenester tilbyr i dag denne tjenesten uten ekstra kostnad.
ENUM er en ny standard, og er ikke fullt så utbredt enda, skjønt den ser ut til å kunne starte en ny revolusjon innen kommunikasjon og personlig mobilitet.
GigaCampus --- https://gigacampus.wiki.uninett.no/start---- Er et fireårsprosjekt fram mot 2009 som skal styrke og samordne campusnettetene slik at en høykapasitets infrastruktur blir tilgjengelig for sluttbrukere ved landets statlige universiteter og høgskoler. Flere av samarbeidspartnerne i GigaCampus-programmet ligger langt framme når det gjelder SIP-utvikling, med Universitetet i Oslo og Høgskolen i Agder i teten. UiO har for øvrig satt i gang et prosjekt for å vurdere nytt telefonisystem, noe som sannsynligvis vil ende med en SIP-infrastruktur. – Generelt har forskningsnettverdenen gode nett som ligger til rette for gratis telefonikontakt mellom forskere. 70 % av dagens telefonikostnader går over mobiltelefon. Ett av utviklingsprosjektene under GigaCampus er å få etablert en gratis, trådløs telefoniinfrastruktur på campus. Utfordringen er å lage en tjeneste av god nok kvalitet.
Mot 2009 Tre faser: 1. Den første fasen består i å transportere trafikk mellom telefonsentraler over IP, noe som allerede er igangsatt. 2. Neste fase blir å etablere ENUM-basert ruting over hele verden. 3. Til slutt står man overfor neste generasjon telefonsystemer, som trolig blir SIP-basert. Mest sannsynelig er man allerede der innen 2009. Det vil nok ta noe tid før den jevne sluttbruker merker endringene. Det første som skjer er at institusjonene vil merke at de sparer transportkostnader. Med en ny generasjon telefonsystemer vil det komme nye tjenester som berører all person-til-persontrafikk: e-post, telefoni, videokonferanse, lynmeldingstjeneste og kanskje helt nye tjenester.
Det kan tyde på at vi står ovenfor et paradigmeskifte på telefoniområdet. Tidligere var det telefonsentralene som var intelligente, nå er det telefonapparatene. Etter hvert vil enkle og billige SIP-sentraler ta helt over.
