La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol1/44Marco Sommani– Il SessionInitiationProtocol Il SessionInitiationProtocol Marco.

Presentazioni simili


Presentazione sul tema: "GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol1/44Marco Sommani– Il SessionInitiationProtocol Il SessionInitiationProtocol Marco."— Transcript della presentazione:

1 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol1/44Marco Sommani– Il SessionInitiationProtocol Il SessionInitiationProtocol Marco Sommani CNR-IIT, Pisa GARR-WS9, Roma

2 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol2/44Marco Sommani– Il SessionInitiationProtocol SIP SIP (SessionInitiationProtocol) è un protocollo utilizzato per iniziare, modificare o terminare sessioni fra uno o più partecipanti. (RFC 3261) permette ai partner di scoprire i rispettivi indirizzi e portnumber permette ai partner di concordare le modalità con cui scambiarsi i dati sessioni multimediali, ma anche chat, condivisione della lavagna ed altro Dove possibile, si appoggia su altri standard IETF: Le modalità con cui scambiarsi i dati vengono concordate trasportando allinterno dei messaggi SIP informazioni SDP (SessionDescriptionProtocol, RFC 3227) Per gli indirizzi si usano gli UniformResourceIdentifiers (URI, RFC 3986): -- sip: ==> trasporto UDP o TCP -- sips: ==> trasporto TLS Per il traffico multimediale si usa di preferenza RTP (RFC 3550, 5506)

3 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol3/44Marco Sommani– Il SessionInitiationProtocol Gli RFC 326x (giugno 2002) 3261 SIP: Session Initiation Protocol lRFCprincipale. InsiemeaglialtrirendeobsoletolRFC Reliability of Provisional Responses in Session Initiation Protocol (SIP) 3263 Session Initiation Protocol (SIP): Locating SIP Servers come individuareil next-hop a cui inviare la richiesta 3264 An Offer/Answer Model with Session Description Protocol (SDP) come utilizzareilprotocollo SDP in combinazione con il SIP 3265 Session Initiation Protocol (SIP)-Specific Event Notification definisce le richiesteopzionaliSUBSCRIBEe NOTIFY Aggiornamenti negli RFC 3835, 4320, 4916 e 5393

4 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol4/44Marco Sommani– Il SessionInitiationProtocol Messaggi SIP SIP si basa su transazioni in cui entità dette UserAgents (UA) si scambiano messaggi ASCII Una transazione inizia con una Requestinviata da uno UserAgent Client (UAC) ad uno UserAgent Server (UAS) e termina con una FinalResponse inviata in senso inverso la FinalResponse può essere preceduta da una o più ProvisionalResponses la Request ACK non prevede risposte I messaggi possono transitare attraverso uno o più Proxy Server La prima riga di una Requestcontiene il nome del metodo usato nella transazione es: INVITE, CANCEL, ACK, BYE, REGISTER, OPTIONS... La prima riga di una Responsecontiene un codice di stato codici 1xx: ProvisionalResponses codici 2xx, 3xx, 4xx, 5xx, 6xx: FinalResponses La prima riga dei messaggi è seguita da un certo numero di Headers Lultimo Header è seguito da una riga vuota, dopo la quale può essere presente il message body (es.: SDP)

5 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol5/44Marco Sommani– Il SessionInitiationProtocol Request URI Request BYE: BYE SIP/2.0 Via: SIP/2.0/UDP ;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob ;tag=a6c85cf To: Alice ;tag= Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Final ResponseallaRequest BYE: SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bKnashds10 From: Bob ;tag=a6c85cf To: Alice ;tag= Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Esempioditransazione SIP

6 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol6/44Marco Sommani– Il SessionInitiationProtocol La SIP URI Identifica le entità SIP: le indicazionisuportae/otrasportosonoconsentite solo se la domain- partidentifica un particolare host: fully qualified domain namepresentenel DNS con record A o AAAA indirizzo IPv4 o IPv6 la domain-partpuòancheindicare un dominio SIP, convertibile in indirizzoditrasportoconsultandoi record NAPTR e SRV del DNS La URI prendeilnomedi: contact-address (indirizzoreale): se permettediricostruiregliindirizziditrasportodellentità SIP stessa address-of-record (indirizzopubblico): se permettediricostruiregliindirizziditrasportodi un server in gradodilocalizzarelentità SIP

