Se sei un installatore VoipVoice e hai frequentato i corsi di certificazione tecnica della nostra VoIP Academy, saprai già che il SIP è un protocollo di segnalazione e che l’SDP (Session Description Protocol) descrive invece i media di una sessione. Questa separazione consente al SIP di creare sessioni per qualsiasi tipologia di media: voce, video o messaggi in tempo reale. In questo articolo di approfondimento tecnico parleremo di Early Media e Late Media in ambito SIP, scopriremo la differenza con Early Offer e Late Offer e vedremo come procedere in caso di problemi.
Una normale chiamata SIP inizia con successo quando il chiamato la accetta con la risposta finale di 200 OK. A questo punto la negoziazione del codec avviene con successo e il protocollo SIP avvia (mediante SDP) una sessione multimediale con entrambi gli endpoint che dialogano correttamente e conoscono le reciproche capacità. Se questo comportamento rappresenta ciò che avviene normalmente, vi sono dei casi in cui è possibile che lo scambio audio venga anticipato. In altri casi è anche possibile che l’ordine di offerta dei codec e delle capacità tra chiamante e chiamato vengano invertite. Per chi conosce già le basi del protocollo SIP, questi argomenti meritano sicuramente un approfondimento.
Partiamo dall’inizio. In ambito SIP una chiamata e la conversazione audio effettiva si avviano dopo una risposta di 200 OK. Ma questo non ha nulla a che fare con il momento esatto in cui si avvia una sessione multimediale. Vi sono infatti delle circostanze nelle quali l’endpoint remoto può avviare una sessione multimediale prima che avvenga la chiamate vera e propria. E’ ad esempio il caso in cui l’estremità remota riproduce un messaggio vocale per avvisarci in merito al motivo di irraggiungibilità del chiamato oppure riproduce direttamente un messaggio di selezione IVR richiedendo la digitazione di tasti, senza rispondere direttamente alla chiamata.
Cos’è l’Early Media in ambito VoIP SIP ?
Vi sono quindi dei casi in cui il flusso audio transita prima ancora che la chiamata abbia inizio. In ambito VoIP SIP si parla di “sessione multimediale anticipata”, in termini tecnici chiamato early media. Non si tratta infatti della voce dell’interlocutore con cui si desidera parlare ma di di toni di sistema, annunci preregistrati o qualsiasi altro suono che il chiamato desidera fare ascoltare al chiamante.
E’ un’implementazione in qualche modo simile alla telefonia tradizionale PSTN. Essa si verifica quando si cerca di chiamare un numero cellulare fuori dal raggio di copertura: ” gentile cliente, il numero che ha composto non è disponibile al momento, riprova più tardi.” In questi casi il fornitore di telefonia vi sta semplicemente fornendo una informazione di avviso senza che venga addebitato il costo della chiamata. In termini pratici non si tratta di una risposta alla chiamata ma di un semplice messaggio di avviso/segnalazione.
SIP 180 Ringing
Come riportato nella RFC3261 SIP, la risposta di 180 viene utilizzata per avvisare il chiamante che l’UA (User Agent) che riceve la richiesta di INVITE SIP sta squillando.
La risposta 180, nella maggior parte dei casi, non trasporta l’SDP nel corpo del messaggio (SIP body). Il dispositivo che riceve una risposta 180 (senza SDP) di solito avvia una sessione audio con il “tono di libero” (ringback tone). In questo caso il “tono di libero” non viaggia attraverso la rete ma è semplicemente emulato dal telefono IP o dal centralino telefonico del chiamante.
Vale la pena ricordare che questo comportamento si verifica quando vengono ricevute alcune risposte SIP nelle classi 4XX, 5XX, 6XX. Il dispositivo, prima di interrompere la chiamata, dovrebbe generare un segnale audio per segnalare che la chiamata è fallita oppure che la linea è occupata.
SIP 183 Session Progress
La risposta 183 (Session Progress) viene utilizzata per trasmettere le informazioni. I campi di intestazione o il body message SDP, in questo caso, possono essere utilizzati per fornire maggiori dettagli sull’avanzamento della chiamata.
Risposta SIP 183 con Early Media nell’SDP
La risposta 183 contenente il body SDP viene solitamente utilizzata in 3 casi:
- Trasmettere il tono di libero attraverso la reta: il dispositivo che esegue la chiamata (UAC) riceverà il tono di libero direttamente dal chiamato (UAS) per indicare che il chiamato è stato avvisato. In questo caso, diversamente da quanto normalmente previsto dal protocollo SIP, il tono di libero viaggia effettivamente attraverso la rete.
- Per riprodurre un tono o un messaggio vocale di messaggio d’errore (es. utente non raggiungibile) e poi riagganciare.
- Per l’implementazione di un risponditore vocale interattivo (IVR): In questo caso toni dtmf di selezione sono attivi contemporaneamente al flusso multimediale.
Questi esempi dovrebbero aver reso più chiaro lo scopo e il funzionamento dell’early media nell’ambito di una risposta SIP con codice 183.
Il funzionamento dell’Early Media (sessione media anticipata) e del Late Media
Negli esempi appena visti sembrerebbe che il funzionamento di “early media” sia piuttosto semplice. Nella pratica, non sempre questo comportamento è lineare. l’UAC (il chiamante) non può decidere se avviare la riproduzione del tono di libero (in risposta al 180 ringing) oppure avviare la riproduzione del messaggio RTP in arrivo con il codice 183. Poiché la segnalazione SIP e l’audio RTP viaggiano su due binari differenti, l’UAC potrebbe riprodurre la risposta 183 con il body message SDP senza prima emulare il tono di libero.
Oltre a questo caso, esiste anche la possibilità che si possano implementare delle risposte SIP 180 contenenti un messaggio SDP ed in grado di avviare una early media, senza la necessità di una risposta 183 dedicata. In buona sostanza si pone il problema del possibile conflitto tra una risposta con codice 180 ed una con codice 183.
Affinché l’early media funzioni è quindi fondamentale verificare che i pacchetti media stiano effettivamente arrivando in un determinato momento.
Le raccomandazioni della RFC3960
Proprio per evitare le possibili problematiche appena evidenziate, la RFC3960, raccomanda di attenersi ad alcuni comportamenti:
- A meno che non si riceva una risposta 180 (ringing), non generare mai un tono di libero locale.
- Se è stato ricevuto un 180 (ringing) ma non ci sono pacchetti multimediali in arrivo , generare il tono di libero locale.
- Se è stato ricevuto un 180 (ringing) e sono presenti pacchetti multimediali in arrivo, riprodurli senza però generare il tono di libero locale.
Questi criteri non sono però definiti come standard da seguire per ogni dispositivo SIP; essi affermano semplicemente che:
Qualsiasi UA dovrebbe riprodurre i pacchetti multimediali in arrivo (e interrompere la generazione del tono di libero se era in esecuzione)
La RFC3960, prescrive inoltre che, quando la chiamata lascia lo stato di riproduzione multimediale, ricevendo una risposta, la risposta SDP nel 200 OK deve corrispondere alla risposta SDP nel 183/180 precedente. Ciò significa che nel passaggio dal 180/183 al 200 OK non è consentita alcuna modifica nella capacità multimediale (IP, porta e codec) quando la chiamata passa dalla prima sessione “early media” alla sessione successiva di chiamata vera e proprie (late media).
Bene, questo è tutto, spero che abbia senso per te. Probabilmente, le tracce di Wireshark di una chiamata SIP con early media può aiutarti a capire in modo più chiaro.
Early Offer e Late Offer in ambito SIP
Mi è capitato spesso di vedere confondere i concetti di Early media e Late Media, di cui abbiamo appena parlato, con quelli di Early Offer e Late/Delayed Offer (Offerta Anticipata e Offerta tardiva/ritardata). I due concetti riguardano entrambi la gestione dell’audio ma sono completamente distinti.
E’ noto che in ambito SIP le intestazioni di INVITE descrivono il tipo di sessione che si desidera stabilire, mentre l’SDP descrive i media che si desidera inviare e ricevere. Ad esempio, un telefono IP invia generalmente nell’SDP le voci che indicano i codec supportati : G.711A, G711U, G.729. Il destinatario dell’INVITE analizzerà l’SDP, deciderà quale codec utilizzare ed invierà il proprio SDP nella risposta 200 Ok.
Il chiamato (UAS) può quindi normalmente vedere l’SDP del chiamante (UAC) prima di mostrare il proprio. In altre parole, il chiamante lascia normalmente la scelta del codec al chiamato.
Questo comportamento è chiamato Early Offer (Offerta Anticipata) . In questo caso l’SDP del chiamante è indicato direttamente nell’INVITE.
Tuttavia, secondo l’RFC6337 è anche possibile decidere di non lasciare la scelta del codec unicamente al chiamato. E’ infatti possibile modificare il tipo di offerta in Late Offer (Offerta Tardiva, anche detta “Delayed Offer” ossia Offerta Ritardata). Con l’offerta tardiva, non è presente alcun SDP nella richiesta INVITE. La responsabilità della scelta del codec cade quindi sul chiamante.
Nell’offerta tardiva, la parte chiamata riceve un INVITE senza SDP. Il comportamento è esattamente il medesimo di una normale sessione SIP: il chiamato invia un 180 (ringing) ma non è a conoscenza di quale codec potrà essere coinvolto nella sessione. Quando risponderà alla chiamata, invierà un 200 Ok con SDP e il chiamante risponde con un ACK. In questo caso, l’ACK conterrà l’SDP che avrebbe dovuto essere inviato con l’INVITE iniziale. Con questa modifica al posizionamento dell’SDP, il chiamante può decidere quale codec verrà utilizzare per la sessione audio.
Un ulteriore metodo, consigliato agli installatori, per obbligare il chiamato ad utilizzare il codec scelto dal chiamante, consiste nel dichiarare un unico codec nell’SDP dell’INVITE.
Riassumendo avremo quindi:
Offerta anticipata = SDP nell’INVITE
Offerta tardiva = SDP nell’ACK
Conclusioni e note per la diagnosi delle anomalie.
I toni di libero, occupato, squillo sono gestiti tramite codici numerici di risposta. Contrariamente alla telefonia tradizionale, il tono non è quindi trasmesso attraverso la rete. Per mantenere la compatibilità e le abitudini acquisite con la telefonia analogica, il protocollo SIP prevede una emulazione locale dei messaggi e dei toni audio. Esistono però delle eccezioni, come la risposta “183 (SDP)” che producono la riproduzione di toni o messaggi audio prima che la chiamata vocale venga avviata tra le due parti. Questi toni/messaggi viaggiano tra i due endpoint con un criterio simile alla telefonia analogica.
Nel caso in cui si presentino anomalie con la riproduzione dei toni, è sempre indispensabile eseguire delle verifiche approfondite. Queste ultime si effettuano catturando un file .pcap della chiamata per poi analizzarlo con il tool Wireshark. Le specifiche RFC del protocollo SIP non prescrivono un obbligo specifico o un ordinamento per l’invio delle risposte 180/183. In alcuni casi è possibile, ad esempio, che i sistemi PBX non siamo in grado di interpretare correttamente alcune situazioni anomale (as es. l’invio di due risposte SIP consecutive: 183 seguito da 183 con SDP).
Per identificare la causa del problema è necessario verificare il tracciato della chiamata SIP. In base al codice rilevato, sarà possibile stabilire se l’incongruenza è causata o meno dal PBX. In caso di messaggi “troncati” a livello di sintassi SIP non è infrequente che la causa dell’anomalia sia dovuta ad un errore di NAT oppure alla presenza di un SIP ALG (o SIP Helper) sull’apparato Router Firewall.
