Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-

src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

@@ -2,78 +2,78 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Informazioni di Base
+## Informazioni di base
 
-SIP (Session Initiation Protocol) è un **protocollo di segnalazione e controllo delle chiamate** ampiamente utilizzato per stabilire, modificare e terminare sessioni multimediali, inclusi voce, video e messaggistica istantanea, su reti IP. Sviluppato dal **Internet Engineering Task Force (IETF)**, SIP è definito in **RFC 3261** ed è diventato lo standard de facto per VoIP e comunicazioni unificate.
+SIP (Session Initiation Protocol) è un **protocollo di segnalazione e controllo delle chiamate** ampiamente usato per instaurare, modificare e terminare sessioni multimediali, comprese voce, video e messaggistica istantanea, su reti IP. Sviluppato dall'**Internet Engineering Task Force (IETF)**, SIP è definito in **RFC 3261** ed è diventato lo standard de facto per VoIP e comunicazioni unificate.
 
-Al alcune caratteristiche chiave di SIP includono:
+Alcune caratteristiche chiave di SIP includono:
 
-1. **Protocollo Basato su Testo**: SIP è un protocollo basato su testo, il che lo rende leggibile dall'uomo e più facile da debug. Si basa su un modello di richiesta-risposta, simile a HTTP, e utilizza metodi come INVITE, ACK, BYE e CANCEL per controllare le sessioni di chiamata.
+1. **Protocollo testuale**: SIP è un protocollo testuale, il che lo rende leggibile dall'uomo e più facile da debug. Si basa su un modello request-response, simile a HTTP, e usa metodi come INVITE, ACK, BYE e CANCEL per controllare le sessioni di chiamata.
-2. **Scalabilità e Flessibilità**: SIP è altamente scalabile e può essere utilizzato in implementazioni di piccole dimensioni così come in ambienti aziendali e di carrier di grandi dimensioni. Può essere facilmente esteso con nuove funzionalità, rendendolo adattabile a vari casi d'uso e requisiti.
+2. **Scalabilità e flessibilità**: SIP è altamente scalabile e può essere utilizzato sia in deployment di piccola scala che in ambienti enterprise o carrier-grade. Può essere facilmente esteso con nuove funzionalità, rendendolo adattabile a diversi casi d'uso e requisiti.
-3. **Interoperabilità**: L'adozione e la standardizzazione diffuse di SIP garantiscono una migliore interoperabilità tra diversi dispositivi, applicazioni e fornitori di servizi, promuovendo comunicazioni senza soluzione di continuità su varie piattaforme.
+3. **Interoperabilità**: L'adozione diffusa e la standardizzazione di SIP garantiscono una migliore interoperabilità tra dispositivi, applicazioni e provider di servizi diversi, favorendo comunicazioni senza soluzione di continuità tra varie piattaforme.
-4. **Design Modulare**: SIP funziona con altri protocolli come **RTP (Real-time Transport Protocol)** per la trasmissione dei media e **SDP (Session Description Protocol)** per descrivere le sessioni multimediali. Questo design modulare consente una maggiore flessibilità e compatibilità con diversi tipi di media e codec.
+4. **Design modulare**: SIP lavora con altri protocolli come **RTP (Real-time Transport Protocol)** per la trasmissione dei media e **SDP (Session Description Protocol)** per la descrizione delle sessioni multimediali. Questo design modulare permette maggiore flessibilità e compatibilità con diversi tipi di media e codec.
-5. **Server Proxy e di Reindirizzamento**: SIP può utilizzare server proxy e di reindirizzamento per facilitare l'instradamento delle chiamate e fornire funzionalità avanzate come inoltro di chiamata, trasferimento di chiamata e servizi di segreteria telefonica.
+5. **Proxy e Redirect Server**: SIP può utilizzare proxy e redirect server per facilitare il routing delle chiamate e fornire funzionalità avanzate come inoltro di chiamata, trasferimento di chiamata e servizi di voicemail.
-6. **Presenza e Messaggistica Istantanea**: SIP non è limitato alla comunicazione vocale e video. Supporta anche la presenza e la messaggistica istantanea, consentendo una vasta gamma di applicazioni di comunicazione unificata.
+6. **Presence e Instant Messaging**: SIP non è limitato alla comunicazione voce e video. Supporta anche presence e instant messaging, abilitando una vasta gamma di applicazioni di comunicazione unificata.
 
