Passa al contenuto principale

7. SIP Messages

7 SIP Messages

SIP è un protocollo basato su testo e utilizza il set di caratteri UTF-8 (RFC 2279 [7]).

Un messaggio SIP è una richiesta dal client al server o una risposta dal server al client.

Sebbene i messaggi di richiesta (sezione 7.1) e di risposta (sezione 7.2) differiscano nei dettagli del set di caratteri e della sintassi, utilizzano il formato di base della RFC 2822 [3] (ad esempio, SIP consente campi di intestazione che non sono campi di intestazione validi secondo RFC 2822). Entrambi i tipi di messaggio sono composti da una riga di inizio, uno o più campi di intestazione, una riga vuota che indica la fine dei campi di intestazione e un corpo del messaggio opzionale.

     generic-message  =  start-line
                         *message-header
                         CRLF
                         [ message-body ]
     start-line       =  Request-Line / Status-Line

La riga di inizio, ogni riga di campo di intestazione e la riga vuota DEVONO (MUST) terminare con una sequenza di ritorno a capo avanzamento riga (CRLF). Si noti che una riga vuota deve essere presente anche se non esiste alcun corpo del messaggio.

A eccezione delle differenze di set di caratteri sopra, gran parte della sintassi dei messaggi e dei campi di intestazione SIP è identica a quella di HTTP/1.1. Invece di ripetere qui sintassi e semantica, useremo [HX.Y] per fare riferimento alla sezione X.Y della specifica HTTP/1.1 corrente (RFC 2616 [8]).

SIP non è tuttavia un'estensione di HTTP.

7.1 Richieste

Una richiesta SIP si distingue per avere una riga di inizio di tipo Request-Line. La Request-Line contiene un nome di metodo, un Request-URI e la versione del protocollo, separati da un singolo carattere di spazio (SP).

La Request-Line termina con CRLF. Non è consentito alcun CR o LF tranne la sequenza CRLF di fine riga. Non è consentito alcun spazio lineare (LWS) in alcun elemento.

     Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

  Method: la presente specifica definisce sei metodi. REGISTER per registrare informazioni di contatto, INVITE, ACK e CANCEL per stabilire una sessione, BYE per terminare una sessione e OPTIONS per interrogare le capacità di un server. Le estensioni SIP descritte nelle RFC del percorso standard possono definire metodi aggiuntivi.

  Request-URI: il Request-URI è un URI SIP o SIPS come descritto nella sezione 19.1, o un URI generico (RFC 2396 [5]). Indica l'utente o il servizio a cui questa richiesta è destinata. Il Request-URI NON DEVE (MUST NOT) contenere spazi non escapati o caratteri di controllo e NON DEVE (MUST NOT) essere racchiuso tra « < > ».

       Gli elementi SIP POSSONO (MAY) supportare Request-URI con uno schema diverso da « sip » o « sips » (ad esempio lo schema di URI « tel » della RFC 2806 [9]). Gli elementi SIP POSSONO (MAY) utilizzare i propri mezzi per convertire un URI non-SIP e produrre un URI SIP, SIPS o di un altro schema.

  SIP-Version: sia le richieste sia le risposte contengono la versione SIP utilizzata e seguono [H3.1] (sostituendo HTTP con SIP e HTTP/1.1 con SIP/2.0) per quanto riguarda l'ordinamento delle versioni, i requisiti di conformità e l'aggiornamento dei numeri di versione. Per essere conforme, un'applicazione che invia un messaggio SIP DEVE (MUST) includere una SIP-Version di « SIP/2.0 ». La stringa SIP-Version non distingue tra maiuscole e minuscole, ma le implementazioni DEVONO (MUST) inviarla in maiuscolo.

       A differenza di HTTP/1.1, SIP tratta il numero di versione come una stringa letterale. In pratica, ciò non dovrebbe fare alcuna differenza.

7.2 Risposte