7 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol7/44Marco Sommani– Il SessionInitiationProtocol Sessioniedialoghi La sessioneè un flussodidati, generalmentemultimediali, unidirezionaleobidirezionale, controllatoda due UA SIP due UA SIP concordano le sessioniscambiandomessaggi SDP trasportati come message-bodyneimessaggi SIP per attivare la sessione un UA invia un messaggio SDP diOfferelaltrorisponde con un Answer caso 1: Offernella INVITE RequesteAnswer in unaResponse caso 2: Offer in unaResponseeAnswernella ACK Request Il dialogoèunaassociazionelogicafra due UA SIP, chevieneattivataodisattivata per mezzo ditransazioni SIP non tutte le transazioni SIP fanno parte di un dialogo Gliscambidiinformazioni SDP relative allesessioniavvengonofra UA chehannoattivatoostannoattivando un dialogo

8 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol8/44Marco Sommani– Il SessionInitiationProtocol Dialogo con negoziazionedisessioni INVITE B 100 Trying 183 Session Progress 180 Ringing + SDP Offer 200 OK ACK B + SDP Answer AB INVITE A + SDP Offer 200 OK + SDP Answer BYE A 200 OK Established Dialog Early Dialog ACK A

9 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol9/44Marco Sommani– Il SessionInitiationProtocol Metodi SIP LRFC 3261 definisce i seguenti metodi: RFC successivi hanno introdotto altri metodi: es.: SUBSCRIBE, NOTIFY, INFO, UPDATE, MESSAGE,.... INVITEinizia dialoghi con le relative sessioni o modifica le sessioni di un dialogo già iniziato ACKsegue immediatamente la transazione INVITE (non è seguita da Response) BYEtermina un dialogo e tutte le sessioni associate al dialogo CANCELcancella una Requestpendente (generalmente INVITE) REGISTERcomunica a un SIP registrar uno o più contact-addresses da associare ad un address-of-record OPTIONSrichiesta di informazioni su funzionalità e stato

10 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol10/44Marco Sommani– Il SessionInitiationProtocol Elementi architetturali del SIP UserAgent Client (UAC) entità che genera le Request UserAgent Server (UAS) entità che riceveRequeste può generareResponseper accettarle, respingerle o indirizzarle altrove. Registrar Server tipo speciale di UAS che accetta leRequestREGISTER e memorizza le informazioni in esse contenute in un location service Proxy Server entità che instrada leRequestverso gli UAS e leResponseverso gli UAC può rispondere direttamente ad unaRequest(in tal caso opera come UAS) può rimpiazzare la Request URI con una nuova servendosi di informazioni configurate staticamente consultando il location service di un registrar server, spesso co-locato consultando il DNS (ENUM)

11 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol11/44Marco Sommani– Il SessionInitiationProtocol SIP: esempio di registrazione 1. Il client SIP invia una RequestREGISTER a registrar.biloxi.com 2. Il SIP registrar associa la URI del Contact: alladdress-of-record presente nellHeaderTo: 3. Il SIP registrar risponde al client SIP comunicando la lista dei contact-addressassociati SIP client SIP Registrar Location Database REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob From: Bob ;tag= Call-ID: CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060; branch=z9hG4bKnashds7;received= To: Bob ;tag=2493k59kd From: Bob ;tag= Call-ID: CSeq: 1826 REGISTER Contact: ;expires=7200, ;expires=1320 Content-Length: registrar.biloxi.com