-Nonostante i suoi molti vantaggi, SIP può essere complesso da configurare e gestire, in particolare quando si tratta di problemi di attraversamento NAT e firewall. Tuttavia, la sua versatilità, scalabilità e ampio supporto nell'industria lo rendono una scelta popolare per VoIP e comunicazione multimediale.
+Nonostante i molti vantaggi, SIP può essere complesso da configurare e gestire, soprattutto quando si affrontano problemi di NAT traversal e firewall. Tuttavia, la sua versatilità, scalabilità e l'ampio supporto nel settore lo rendono una scelta popolare per VoIP e comunicazioni multimediali.
 
-### Metodi SIP
+### SIP Methods
 
-I metodi SIP fondamentali definiti in **RFC 3261** includono:
+I metodi core di SIP definiti in **RFC 3261** includono:
 
-1. **INVITE**: Utilizzato per **iniziare una nuova sessione (chiamata)** o modificare una esistente. Il metodo INVITE trasporta la descrizione della sessione (tipicamente usando SDP) per informare il destinatario sui dettagli della sessione proposta, come tipi di media, codec e protocolli di trasporto.
+1. **INVITE**: Usato per **inviare una nuova sessione (chiamata)** o modificare una esistente. Il metodo INVITE trasporta la descrizione della sessione (tipicamente usando SDP) per informare il destinatario sui dettagli della sessione proposta, come tipi di media, codec e protocolli di trasporto.
-2. **ACK**: Inviato per **confermare la ricezione** di una risposta finale a una richiesta INVITE. Il metodo ACK garantisce l'affidabilità delle transazioni INVITE fornendo un riconoscimento end-to-end.
+2. **ACK**: Inviato per **confermare la ricezione** di una risposta finale a una richiesta INVITE. Il metodo ACK garantisce l'affidabilità delle transazioni INVITE fornendo un acknowledgment end-to-end.
-3. **BYE**: Utilizzato per **terminare una sessione stabilita (chiamata)**. Il metodo BYE è inviato da una delle parti nella sessione per indicare che desidera terminare la comunicazione.
+3. **BYE**: Usato per **terminare una sessione stabilita (chiamata)**. Il metodo BYE è inviato da una delle parti nella sessione per indicare che desidera terminare la comunicazione.
-4. **CANCEL**: Inviato per **annullare una richiesta INVITE in sospeso** prima che la sessione venga stabilita. Il metodo CANCEL consente al mittente di abortire una transazione INVITE se cambia idea o se non c'è risposta dal destinatario.
+4. **CANCEL**: Inviato per **annullare un INVITE pendente** prima che la sessione sia stabilita. Il metodo CANCEL permette al mittente di abortire una transazione INVITE se cambia idea o se non riceve risposta dal destinatario.
-5. **OPTIONS**: Utilizzato per **interrogare le capacità di un server SIP o di un agente utente**. Il metodo OPTIONS può essere inviato per richiedere informazioni sui metodi supportati, tipi di media o altre estensioni senza effettivamente stabilire una sessione.
+5. **OPTIONS**: Usato per **interrogare le capacità di un server SIP o di un user agent**. Il metodo OPTIONS può essere inviato per richiedere informazioni sui metodi supportati, tipi di media o altre estensioni senza instaurare effettivamente una sessione.
-6. **REGISTER**: Utilizzato da un agente utente per **registrare la propria posizione attuale con un server registratore SIP**. Il metodo REGISTER aiuta a mantenere una mappatura aggiornata tra l'URI SIP di un utente e il suo attuale indirizzo IP, abilitando l'instradamento e la consegna delle chiamate.
+6. **REGISTER**: Usato da un user agent per **registrare la propria posizione corrente con un SIP registrar server**. Il metodo REGISTER aiuta a mantenere una mappatura aggiornata tra l'SIP URI di un utente e il suo indirizzo IP corrente, abilitando il routing e la consegna delle chiamate.
 
 > [!WARNING]