Una risposta SIP si distingue da una richiesta per avere una riga di inizio di tipo Status-Line. La Status-Line è composta dalla versione del protocollo seguita dal Status-Code numerico e dalla relativa frase di motivo, ciascun elemento separato da un singolo SP.

Non è consentito alcun CR o LF tranne la sequenza CRLF finale.

  Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

Lo Status-Code è un codice di risultato intero a tre cifre che indica il risultato della comprensione e del tentativo di soddisfare la richiesta. La Reason-Phrase è destinata a dare una breve descrizione testuale dello Status-Code. Lo Status-Code è destinato alle macchine automatiche e la Reason-Phrase agli utenti umani. Un client non ha bisogno di esaminare o visualizzare la Reason-Phrase.

Questa specifica propone espressioni specifiche per le frasi di motivo, ma le implementazioni POSSONO (MAY) scegliere un altro testo, come la lingua indicata dal campo di intestazione Accept-Language della richiesta.

La prima cifra dello Status-Code definisce la classe della risposta. Le ultime due cifre non hanno alcun ruolo di classificazione. Pertanto, le risposte con codice di stato compreso tra 100 e 199 sono chiamate « risposte 1xx », quelle tra 200 e 299 « risposte 2xx », e così via. In SIP/2.0, sei valori sono consentiti per la prima cifra.

  1xx: Provisional (provvisorio) — richiesta ricevuta e lavorazione in corso.

  2xx: Success (successo) — azione ricevuta, compresa e accettata.

  3xx: Redirection (reindirizzamento) — sono necessari ulteriori processi per soddisfare la richiesta.

  4xx: Client Error (errore client) — la richiesta ha una sintassi non valida o non può essere soddisfatta da questo server.

  5xx: Server Error (errore server) — il server ha fallito nel soddisfare una richiesta apparentemente valida.

  6xx: Global Failure (fallimento globale) — la richiesta non può essere soddisfatta da alcun server.

La sezione 21 definisce queste classi e descrive i singoli codici.

7.3 Campi di intestazione

I campi di intestazione SIP sono simili ai campi di intestazione HTTP, sia nella sintassi sia nella semantica. In particolare, i campi di intestazione SIP seguono le definizioni di [H4.2] riguardo alla sintassi di message-header e alle regole di estensione dei campi di intestazione su più righe. Queste sono tuttavia specificate in HTTP da uno spazio e un ritorno a capo impliciti. Questa specifica aderisce a RFC 2234 [10] e utilizza solo spazi e ritorni a capo espliciti come parte essenziale della grammatica.

[H4.2] specifica inoltre che più campi di intestazione con lo stesso nome di campo i cui valori sono elenchi separati da virgole possono essere combinati in un singolo campo di intestazione. Ciò si applica anche a SIP, ma con regole specifiche diverse a causa della diversa grammatica. Più precisamente, qualsiasi intestazione SIP la cui grammatica è della forma

  header  =  "header-name" HCOLON header-value *(COMMA header-value)

consente di combinare campi di intestazione con lo stesso nome in un elenco separato da virgole. Il campo di intestazione Contact consente un elenco separato da virgole, a meno che il valore del campo di intestazione non sia « * ».

7.3.1 Formato del campo di intestazione

I campi di intestazione seguono il formato generale di intestazione dato nella RFC 2822 [3], sezione 2.2. Ogni campo di intestazione è composto da un nome di campo, seguito da due punti (« : ») e da un valore di campo.

  field-name: field-value

La grammatica formale di message-header specificata nella sezione 25 consente uno spazio arbitrario su entrambi i lati dei due punti. Tuttavia, le implementazioni DOVREBBERO (SHOULD) evitare uno spazio tra il nome di campo e i due punti e utilizzare un singolo spazio (SP) tra i due punti e il valore di campo.

  Subject:            lunch
  Subject      :      lunch
  Subject            :lunch
  Subject: lunch

Pertanto, tutti quelli sopra sono validi ed equivalenti, ma l'ultimo è il formato raccomandato.