12 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol12/44Marco Sommani– Il SessionInitiationProtocol Attivazione di dialogo via SIP Proxy 1. lUAC di A invia una INVITE al SIP Proxy grossaditta.it (lindirizzo di trasporto viene ricavato dal DNS) SIP Proxy di grossaditta.it Location Database User Agent BUser Agent A audio INVITE SIP/2.0 Via: SIP/2.0/UDP :5060;.... To: From: Call-ID: ccc... CSeq: 1 INVITE Contact: Il SIP proxy cerca nel location database i contact- address associati alladdress-of-recordpresente nella Request URI: 3. Il SIP proxy inoltra lINVITE allunico contact-address di B trovato nel location database: INVITE SIP/2.0 Via: SIP/2.0/UDP :5060;.... Via: SIP/2.0/UDP :5060;.... To: From: Call-ID: ccc... CSeq: 1 INVITE Contact: 4. Quando lutente B alza la cornetta, lUAS di B invia una Response 200 OK, che raggiunge lUAC di A, transitando da tutti gli hop presenti nei Via: Header. Lo UserAgent A apprende dalla Response il contact-address dello UserAgentB SIP/ OK Via: SIP/2.0/UDP :5060;.... Via: SIP/2.0/UDP :5060;.... To: From: Call-ID: ccc... CSeq: 1 INVITE Contact: 5. LUAC di A invia un ACK allUAS di B mandandolo direttamente al contact-addresspresente nel Contact: Header della FinalResponse ACK SIP/2.0 Via: SIP/2.0/UDP :5060;.... To: From: Call-ID: ccc... CSeq: 1 ACK Le sessioni audio/video fluiscono come concordato nella negoziazione SDP

13 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol13/44Marco Sommani– Il SessionInitiationProtocol Riga inizialedella Request (Request URI) domain-part =dominio SIP locale processare la Requestlocalmente, eventualmentesostituendo la Request URI domain-part dominio SIP locale in mancanzadiHeader Route:, la domain-part dellaRequest URI indicailnext-hop Route:Il primo Header Route: indicailnext-hop dellaRequest Chi riceveunaRequestcancellail primo Header Route: se la suadomain-partè un dominio SIP locale From:IdentificaloriginatoredellaRequest Dovrebbegiungereimmutato al destinatario To:Mostra al destinatariodella Request quale era la URI originaria La URI dovrebbegiungereimmutata al destinatario Nel REGISTER contieneladdress-of-record da (de)registrare Contact:Nelle INVITE il campo èusatodaciascun UA per comunicareilpropriocontact-addressper le successive Request del dialogo Non dovrebbeesseremodificato (eccezione: indirizzi NAT-tati) SIP URI neidiversicampideimessaggi

14 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol14/44Marco Sommani– Il SessionInitiationProtocol Ancora sui dialoghi Un dialogoèidentificatoda Call-ID:, tag del From: etag del To: LUAC mettenellaRequest inizialeil Call-ID eiltag del From: LUAS metteiltag del To: nella prima Responsediversada 100 Trying OgniProxy intermediopuòinserirenellaRequestiniziale un Header Record-route: contenente la propria URI LUAS chericeveunaRequestinizialedeve: memorizzare le URI dei Record-route: per costruire la listadei Route: dainserirenelle successive richieste del dialogo copiaretuttii Record-route, così come eranopresentinellaRequest, nellaFinal Responsecherendeildialogoestablished (codice 2xx) LUAC chericeve la Final Response deve: memorizzare in ordineinverso le URI dei Record-route per costruire la listadei Route: dainserirenelle successive richieste del dialogo

15 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol15/44Marco Sommani– Il SessionInitiationProtocol Route: e Record-route: al lavoro UA A Proxy XProxy Y UA B INVITE Via: A Contact: A INVITE Record-route: X;lr Via: X Via: A Contact: A INVITE B Record-route: Y;lr Record-route: X;lr Via: Y Via: X Via: A Contact: A A Y;lr X;lr 200 OK Record-route: Y;lr Record-route: X;lr Via: Y Via: X Via: A Contact: B 200 OK Record-route: Y;lr Record-route: X;lr Via: X Via: A Contact: B 200 OK Record-route: Y;lr Record-route: X;lr Via: A Contact: B B X;lr Y;lr ACK B Route: X;lr Route: Y;lr Via: A ACK B Route: Y;lr Via: X Via: A ACK B Via: Y Via: X Via: A BYE A Via: X Via: Y Via: B BYE A Route: X;lr Via: Y Via: B BYE A Route: Y;lr Route: X;lr Via: B

