L’estensione SIP 100rel e il messaggio di PRACK

L’estensione SIP 100rel e il messaggio di PRACK

Come abbiamo già avuto modo di osservare a proposito del prototocollo SIP, quando un endpoint invia un messaggio di risposta finale, come ad esempio un 200 OK, oppure un 404 NOT FOUND o un 486 BUSY HERE, è necessario che la parte ricevente riconosca di averla ricevuta con un ACK.

Con i messaggi di risposta provvisoria, che rientrano nella classe 1XX , come un 180 RINGING, non è invece comunemente previsto un messaggio di riconoscimento dell’avvenuta ricezione . Questo significa che non abbiamo modo di sapere con certezza se il nostro UAC ha ricevuto o meno la risposta provvisoria.

La necessità di dialogo tra Protocollo SIP e gli altri protocolli

I problemi più importanti però possono iniziare a sorgere quando si utilizza il protocollo SIP su Media Gateway o quando si effettua un interscambio con protocolli come SS7 / ISUP / PSTN. Questi protocolli prevedono infatti sempre la consegna di un messaggio di riconoscimento ad un messaggio di RINGING. Il protocollo SIP in questi casi non prevede la riconferma in tale situazione e questa circostanza può a volte generare anomalie quali o errori nell’interscambio.

L’IETF ha attentamente analizzato le anomalie ricorrenti poiché  in alcuni casi c’era la necessità di confermare la ricezione di queste risposte provvisorie attraverso un messaggio simile all’ACK. Per questa ragione alla RFC 3261 del 2002, riferimento di base per il protocollo SIP fu affiancata la RFC3262 che prende in considerazione la possibilità di garantire una più alta affidabilità per l’invio e il riconoscimento dei messaggi di risposta SIP provvisori.

Il messaggio PRACK e l’estendione 100rel

La RFC3262 ha quindi introdotto il Provisional Acknowledgement (PRACK) e ha aggiunto l’estensione 100rel per le header SUP “Supported” e “Required” nei casi in cui il PRACK è obbligatorio.

In sostanza quando non utilizziamo l’estensione 100rel, un gateway multimediale genera una risposta 180 RINGING oppure 183 SESSION PROGRESS e la invia lungo la catena dei proxy fino all’endopoint, con il rischio che il messaggio possa perdersi in qualsiasi punto lungo la catena. In questa particolare situazione accadrebbe che il Gateway non sarebbe mai in grado di sapere se il messaggio è stato o meno ricevuto correttamente.

Quando invece utilizziamo l’ estensione 100rel , il nostro gateway multimediale genera una risposta 18x e la inoltra lungo la catena dei proxy fino all’endpoint. La risposta 18x inviata in questo caso, include anche un indicatore RSeq che è un numero di sequenza che garantisce l’affidabilità e va ad affiancarsi al tradizionale Cseq. L’endpoint in questo caso riceve la risposta 18x e restituisce un Provisional Acknowledgement o PRACK, con un’intestazione Rack header (Reliable Acknowledgement) con lo stesso valore dell’RSeq della risposta 18x ricevuta. Il gateway multimediale invia per finire un 200 OK per il PRACK.

L’utilizzo dell’estensione 100rel prevede quindi, nel complesso, la possibilità che un messaggio di risposta provvisoria (tipicamente 180 o 183) possa essere ritrasmesso nel caso in cui esso non ottenga un successivo messaggio di PRACK o non sopraggiunga un SIP timeout.

Esempio di chiamata SIP con estensione 100rel attivata

Nell’esempio che segue è possibile osservare una chiamata SIP con l’estensione 100rel attivata. Matteo in questo caso chiama Simone.

Nel messaggio iniziale di invite è presente nell’header SIP “Supported” l’estensione 100rel in quanto il telefono di Simone prevede che l’estensione 100rel sia obbligatoriamente utilizzata.

Il telefono di Simone risponde all’INVITE con il messaggio provvisorio di 180 RINGING.

Essendo attiva l’estensione 100rel, il telefono di Matteo invia il messaggio di PRACK e il telefono di Simone risponde al PRACK con un 200 OK.

In questa transazione è possibile osservare il messaggio di riconoscimento ACK, che fa seguito al 200 OK relativo all’INVITE INIZIALE (evidenziati in verde). In parallelo occorre però osservare come al messaggio di 180 RINGING segua il PRACK e la successiva risposta di 200 OK di conferma definitiva. Questo comportamento è quello previsto dalla RFC3261

SIP PRACK e 100rel
Esempio di una chiamata SIP effettuata utilizzando l’estensione 100rel

Lascia un commento

Questo sito utilizza cookies per darti la miglior esperienza possibile. Accetta il loro utilizzo cliccando sul tasto "Accetto".