I campi di intestazione possono essere estesi su più righe prefissando ogni riga aggiuntiva con almeno uno SP o una tabulazione orizzontale (HT). Il ritorno a capo e lo spazio iniziale della riga successiva sono trattati come un singolo carattere SP. Pertanto, quanto segue è equivalente.

  Subject: I know you're there, pick up the phone and talk to me!
  Subject: I know you're there,
           pick up the phone
           and talk to me!

L'ordine relativo dei campi di intestazione con nomi di campo diversi non è significativo. Tuttavia, i campi di intestazione richiesti per l'elaborazione del proxy (Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization, ecc.) sono raccomandati (RECOMMENDED) in cima al messaggio per facilitare l'analisi rapida. L'ordine relativo delle righe di campo di intestazione con lo stesso nome di campo è significativo. Più righe di campo di intestazione con lo stesso nome di campo POSSONO (MAY) esistere in un messaggio solo se il valore di campo completo di quel campo di intestazione è definito come un elenco separato da virgole (cioè conformemente alla grammatica della sezione 7.3). Esse DEVONO (MUST) poter essere combinate in una singola coppia « field-name: field-value » senza modificare la semantica del messaggio, aggiungendo ogni valore di campo successivo al primo separato da virgole. L'eccezione a questa regola riguarda i campi di intestazione WWW-Authenticate, Authorization, Proxy-Authenticate e Proxy-Authorization. Più righe di campo di intestazione con questi nomi POSSONO (MAY) esistere in un messaggio, ma la loro grammatica non segue il formato generale della sezione 7.3, esse NON DEVONO (MUST NOT) essere combinate in una singola riga di campo di intestazione.

Le implementazioni DEVONO (MUST) essere in grado di elaborare più righe di campo di intestazione con lo stesso nome in qualsiasi combinazione dei formati a valore singolo per riga o a valori separati da virgole.

I seguenti gruppi di righe di campo di intestazione sono tutti validi ed equivalenti.

  Route: `&lt;sip:[email protected]>`
  Subject: Lunch
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Subject: Lunch

  Subject: Lunch
  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

Ciascuno dei seguenti blocchi è valido, ma non sono equivalenti tra loro.

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`,`&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

Il formato del valore di un campo di intestazione è definito per nome di campo di intestazione. È sempre o una sequenza opaca di ottetti TEXT-UTF8 o una combinazione di spazi, token, delimitatori e stringhe tra virgolette. Molti campi di intestazione esistenti seguono la forma generale in cui il valore di campo è seguito da una sequenza di coppie nome parametro-valore parametro separate da punto e virgola.

     field-name: field-value *(;parameter-name=parameter-value)

Si noti che, sebbene un numero arbitrario di coppie di parametri possa essere aggiunto al valore di un campo di intestazione, un particolare nome di parametro NON DEVE (MUST NOT) apparire più volte.

Quando si confrontano i campi di intestazione, il nome del campo non distingue mai tra maiuscole e minuscole. Salvo diversa indicazione nella definizione di un particolare campo di intestazione, i valori di campo, i nomi di parametro e i valori di parametro non distinguono tra maiuscole e minuscole. I token non distinguono mai tra maiuscole e minuscole. Salvo diversa indicazione, i valori rappresentati come stringhe tra virgolette distinguono tra maiuscole e minuscole. Ad esempio,

  Contact: `&lt;sip:[email protected]>`;expires=3600

è equivalente a

  CONTACT: `&lt;sip:[email protected]>`;ExPiReS=3600

e

  Content-Disposition: session;handling=optional

è equivalente a

  content-disposition: Session;HANDLING=OPTIONAL

I due seguenti campi di intestazione non sono equivalenti.

  Warning: 370 devnull "Choose a bigger pipe"
  Warning: 370 devnull "CHOOSE A BIGGER PIPE"

7.3.2 Classificazione dei campi di intestazione