16 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol16/44Marco Sommani– Il SessionInitiationProtocol Il Forking Quando un SIP Proxy riceveunaRequest in cui la domain- partdellaRequest URIindicaildominio locale, determina la nuovaRequest URI a cui inoltrareilmessaggio consultandoilLocation Database usandoaltrimeccanismi (es.: ENUM) Se le nuoveRequest URIsonopiùdiuna, il Proxy invia a ciascunaunacopiadellaRequest: ha luogoilForking Il Proxy cercadi fare in modochelUACriceva solo unaFinal Response (massimo un established dialogue) Prima dellaFinal Response, lUACpuòricevereProvisional Responsesdapiù UAS, con conseguenteattivazionedipiùearly dialogues

17 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol17/44Marco Sommani– Il SessionInitiationProtocol Forking: trattamento delle Response sul Proxy Response code Azioni 100La Response siferma al Proxy 1xx 100La Responseprosegue verso lUAC 2xxLa Response prosegue verso lUAC il Proxy inviauna CANCEL a tuttigli UAS che non hannoancorainviatounaFinal Response 3xx, 4xx, 5xx, 6xx Vengonoconservatedal Proxy fino a quando: arrivauna 2xx tutte le altreFinal Response in cache sono eliminate tuttigli UAS hannoinviatounaFinal Response diversada 2xx il Proxy deveinviareunaFinal ResponseallUAC, scegliendolafraquellericevute scade un timeout allUACvieneinviatauna 408 Request Timeout eagli UAS che non hannorispostouna CANCEL

18 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol18/44Marco Sommani– Il SessionInitiationProtocol Forking con Response 200 OK INVITE xxx 100 Trying 180 Ringing AB 200 OK CProxy INVITE B INVITE C 100 Trying 180 Ringing 200 OK CANCEL C ACK B 200 OK 487 Req Terminated ACK C

19 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol19/44Marco Sommani– Il SessionInitiationProtocol Forking con Response negative INVITE xxx 100 Trying 183 in Progress AB 486 Busy Here CProxy INVITE B INVITE C 100 Trying 183 in Progress 180 Ringing 408 Req Timeout ACK xxx 408 Req Timeout 183 in Progress ACK B ACK C

20 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol20/44Marco Sommani– Il SessionInitiationProtocol Le Final Response con codice 3xx Con la Response 3xx lUASsuggerisceallUACunalistadidestinazioni (URI) alternative le URI alternative sonoinviatenellHeader Contact: dellaResponse Lo standard lasciaallUACampielibertàdisceltasu come utilizzare le informazionicontenutenel Contact: inviare la Request a tutte le nuove URI contemporaneamente inviare le Request in successione mostrareidestinatariallutenteumano (display del telefono, messaggiovocale...) non fare niente Talvoltai Proxy creanolorostessi le Response 3xx cosìfacendosicomportanoda UAS e non da Proxy

21 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol21/44Marco Sommani– Il SessionInitiationProtocol Forking con Response 3xx INVITE xxx 100 Trying AB 302 Moved Temp Contact: X CProxy INVITE B INVITE C 100 Trying 302 Moved Temp Contact: Y ACK xxx 302 Moved Temp Contact: X Contact: Y ACK B ACK C

22 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol22/44Marco Sommani– Il SessionInitiationProtocol HTTP Authentication (1 di 2) LRFC 3261 dà la possibilitàai Proxy edagli UAS diaccettareRequest solo se lUACfornisce le sue credenziali Il meccanismousato in SIP imita la Digest Access Authentication dellHTTP (RFC 2617) Ad unaRequest con credenzialimancanti, invalideoscadutesirisponde con 401 Unauthorized + Header WWW-Authenticate: (caso UAS) 407 Proxy Authentication Required + Header Proxy-Authenticate: (caso Proxy) EntrambigliHeader x-Authenticate: comunicanoallUAC ilrealmdi chi chiedelautenticazione un nonce per calcolare la Digest Authentication Response