-> Nota che per chiamare qualcuno **non è necessario utilizzare il REGISTER** per nulla.\
+> Nota che per chiamare qualcuno **non è necessario usare REGISTER** per nulla.\
-> Tuttavia, è possibile che per effettuare un **INVITE** il chiamante debba **autenticarsi** prima o riceverà una risposta **`401 Unauthorized`**.
+> Tuttavia, è possibile che per eseguire un **INVITE** il chiamante debba prima **autenticarsi** oppure riceverà una risposta **`401 Unauthorized`**.
 
-Oltre a questi metodi fondamentali, ci sono **diversi metodi di estensione SIP** definiti in altri RFC, come:
+Oltre a questi metodi core, esistono **diversi metodi di estensione SIP** definiti in altri RFC, come:
 
-1. **SUBSCRIBE**: Definito in RFC 6665, il metodo SUBSCRIBE è utilizzato per **richiedere notifiche** sullo stato di una risorsa specifica, come la presenza di un utente o lo stato della chiamata.
+1. **SUBSCRIBE**: Definito in RFC 6665, il metodo SUBSCRIBE è usato per **richiedere notifiche** sullo stato di una risorsa specifica, come la presence di un utente o lo stato di una chiamata.
-2. **NOTIFY**: Anch'esso definito in RFC 6665, il metodo NOTIFY è inviato da un server per **informare un agente utente iscritto** sui cambiamenti nello stato di una risorsa monitorata.
+2. **NOTIFY**: Anch'esso definito in RFC 6665, il metodo NOTIFY è inviato da un server per **informare un user agent iscritto** su cambiamenti nello stato di una risorsa monitorata.
-3. **REFER**: Definito in RFC 3515, il metodo REFER è utilizzato per **richiedere che il destinatario esegua un trasferimento o si riferisca a una terza parte**. Questo è tipicamente utilizzato per scenari di **trasferimento di chiamata**.
+3. **REFER**: Definito in RFC 3515, il metodo REFER è usato per **richiedere che il destinatario esegua un trasferimento o faccia riferimento a una terza parte**. Questo è tipicamente usato per scenari di **call transfer**.
-4. **MESSAGE**: Definito in RFC 3428, il metodo MESSAGE è utilizzato per **inviare messaggi istantanei tra agenti utente SIP**, abilitando la comunicazione basata su testo all'interno del framework SIP.
+4. **MESSAGE**: Definito in RFC 3428, il metodo MESSAGE è usato per **inviare messaggi istantanei tra user agent SIP**, abilitando comunicazioni testuali all'interno del framework SIP.
-5. **UPDATE**: Definito in RFC 3311, il metodo UPDATE consente di **modificare una sessione senza influenzare lo stato del dialogo esistente**. Questo è utile per aggiornare i parametri della sessione, come codec o tipi di media, durante una chiamata in corso.
+5. **UPDATE**: Definito in RFC 3311, il metodo UPDATE permette di **modificare una sessione senza alterare lo stato del dialogo esistente**. Questo è utile per aggiornare parametri di sessione, come codec o tipi di media, durante una chiamata in corso.
-6. **PUBLISH**: Definito in RFC 3903, il metodo PUBLISH è utilizzato da un agente utente per **pubblicare informazioni sullo stato degli eventi a un server**, rendendole disponibili ad altre parti interessate.
+6. **PUBLISH**: Definito in RFC 3903, il metodo PUBLISH è usato da un user agent per **pubblicare informazioni sullo stato di eventi a un server**, rendendole disponibili ad altre parti interessate.
 
-### Codici di Risposta SIP
+### SIP Response Codes
 