Alcuni campi di intestazione hanno significato solo in una richiesta o solo in una risposta. Questi sono rispettivamente chiamati campi di intestazione di richiesta e di risposta. Se un campo di intestazione appare in un messaggio che non corrisponde alla sua categoria (ad esempio, un campo di intestazione di richiesta in una risposta), DEVE (MUST) essere ignorato. La sezione 20 definisce la classificazione di ciascun campo di intestazione.

7.3.3 Forma compatta

SIP fornisce un meccanismo per esprimere i nomi di campi di intestazione comuni in forma abbreviata. Ciò può essere utile quando il messaggio è troppo grande per essere trasportato sul trasporto disponibile (ad esempio, con UDP, quando supera l'unità di trasmissione massima (MTU)). Queste abbreviazioni sono definite nella sezione 20. La forma abbreviata PUÒ (MAY) essere sostituita in qualsiasi momento dal nome di campo di intestazione lungo senza modificare la semantica del messaggio. Il nome di campo di intestazione PUÒ (MAY) apparire sia in forma lunga sia in forma breve nello stesso messaggio. Le implementazioni DEVONO (MUST) accettare sia la forma lunga sia la forma breve di ciascun nome di intestazione.

7.4 Corpi

Salvo diversamente indicato, le richieste POSSONO (MAY) includere un corpo del messaggio, incluse le nuove richieste definite dalle estensioni di questa specifica. L'interpretazione del corpo dipende dal metodo di richiesta.

Per i messaggi di risposta, il metodo di richiesta e il codice di stato di risposta determinano il tipo e l'interpretazione del corpo del messaggio. Tutte le risposte POSSONO (MAY) includere un corpo.

7.4.1 Tipo di corpo del messaggio

Il tipo di supporto Internet del corpo del messaggio DEVE (MUST) essere dato dal campo di intestazione Content-Type. Se il corpo ha subito una codifica come la compressione, ciò DEVE (MUST) essere indicato dal campo di intestazione Content-Encoding. Altrimenti, Content-Encoding DEVE (MUST) essere omesso. Il set di caratteri del corpo del messaggio, se applicabile, è indicato come parte del valore del campo di intestazione Content-Type.

I tipi MIME « multipart » definiti nella RFC 2046 [11] POSSONO (MAY) essere utilizzati nel corpo del messaggio. Un'implementazione che invia una richiesta contenente un corpo di messaggio multipart DEVE (MUST), se l'implementazione remota lo ha richiesto tramite un campo di intestazione Accept che non include multipart, inviare la descrizione di sessione come corpo di messaggio non-multipart.

I messaggi SIP POSSONO (MAY) includere un corpo binario o una parte di corpo. Se il mittente non fornisce un parametro charset esplicito, i sottotipi di supporto di tipo « text » sono definiti per avere « UTF-8 » come valore charset predefinito.

7.4.2 Lunghezza del corpo del messaggio

La lunghezza (in byte) del corpo è fornita dal campo di intestazione Content-Length. La sezione 20.14 descrive nel dettaglio il contenuto richiesto di questo campo di intestazione.

Si noti che la codifica di trasferimento « chunked » di HTTP/1.1 NON DEVE (MUST NOT) essere utilizzata con SIP. (Nota: la codifica chunked modifica il corpo del messaggio per trasportarlo come una serie di blocchi, ciascuno con il proprio indicatore di dimensione.)

7.5 Incorniciamento dei messaggi SIP

A differenza di HTTP, le implementazioni SIP possono utilizzare UDP o un altro protocollo datagramma non affidabile. Ciascun datagramma trasporta una singola richiesta o risposta. Vedere la sezione 18 per i vincoli sull'utilizzo di un trasporto non affidabile.

Le implementazioni che elaborano messaggi SIP su un trasporto orientato al flusso DEVONO (MUST) ignorare eventuali CRLF che appaiono prima della riga di inizio [H4.1].

  Per trovare la fine di ciascun messaggio SIP nel flusso, viene utilizzato il valore del campo di intestazione Content-Length. Esso è sempre presente quando un messaggio SIP viene inviato su un trasporto orientato al flusso.