23 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol23/44Marco Sommani– Il SessionInitiationProtocol HTTP Authentication (2 di 2) LUAC chericeveunaResponse 401 o 407 puòrinunciareoripetere la Requestaggiungendo un Header Authorization: o Proxy-Autorization contenente ilnome del realm per cui siforniscono le credenziali lo username chelUACpossiede in quelrealm la Request URI dellaRequest Il noncericevutoda chi ha inviato la challenge Unastringadi 32 caratteriesadecimali, detta Digest Authentication Response, calcolata a partiredaivalorideglialtriparametriedalla password dellousername In tutte le successive RequestinviateallostessodestinatariolUAC continua ainseriregliHeader Authorization e Proxy-Authorization finoallaricezionediunanuovachallenge

24 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol24/44Marco Sommani– Il SessionInitiationProtocol Proxy-Authenticate / Proxy-Authorization DallUAC parte la Request: INVITE SIP/2.0 Il Proxy bh3.iit.cnr.it risponde con un: SIP/ Proxy Authentication Required NellaResponse 407 cèilseguenteHeader: Proxy-Authenticate: Digest realm="bh3.iit.cnr.it", nonce="4a210e6c d1e916f211827b1084f2c330" Nelle successive Requestdiretteallastessadestinazione: Proxy-Authorization: Digest username="8327,realm="bh3.iit.cnr.it", nonce="4a210e6c d1e916f211827b1084f2c330", response="129ceed44ef731662acac6f01574e080,algorithm=MD5

25 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol25/44Marco Sommani– Il SessionInitiationProtocol HTTP Authentication: flussodeimessaggi INVITE A B 407 Proxy Authentication Required Proxy-Authenticate: realm=X,nonce=aaaa Proxy X INVITE INVITE B 401 Unauthorized WWW-Authenticate: realm=B,nonce=cccc 401 Unauthorized WWW-Authenticate: realm=B,nonce=cccc INVITE INVITE B

26 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol26/44Marco Sommani– Il SessionInitiationProtocol Indirizzo di trasporto di un SIP domain Se la domain-part della RequestURI è un SIP domain, le infomazioni per determinare lindirizzo di trasporto del next-hop a cui inviare la Request si trovano su record DNS di tipo SRV La chiave (nome a dominio) del record SRV da cercare si ottiene così: chiedere al DNS i record con dominio uguale alla domain-part e con tipo NAPTR e fra questi scegliere quelli con campo service uguale a: SIP+D2U se come trasporto si vuole usare UDP SIP+D2T se si vuole usare TCP SIPS+D2T se si vuole usare TLS in caso di successo, la chiave si trova nel campo replacement del NAPTR altrimenti, il nome a dominio del record SRV si costruisce anteponendo alla domain-partle stringhe: _sip._udp. per il trasporto UDP, _sip._tcp. per TCP, _sips._tcp. per TLS In mancanza di SRV, la domain-part della URI è un nome a dominio del next-hop stesso (cercare A e/o AAAA)

27 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol27/44Marco Sommani– Il SessionInitiationProtocol Record SRV I record SRV (RFC 2782) hanno la seguente forma: Domain TTL Class SRV Priority Weight Port Target _sip._udp.bigu.edu IN SRV proxy.bigu.edu. Domainè la chiave (nome a dominio) del Resource Record SRVèiltipodi record in esame Priorityè la priorità: 10. Nelcasodipiù record SRV indicalordinediinterrogazione (prima ipiùbassi) Weightèil peso: 10. Nelcasodipiù record SRV con stessapriorità, indica la frequenza con cui vautilizzato. Portè la porta: Targetèilnome a dominio del next-hop: proxy.bigu.edu.

28 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol28/44Marco Sommani– Il SessionInitiationProtocol Formato del record NAPTR Il record NAPTR ha molteplici usi ed è descritto nello RFC 3403 I campi usuali Domain TTL Class NAPTR sono seguiti da altri 6 campi: orderpreferenceflagsservicesregexpreplacement I primi due sono numeri, gli altri stringhe racchiuse fra regexp e replacement sono mutuamente esclusivi con flags = s cè solo il campo replacement con flags = u cè solo il campo regexp al posto di un campo stringa assente ci vuole un punto Nei record contenenti le chiavi per la ricerca dei record SRV servicesèSIP+D2x o SIPS+D2x, dove possibili valori di x sono U o T il campo flags ha il valore s Esempi di NAPTR con chiavi di record SRV: example.com. IN NAPTR "s" "SIPS+D2T". _sips._tcp.example.com. example.com. IN NAPTR "s" "SIP+D2T". _sip._tcp.example.com. example.com. IN NAPTR "s" "SIP+D2U". _sip._udp.example.com.