-- **1xx (Risposte Provvisorie)**: Queste risposte indicano che la richiesta è stata ricevuta e il server sta continuando a elaborarla.
+- **1xx (Provisional Responses)**: Queste risposte indicano che la richiesta è stata ricevuta e il server sta continuando a processarla.
 - 100 Trying: La richiesta è stata ricevuta e il server sta lavorando su di essa.
-- 180 Ringing: Il chiamato è stato avvisato e risponderà alla chiamata.
+- 180 Ringing: Il chiamato sta venendo avvisato e risponderà alla chiamata.
 - 183 Session Progress: Fornisce informazioni sul progresso della chiamata.
-- **2xx (Risposte di Successo)**: Queste risposte indicano che la richiesta è stata ricevuta, compresa e accettata con successo.
+- **2xx (Successful Responses)**: Queste risposte indicano che la richiesta è stata ricevuta, compresa e accettata con successo.
-- 200 OK: La richiesta è stata soddisfatta con successo e il server l'ha adempiuta.
+- 200 OK: La richiesta è riuscita e il server l'ha eseguita.
 - 202 Accepted: La richiesta è stata accettata per l'elaborazione, ma non è ancora stata completata.
-- **3xx (Risposte di Reindirizzamento)**: Queste risposte indicano che è necessaria un'ulteriore azione per soddisfare la richiesta, tipicamente contattando una risorsa alternativa.
+- **3xx (Redirection Responses)**: Queste risposte indicano che è richiesta un'azione ulteriore per soddisfare la richiesta, tipicamente contattando una risorsa alternativa.
 - 300 Multiple Choices: Ci sono più opzioni disponibili e l'utente o il client deve sceglierne una.
 - 301 Moved Permanently: La risorsa richiesta è stata assegnata a un nuovo URI permanente.
 - 302 Moved Temporarily: La risorsa richiesta è temporaneamente disponibile a un URI diverso.
 - 305 Use Proxy: La richiesta deve essere inviata a un proxy specificato.
-- **4xx (Risposte di Errore del Client)**: Queste risposte indicano che la richiesta contiene una sintassi errata o non può essere soddisfatta dal server.
+- **4xx (Client Error Responses)**: Queste risposte indicano che la richiesta contiene una sintassi errata o non può essere soddisfatta dal client.
-- 400 Bad Request: La richiesta era malformata o non valida.
+- 400 Bad Request: La richiesta era malformata o invalida.
 - 401 Unauthorized: La richiesta richiede l'autenticazione dell'utente.
 - 403 Forbidden: Il server ha compreso la richiesta ma rifiuta di soddisfarla.
 - 404 Not Found: La risorsa richiesta non è stata trovata sul server.
 - 408 Request Timeout: Il server non ha ricevuto una richiesta completa entro il tempo che era disposto ad aspettare.
 - 486 Busy Here: Il chiamato è attualmente occupato e non può rispondere alla chiamata.
-- **5xx (Risposte di Errore del Server)**: Queste risposte indicano che il server non è riuscito a soddisfare una richiesta valida.
+- **5xx (Server Error Responses)**: Queste risposte indicano che il server non è riuscito a soddisfare una richiesta valida.
-- 500 Internal Server Error: Il server ha riscontrato un errore durante l'elaborazione della richiesta.
+- 500 Internal Server Error: Il server ha incontrato un errore durante l'elaborazione della richiesta.
 - 501 Not Implemented: Il server non supporta la funzionalità richiesta per soddisfare la richiesta.
 - 503 Service Unavailable: Il server non è attualmente in grado di gestire la richiesta a causa di manutenzione o sovraccarico.
-- **6xx (Risposte di Fallimento Globale)**: Queste risposte indicano che la richiesta non può essere soddisfatta da alcun server.
+- **6xx (Global Failure Responses)**: Queste risposte indicano che la richiesta non può essere soddisfatta da nessun server.
-- 600 Busy Everywhere: Tutte le possibili destinazioni per la chiamata sono occupate.
+- 600 Busy Everywhere: Tutte le destinazioni possibili per la chiamata sono occupate.
 - 603 Decline: Il chiamato non desidera partecipare alla chiamata.
