SIP Session Initiation Protocol

SIP: Session Initiation Protocol “[…] an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.” (RFC 3261) Una sessione è uno scambio di dati tra un’insieme di partecipanti che ne concordano le caratteristiche Una telefonata è una sessione Una videoconferenza è una sessione Una partita in rete a Quake è una sessione Il download di un file NON è una sessione

SIP – Modello architetturale SIP è simile ad HTTP: Architettura client/server Modello request/response Codifica testuale BNF (Backus-Naur Form) Codici associati ai messaggi di risposta: 1xx: Informational 2xx: success 3xx: Redirection 4xx: Client error 5xx: server Failure 6xx: Global Failure Provisional Response Final Response

Entità SIP User Agent Client (UAC) User Agent server (UAS) Registrar Location Service Redirect server Proxy (Proxy server) Sono entità logiche: una particolare implementazione può combinarne alcune in un’unica applicazione

User Agent (Client e Server) User Agent Client: genera una nuova richiesta (es: INVITE) User Agent Server: genera una risposta ad una richiesta. La richiesta può essere accettata, rifiutata o affidata ad un’altra entità Trattandosi di entità logiche, user agent client e user agent server sono in realtà dei ruoli che uno user agent può ricoprire nel momento in cui (e limitatamente a quello) – rispettivamente – genera una nuova richiesta o genera la risposta ad una richiesta.

Registrar e Location Service Un Registrar Accetta richieste di tipo REGISTER provenienti da UAC Aggiorna di conseguenza i dati del Location Service Un Location Service Contiene i record relativi ai contatti di ogni utente Viene interpellato dai proxy o dai redirect server per sapere dove contattare un utente

Redirect e Proxy Server Un Redirect Server è un UAS che genera risposte al fine di indirizzare un UAC verso l’utente desiderato Un Proxy agisce in qualità di intermediario Ricopre entrambi i ruoli di server e di client allo scopo di effettuare richieste per conto di altri client Può essere di tipo stateless o di tipo stateful

Indirizzi SIP Simili ad indirizzi e-mail: sip:utente@dominio sip:Giuseppe.Podesta@laser.dist.unige.it Seguono le regole specificate per gli URI (Uniform Resource Identifier) nella RFC 2396

Messaggi SIP - tipologie Request – da client a server, contengono: un method type, identifica il tipo di richiesta un Request-URI, indica l’utente o il servizio a cui la richiesta è indirizzata Response – da server a client, contengono: uno status code, identifica il tipo di risposta una reason phrase, destinata ad un utente umano

Messaggi SIP - composizione Header intestazioni che compaiono in testa al messaggio, obbligatori Possono essere presenti più header dello stesso tipo L’ordine degli header può essere significativo Body il corpo del messaggio, facoltativo Può contenere la descrizione di una sessione JAIN SIP permette di utilizzare una stringa, un array di byte o qualsiasi oggetto definito nella specifica SDP

Transaction Lo scambio di messaggi può avvenire all’interno di un contesto transazionale SIP definisce delle transaction come l’insieme di una Request e di una o più Response relative alla Request Nel caso di più Response, l’ultima è final, mentre le altre sono dette provisional Alle transaction il protocollo associa macchine a stati finiti, che descrivono e regolano l’avanzamento dello stato

Client Transaction, Server Transaction Client e Server sono ruoli logici Client Transaction Invio di Request, ricezione di Response Server Transaction Ricezione di Request, invio di Response Un’unica applicazione può essere caratterizzata da entrambi i ruoli Es. un softphone si comporta da client quando effettua chiamate e da server quando le riceve

Un’altra entità SIP che ha entrambi i ruoli Request Request Response Response

INVITE CLIENT TRANSACTION INVITE SERVER TRANSACTION

Metodi REGISTER INVITE ACK BYE CANCEL OPTIONS INFO

Messaggi SIP – una Request INVITE INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 <body non mostrato>

Messaggi SIP – una Response 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com; branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com; branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com; branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 <body non mostrato>

Registrazione (REGISTER)

Chiamata (Redirect Mode) Manca il “180 ringing” e il teardown della connessione mediante BYE.

Chiamata (Proxy Mode) Manca il “180 ringing” e il teardown della sessione mediante BYE.

SIP+SDP: Richiesta

SDP: Session Description Protocol v= (protocol version) o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information) b=* (bandwidth information) One or more time descriptions Time description t= (time the session is active) r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) VEDI PAGG 8-24 RFC 2327

SIP+SDP: Risposta

“RTP / AVP” RTP / Audio Video Profile, specificato nella RFC 3551 Descrive le modalità secondo cui trasmettere audio e video in RTP Descrive i “payload type” dell’header RTP per le differenti codifiche z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions

RTP Header Marker Bit (M): indica l’inizio di un talkspurt. V=2 X P CC M PT Timestamp Sequence Number Synchronization source (SSRC) identifier Contributing source (SSRC) identifiers Marker Bit (M): indica l’inizio di un talkspurt. Payload Type (PT): specifica il formato del payload; è pari a 4 per il G.723. Sequence Number: viene usato per riordinare i pacchetti e rilevare pacchetti persi. Timestamp: rappresenta l’istante di campionamento del primo byte del payload. E’ importante ai fini della sincronizzazione e per il calcolo del jitter. SSRC: identifica la sorgente del flusso di pacchetti RTP.

RTCP Sender e Receiver Reports RC PT SSRC of sender Length NTP Timestamp, most significant word header Sender’s packet count NTP Timestamp, least significant word RTP Timestamp Sender’s octet count sender info SSRC_1 (SSRC of first source) Interarrival jitter Last SR (LSR) Delay since last SR (DLSR) Fraction lost Cumulative number of packets lost Extended highest sequence number received report block RTP / RTCP: RTCP Sender Report e Receiver Report

http://www.networksorcery.com/enp/protocol/sip.htm http://www.networksorcery.com/enp/protocol/rtp.htm http://www.networksorcery.com/enp/protocol/rtcp.htm