29 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol29/44Marco Sommani– Il SessionInitiationProtocol Esempio di ricerca come da RFC 3263 Devo mandare una INVITE a Chiedo al DNS i NAPTR per iit.cnr.it e ottengo: iit.cnr.it. 300 IN NAPTR "s" "SIP+D2T". sip_tcp.iit.cnr.it. iit.cnr.it. 600 IN NAPTR "s" "SIP+D2U". sip_udp.iit.cnr.it. Siccome voglio usare UDP, scelgo il secondo record Chiedo al DNS i record SRV per sip_udp.iit.cnr.it e ottengo: sip_udp.iit.cnr.it IN SRV bh3.iit.cnr.it. Ora so che il next-hop della richiesta è la porta 5060 del server bh3.iit.cnr.it In mancanza del record NAPTR, avrei cercato il record SRV con nome _sip._udp._iit.cnr.it. In mancanza dei record SRV, avrei tentato di mandare la richiesta alla porta 5060 di un host di nome iit.cnr.it, sperando di trovarlo

30 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol30/44Marco Sommani– Il SessionInitiationProtocol SIP in presenza di NAT e firewall Non esistono soluzioni universali per risolvere il problema dellattraversamento dei firewall come minimo, è sempre necessaria la cooperazione del gestore del firewall Nellottobre 2008 èuscitolRFC 5389 Session Traversal Utilities for NAT (STUN), cherendeobsoletoilprecedente RFC 3489 echeèstatopensato per risolvereilproblemadellattraversamentodei NAT Siccome la maggior parte degli UserAgent attuali sono conformi al vecchio RFC, nel seguito si fa riferimento a quello lLRFC 3489 permette a uno UserAgent di comunicare correttamente anche trovandosi su una rete con indirizzi privati, purché il NAT sia del tipo detto a cono pieno (full cone NAT) il Client si attenga a procedure ben precise

31 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol31/44Marco Sommani– Il SessionInitiationProtocol NAT a cono pieno Il mapping fra la coppia privata (X,y) e la pubblica (A,b),è lo stesso per tutti i partner pubblici di (X,y) Il NAT passa a (X,y) qualunque pacchetto TCP o UDP destinato a (A,b) Quasi tutti i router per uso domestico e quelli usati nei WiFiHotspot sono NAT a cono pieno N.B.: in caso di saturazione delle tabelle di mapping, il comportamento del NAT è imprevedibile e sono possibili malfunzionamenti

32 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol32/44Marco Sommani– Il SessionInitiationProtocol Requisiti per il Client SIP Uno UserAgentSIP a valle di un NAT a cono pieno, opera correttamente se: è in grado di interrogare un server STUN (RFC 3489) per conoscere il mapping esterno delle porte su cui è in ascolto usa il parametro rport nellHeader Via:, come da RFC 3581 usa come source port per i flussi RTP da lui prodotti le stesse porte su cui intende ricevere i flussi del partner completata la negoziazione SDP, emette costantemente i flussi RTP se vuole ricevere Request, mantiene attivo sul NAT il mapping della porta su cui il suo UAS sta in ascolto, inviando al Registrar e/o al Proxy messaggi di keepalive (tipicamente uno ogni 20 secondi) Anche in presenza di tutti i requisiti, non è garantita la consegna del flusso RTCP, inviato alla porta RTP+1