-- 604 Does Not Exist Anywhere: La risorsa richiesta non è disponibile in nessun luogo nella rete.
+- 604 Does Not Exist Anywhere: La risorsa richiesta non è disponibile da nessuna parte nella rete.
 
-## Esempi
+## Examples
 
-### Esempio SIP INVITE
+### SIP INVITE Example
 ```
 INVITE sip:jdoe@example.com SIP/2.0
 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
@@ -94,43 +94,43 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 <details>
 
-<summary>Ogni Parametro Spiegato</summary>
+<summary>Ogni parametro spiegato</summary>
 
-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Questa riga indica il metodo (INVITE), l'URI della richiesta (sip:[jdoe@example.com](mailto:jdoe@example.com)) e la versione SIP (SIP/2.0).
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Questa riga indica il metodo (INVITE), l'URI della richiesta (sip:[jdoe@example.com](mailto:jdoe@example.com)), e la versione SIP (SIP/2.0).
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - L'intestazione Via specifica il protocollo di trasporto (UDP) e l'indirizzo del client (pc33.example.com). Il parametro "branch" è utilizzato per la rilevazione dei loop e il matching delle transazioni.
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - L'header Via specifica il protocollo di trasporto (UDP) e l'indirizzo del client (pc33.example.com). Il parametro "branch" è usato per il rilevamento di loop e l'abbinamento delle transazioni.
-3. **Max-Forwards**: `Max-Forwards: 70` - Questo campo di intestazione limita il numero di volte in cui la richiesta può essere inoltrata dai proxy per evitare loop infiniti.
+3. **Max-Forwards**: `Max-Forwards: 70` - Questo campo header limita il numero di volte in cui la richiesta può essere inoltrata dai proxy per evitare loop infiniti.
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - L'intestazione To specifica il destinatario della chiamata, inclusi il loro nome visualizzato (John Doe) e l'URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - L'header To specifica il destinatario della chiamata, incluso il display name (John Doe) e l'URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - L'intestazione From specifica il mittente della chiamata, inclusi il loro nome visualizzato (Jane Smith) e l'URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). Il parametro "tag" è utilizzato per identificare univocamente il ruolo del mittente nel dialogo.
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - L'header From specifica il mittente della chiamata, incluso il display name (Jane Smith) e l'URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). Il parametro "tag" viene usato per identificare in modo univoco il ruolo del mittente nel dialogo.
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - L'intestazione Call-ID identifica univocamente una sessione di chiamata tra due agenti utente.
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - L'header Call-ID identifica in modo univoco una sessione di chiamata tra due user agent.
-7. **CSeq**: `CSeq: 314159 INVITE` - L'intestazione CSeq contiene un numero di sequenza e il metodo utilizzato nella richiesta. È utilizzato per abbinare le risposte alle richieste e rilevare messaggi fuori ordine.
+7. **CSeq**: `CSeq: 314159 INVITE` - L'header CSeq contiene un numero di sequenza e il metodo usato nella richiesta. Viene usato per abbinare le risposte alle richieste e rilevare messaggi fuori ordine.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - L'intestazione Contact fornisce un percorso diretto al mittente, che può essere utilizzato per richieste e risposte successive.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - L'header Contact fornisce una route diretta verso il mittente, che può essere usata per richieste e risposte successive.
-9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - L'intestazione User-Agent fornisce informazioni sul software o hardware del mittente, inclusi nome e versione.
+9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - L'header User-Agent fornisce informazioni sul software o hardware del mittente, incluso nome e versione.
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - L'intestazione Allow elenca i metodi SIP supportati dal mittente. Questo aiuta il destinatario a capire quali metodi possono essere utilizzati durante la comunicazione.
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - L'header Allow elenca i metodi SIP supportati dal mittente. Questo aiuta il destinatario a capire quali metodi possono essere usati durante la comunicazione.
-11. **Content-Type**: `Content-Type: application/sdp` - L'intestazione Content-Type specifica il tipo di media del corpo del messaggio, in questo caso, SDP (Session Description Protocol).
+11. **Content-Type**: `Content-Type: application/sdp` - L'header Content-Type specifica il tipo di media del corpo del messaggio, in questo caso SDP (Session Description Protocol).
-12. **Content-Length**: `Content-Length: 142` - L'intestazione Content-Length indica la dimensione del corpo del messaggio in byte.
+12. **Content-Length**: `Content-Length: 142` - L'header Content-Length indica la dimensione del corpo del messaggio in byte.
-13. **Message Body**: Il corpo del messaggio contiene la descrizione della sessione SDP, che include informazioni sui tipi di media, codec e protocolli di trasporto per la sessione proposta.
+13. **Message Body**: The message body contains the SDP session description, which includes information about the media types, codecs, and transport protocols for the proposed session.
 
 - `v=0` - Versione del protocollo (0 per SDP)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Origine e identificatore della sessione
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originatore e identificatore di sessione
 - `s=-` - Nome della sessione (un singolo trattino indica nessun nome di sessione)
 - `c=IN IP4 pc33.example.com` - Informazioni di connessione (tipo di rete, tipo di indirizzo e indirizzo)
-- `t=0 0` - Informazioni temporali (tempi di inizio e fine, 0 0 significa che la sessione non è limitata)
+- `t=0 0` - Informazioni temporali (tempi di inizio e fine, 0 0 significa che la sessione non è vincolata)
-- `m=audio 49170 RTP/AVP 0` - Descrizione del media (tipo di media, numero di porta, protocollo di trasporto e lista dei formati). In questo caso, specifica uno stream audio utilizzando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e formato 0 (PCMU/8000).
+- `m=audio 49170 RTP/AVP 0` - Descrizione del media (tipo di media, numero di porta, protocollo di trasporto e lista dei formati). In questo caso, specifica uno stream audio usando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e il formato 0 (PCMU/8000).
-- `a=rtpmap:0 PCMU/8000` - Mappatura degli attributi del formato (0) al codec (PCMU) e alla sua frequenza di campionamento (8000 Hz).
+- `a=rtpmap:0 PCMU/8000` - Attributo che mappa il formato (0) al codec (PCMU) e alla sua frequenza di clock (8000 Hz).
 
 </details>
 
-### Esempio di SIP REGISTER
+### SIP REGISTER Esempio
 
-Il metodo REGISTER è utilizzato nel Session Initiation Protocol (SIP) per consentire a un agente utente (UA), come un telefono VoIP o un softphone, di **registrare la propria posizione con un server registrar SIP**. Questo processo informa il server **dove instradare le richieste SIP in arrivo destinate all'utente registrato**. Il server registrar è solitamente parte di un server proxy SIP o di un server di registrazione dedicato.
+Il metodo REGISTER è usato nel Session Initiation Protocol (SIP) per permettere a un user agent (UA), come un telefono VoIP o un softphone, di **registrare la sua posizione presso un server registrar SIP**. Questo processo permette al server di sapere **dove instradare le richieste SIP in arrivo destinate all'utente registrato**. Il server registrar fa normalmente parte di un SIP proxy server o di un server di registrazione dedicato.
 
 Ecco un esempio dettagliato dei messaggi SIP coinvolti in un processo di autenticazione REGISTER:
 
-1. Richiesta iniziale **REGISTER** dall'UA al server registrar:
+1. Richiesta **REGISTER** iniziale dall'UA al server registrar:
 ```yaml
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Questo messaggio REGISTER iniziale viene inviato dall'UA (Alice) al server registrar. Include informazioni importanti come la durata di registrazione desiderata (Expires), l'URI SIP dell'utente (sip:[alice@example.com](mailto:alice@example.com)) e l'indirizzo di contatto dell'utente (sip:alice@192.168.1.100:5060).
+Questo messaggio REGISTER iniziale viene inviato dall'UA (Alice) al registrar server. Include informazioni importanti come la durata di registrazione desiderata (Expires), la SIP URI dell'utente (sip:[alice@example.com](mailto:alice@example.com)), e l'indirizzo di contatto dell'utente (sip:alice@192.168.1.100:5060).
 