33 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol33/44Marco Sommani– Il SessionInitiationProtocol Attraversamento NAT: STUN e rport (1 di 2) INVITE SIP/2.0 Via: SIP/2.0/UDP :7498;branch=z9hG4bK-d ef1c0daa6b0d-1--d87543-;rport Max-Forwards: 70 Contact: To: "662127" From: "Marco Sommani" ;tag=64fb0350 Call-ID: MmFjMmEzNTRmYWYxMWZiZDE3ODM5ZTc0OGFhOTA3MTU. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: eyeBeamrelease 1010i stamp Authorization: Digestusername="3827",realm="bh3.iit.cnr.it",nonce=" Content-Length: 394 v=0 o=- 62 IN IP s=CounterPatheyeBeam 1.5 c=IN IP t=0 0 m=audio RTP/AVP a=x-rtp-session-id:20EA85E324FA73EF6C6D97075C a=fmtp:18 annexb=yes a=fmtp: a=rtpmap:100 SPEEX/16000 a=rtpmap:106 SPEEX-FEC/16000 a=rtpmap:105 SPEEX-FEC/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=sendrecv SDP

34 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol34/44Marco Sommani– Il SessionInitiationProtocol Attraversamento NAT: STUN e rport (2 di 2) SIP/ OK Via: SIP/2.0/UDP :7498;received= ;branch=z9hG4bK-d ef1c0daa6b0d-1--d87543-;rport=12345 Record-Route: From: "Marco Sommani" ;tag=64fb0350 To: "662127" ;tag=as34a82cc4 Call-ID: MmFjMmEzNTRmYWYxMWZiZDE3ODM5ZTc0OGFhOTA3MTU. CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: Content-Type: application/sdp Content-Length: 263 (v): 0 (o): root IN IP (s): session (c): IN IP (t): 00 (m): audio RTP/AVP (a): rtpmap:8 PCMA/8000 (a): rtpmap:0 PCMU/8000 (a): rtpmap:3 GSM/8000 (a): rtpmap:101 telephone-event/8000 (a): fmtp: (a): silenceSupp:off SDP

35 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol35/44Marco Sommani– Il SessionInitiationProtocol SIP URI e utente umano Spesso lutente umano non fornisce una Request URI, ma solo un identificatore (numero di telefono, username...) In questi casi lUAC costruisce una URI appendendo allidentificatore fornito seguito da un sip domain name, se configurato nel client altrimenti lindirizzo e la porta del Proxy es.: lutente digita , e lUAC crea la Request URI: (sip domain name) (indirizzo e porta del Proxy) La Request URI deve essere fornita dallutente stesso quando il Client lavora in modalità SIP Direct (senza Outbound Proxy)

36 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol36/44Marco Sommani– Il SessionInitiationProtocol A cosa serve ENUM ENUM (rfc3761) stabilisce come usare il DNS per costruire degli Universal ResourceIdentifiers (URI, rfc3986) partendo da numeri E.164 Esempio partire dal numero (ApplicationUniqueString o AUS) chiedere al DNS i record NAPTR relativi al FQDN (FullyQualified Domain Name) e164.arpa costruire gli URI scegliendo fra i NAPTR ricevuti il migliore fra quelli relativi alla applicazione ENUM e che corrispondono alla AUS ed al servizio desiderato (sip, h323, http, mail, address,....)

37 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol37/44Marco Sommani– Il SessionInitiationProtocol Record NAPTR (rfc3403) A destra della keyword NAPTR ci sono 6 campi: orderpreferenceflagsservicesregexpreplacement I primi due sono numeri, gli altri stringhe racchiuse fra regexp e replacement sono mutuamente esclusivi Al posto di un campo stringa assente ci vuole un punto Nellapplicazione ENUM i services, se presenti, hanno la forma E2U+servizi i flags, se presenti, hanno il valore u Negli usi pratici di ENUM, flags, services e regexpsono presenti e replacementè assente

38 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol38/44Marco Sommani– Il SessionInitiationProtocol Uso di regexp con flags=u Il campo regexp è composto da due sottocampi (ere e repl) delimitati dallo stesso carattere (generalmente !) e opzionalmente seguiti da i La regexp, applicata al numero E.164 originario (AUS o ApplicationUniqueString), fornisce lURI Esempio: da e si ottiene lURI Un eventuale carattere i dopo il terzo delimitatore indica che la regular expressionpuò matchare la AUS in modalità case insensitive