-2. **401 Unauthorized** risposta dal server registrar:
+2. **401 Unauthorized** response from the registrar server:
-```css
+```
-cssCopy codeSIP/2.0 401 Unauthorized
+SIP/2.0 401 Unauthorized
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>;tag=7878744
@@ -156,9 +156,9 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-Il server registrar risponde con un messaggio "401 Unauthorized", che include un'intestazione "WWW-Authenticate". Questa intestazione contiene informazioni necessarie affinché l'UA si autentichi, come il **realm di autenticazione, nonce e algoritmo**.
+Il server registrar risponde con un messaggio "401 Unauthorized", che include l'header "WWW-Authenticate". Questo header contiene le informazioni richieste affinché la UA si autentichi, come il realm di autenticazione, il nonce e l'algoritmo.
 
-3. Richiesta REGISTER **con credenziali di autenticazione**:
+3. REGISTER request **con credenziali di autenticazione**:
 ```vbnet
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -172,9 +172,9 @@ Expires: 3600
 Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
 Content-Length: 0
 ```
-L'UA invia un'altra richiesta REGISTER, questa volta includendo l'**intestazione "Authorization" con le credenziali necessarie, come il nome utente, il dominio, il nonce e un valore di risposta** calcolato utilizzando le informazioni fornite e la password dell'utente.
+UA invia un'altra richiesta REGISTER, questa volta includendo l'header "Authorization" con le credenziali necessarie, come username, realm, nonce e un valore di response calcolato usando le informazioni fornite e la password dell'utente.
 
-Questo è come viene calcolata la **risposta di autorizzazione**:
+Ecco come viene calcolato il **Authorization response**:
 ```python
 import hashlib
 
@@ -207,7 +207,7 @@ qop = "auth"
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
-4. **Risposta di registrazione** riuscita dal server registrar:
+4. **Risposta di registrazione riuscita** dal server registrar:
 ```yaml
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@@ -219,13 +219,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Dopo che il server registrar verifica le credenziali fornite, **invia una risposta "200 OK" per indicare che la registrazione è stata completata con successo**. La risposta include le informazioni di contatto registrate e il tempo di scadenza per la registrazione. A questo punto, l'agente utente (Alice) è registrato con successo con il server registrar SIP, e le richieste SIP in arrivo per Alice possono essere instradate all'indirizzo di contatto appropriato.
+Dopo che il registrar verifica le credenziali fornite, **invia una risposta "200 OK" per indicare che la registrazione è avvenuta con successo**. La risposta include le informazioni di contatto registrate e il tempo di scadenza della registrazione. A questo punto, lo user agent (Alice) è registrato con successo presso il SIP registrar, e le richieste SIP in arrivo per Alice possono essere instradate all'indirizzo di contatto appropriato.
 
-### Esempio di Chiamata
+### Call Example
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
+> [!TIP]
-> Non è menzionato, ma l'Utente B deve aver inviato un **messaggio REGISTER a Proxy 2** prima di poter ricevere chiamate.
+> Non è menzionato, ma User B deve aver inviato un **REGISTER message to Proxy 2** prima di poter ricevere chiamate.
 