39 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol39/44Marco Sommani– Il SessionInitiationProtocol Esempi di record NAPTR (1 di 2) ;; QUESTION SECTION: ; e164.org. IN NAPTR ;; ANSWER SECTION: e164.org. 403 IN NAPTR "u" "E2U+ADDRESS" "!^.*$!ADDRESS:CN=MarcoSommani\;STREET=Via Giuseppe Moruzzi 1\;L=Pisa\;ST=Pisa\;C=Italy!" e164.org. 403 IN NAPTR "u" "E2U+SIP" e164.org. 403 IN NAPTR "u" "E2U+ " ;; QUESTION SECTION: ; e164.namex.it. IN NAPTR ;; ANSWER SECTION: e164.namex.it INNAPTR "u" E2U+sip"

40 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol40/44Marco Sommani– Il SessionInitiationProtocol Esempi di record NAPTR (2 di 2) ;; QUESTION SECTION: ; e164.namex.it. IN NAPTR ;; ANSWER SECTION: e164.namex.it INNAPTR "u" "E2U+SIP" ;; QUESTION SECTION: ; e164.arpa. INNAPTR ;; ANSWER SECTION: e164.arpa. 600 INNAPTR "u" "E2U+sip" e164.arpa. 600 INNAPTR "u" "E2U+h323" ;; QUESTION SECTION: ; freenum.org.INNAPTR ;; ANSWER SECTION: freenum.org. 60INNAPTR "u" "E2U+sip" freenum.org. 60INNAPTR "u" "E2U+iax2" freenum.org. 60INNAPTR "u" "E2U+web:http:" "!^.*$!http://www.loligo.com/!".

41 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol41/44Marco Sommani– Il SessionInitiationProtocol Funzioni di un ENUM resolver Generalmente un ENUM resolverè una procedura che riceve in input un numero E.164, il nome del servizio desiderato e il nome del sottoalbero DNS in cui fare la ricerca restituisce, se esiste, lURI per il servizio desiderato ENUM resolvers sono presenti nei server VoIP più evoluti (SER, OpenSer, Asterisk, GnuGK,...) ENUM resolvers possono essere inclusi anche negli apparati VoIP terminali i telefoni SNOM (http://www.snom.com/) sono in grado di consultare ENUMhttp://www.snom.com/

42 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol42/44Marco Sommani– Il SessionInitiationProtocol ISN: una numerazione alternativa Gli Internet SubscriberNumbers (ISN, sono una numerazione controllata da IANA anziché dalla ITU Hanno la forma mmmmmm*nnnn. Il numero a destra del * si chiama Internet TelephonyAdministrative Domain (ITAD) Gli ITAD usabili per ISN sono numeri compresi fra 256 e Sono assegnati da IANA a chi ne fa richiesta. Al GARR è stato assegnato lITAD 400 Le ricerche ENUM relative a numeri ISN si fanno cercando il numero mmmmmm sullalbero nnnn.freenum.org Esempio. Per cercare gli URI relativi al numero 1234*256 si richiedono i NAPTR di freenum.org

43 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol43/44Marco Sommani– Il SessionInitiationProtocol Lalbero nrenum.net Per sviluppare progetti coordinati facenti uso della tecnologia ENUM senza attendere la piena funzionalità del goldentree, le National Research and EducationNetworks (NREN) hanno attivato lalbero nrenum.net Lintendimento è che nrenum.net sia consultato solo se fallisce la consultazione di e164.arpa LaName Server primario di nrenum.net è gestito da Switch (NREN svizzera), su incarico di TERENA Le radici dei sottoalberi nazionali sono delegate alle NREN Il sito del progetto è Il GARR (NREN italiana) controlla il sottoalbero 9.3.nrenum.net

44 GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol44/44Marco Sommani– Il SessionInitiationProtocol Il SessionInitiationProtocol Marco Sommani CNR-IIT, Pisa GARR-WS9, Roma Fine


Scaricare ppt "GARR-WS9, 15 giugno 2009Marco Sommani – Il Session Initiation Protocol1/44Marco Sommani– Il SessionInitiationProtocol Il SessionInitiationProtocol Marco."

Presentazioni simili


Annunci Google