+
+
+---
+
+## SIP: Sicurezza e note di Pentesting
+
+Questa sezione aggiunge suggerimenti pratici, specifici del protocollo, senza duplicare le linee guida più ampie su VoIP. Per metodologia di attacco VoIP end-to-end, strumenti e scenari, vedere:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Fingerprinting and Discovery
+
+- Inviare una OPTIONS request e rivedere gli header `Allow`, `Supported`, `Server` e `User-Agent` per fingerprinting di dispositivi e stack:
+
+```bash
+# nmap NSE (UDP 5060 by default)
+sudo nmap -sU -p 5060 --script sip-methods <target>
+
+# Minimal raw OPTIONS over UDP
+printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
+```
+
+### Username/Extension Enumeration Behavior
+
+- Enumeration tipicamente abusa delle differenze tra `401/407` vs `404/403` su `REGISTER`/`INVITE`. Indurire i server in modo che rispondano in modo uniforme.
+- Asterisk chan_sip: impostare `alwaysauthreject=yes` (generale) per evitare di rivelare utenti validi. Nelle versioni più recenti di Asterisk (PJSIP), le chiamate da guest sono disabilitate a meno che non sia definito un endpoint `anonymous` e un comportamento simile di "always auth reject" è il default; comunque applicare ACL di rete e fail2ban al perimetro.
+
+### SIP Digest Authentication: algorithms and cracking
+
+- SIP comunemente usa l'auth in stile HTTP-Digest. Storicamente MD5 (e MD5-sess) sono prevalenti; gli stack più recenti supportano SHA-256 e SHA-512/256 secondo RFC 8760. Preferire questi algoritmi più forti nelle deployment moderne e disabilitare MD5 quando possibile.
+- L'offline cracking da un pcap è banale per i digest MD5. Dopo aver estratto challenge/response, è possibile usare hashcat mode 11400 (SIP digest, MD5):
+
+```bash
+# Example hash format (single line)
+# username:realm:method:uri:nonce:cnonce:nc:qop:response
+echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
+
+# Crack with a wordlist
+hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
+```
+
+> [!NOTE]
+> RFC 8760 definisce SHA-256 e SHA-512/256 per HTTP Digest (usato da SIP). L'adozione è disomogenea; assicurati che i tuoi strumenti gestiscano questi algoritmi quando punti a PBX moderni.
+
+### SIP over TLS (SIPS) and over WebSockets
+
+- Crittografia del signaling:
+- `sips:` URIs e TCP/TLS tipicamente su 5061. Verificare la validazione del certificato sugli endpoint; molti accettano cert self-signed o wildcard, permettendo MitM in deployment deboli.
+- WebRTC softphones spesso usano SIP over WebSocket per RFC 7118 (`ws://` or `wss://`). Se il PBX espone WSS, testare authentication e CORS, e assicurarsi che i rate limits siano applicati anche sul front end HTTP.
+
+### DoS quick checks (protocol level)
+
+- Il flooding di INVITE, REGISTER o messaggi malformati può esaurire l'elaborazione delle transazioni.
+- Esempio semplice di rate-limiting per UDP/5060 (Linux iptables hashlimit):
+
+```bash
+# Limit new SIP packets from a single IP to 20/s with burst 40
+iptables -A INPUT -p udp --dport 5060 -m hashlimit \
+--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
+--hashlimit-mode srcip -j ACCEPT
+iptables -A INPUT -p udp --dport 5060 -j DROP
+```
+
+### Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP)
+
+- CVE-2024-35190 (pubblicata il 17 maggio 2024): in specifiche release di Asterisk, `res_pjsip_endpoint_identifier_ip` poteva identificare erroneamente richieste SIP non autorizzate come un endpoint locale, potenzialmente consentendo azioni non autorizzate o l'esposizione di informazioni. Risolto in 18.23.1, 20.8.1 e 21.3.1. Verifica la versione del tuo PBX durante i test e segnala responsabilmente.
+
+### Hardening checklist (SIP-specific)
+
+- Preferire TLS per il signaling e SRTP/DTLS-SRTP per i media; disabilitare cleartext dove possibile.
+- Applicare password forti e algoritmi digest robusti (SHA-256/512-256 dove supportati; evitare MD5).
+- Per Asterisk:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR ACLs.
+- PJSIP: non creare un endpoint `anonymous` a meno che non sia necessario; applicare endpoint `acl`/`media_acl`; abilitare fail2ban o equivalente.
+- Topology hiding sui SIP proxies (es. outbound proxy/edge SBC) per ridurre information leakage.
+- Gestione rigorosa di `OPTIONS` e rate limits; disabilitare metodi non usati (es. `MESSAGE`, `PUBLISH`) se non necessari.
+
+
+
+## Riferimenti
+
+- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760
+- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}