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

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

@@ -4,76 +4,76 @@
 
 ## Informações Básicas
 
-SIP (Session Initiation Protocol) é um **protocolo de sinalização e controle de chamadas** amplamente utilizado para estabelecer, modificar e encerrar sessões multimídia, incluindo voz, vídeo e mensagens instantâneas, sobre redes IP. Desenvolvido pelo **Internet Engineering Task Force (IETF)**, o SIP é definido na **RFC 3261** e se tornou o padrão de fato para VoIP e comunicações unificadas.
+SIP (Session Initiation Protocol) é um **protocolo de sinalização e controle de chamadas** amplamente usado para estabelecer, modificar e terminar sessões multimídia, incluindo voz, vídeo e mensagens instantâneas, sobre redes IP. Desenvolvido pelo **Internet Engineering Task Force (IETF)**, o SIP está definido em **RFC 3261** e tornou-se o padrão de fato para VoIP e comunicações unificadas.
 
 Algumas características principais do SIP incluem:
 
-1. **Protocolo Baseado em Texto**: O SIP é um protocolo baseado em texto, o que o torna legível por humanos e mais fácil de depurar. Ele é baseado em um modelo de solicitação-resposta, semelhante ao HTTP, e usa métodos como INVITE, ACK, BYE e CANCEL para controlar sessões de chamadas.
-2. **Escalabilidade e Flexibilidade**: O SIP é altamente escalável e pode ser usado em implantações de pequeno porte, bem como em ambientes empresariais e de operadoras de grande porte. Ele pode ser facilmente estendido com novos recursos, tornando-o adaptável a vários casos de uso e requisitos.
-3. **Interoperabilidade**: A ampla adoção e padronização do SIP garantem melhor interoperabilidade entre diferentes dispositivos, aplicativos e provedores de serviços, promovendo comunicação sem costura em várias plataformas.
-4. **Design Modular**: O SIP funciona com outros protocolos como **RTP (Real-time Transport Protocol)** para transmissão de mídia e **SDP (Session Description Protocol)** para descrever sessões multimídia. Esse design modular permite maior flexibilidade e compatibilidade com diferentes tipos de mídia e codecs.
-5. **Servidores Proxy e de Redirecionamento**: O SIP pode usar servidores proxy e de redirecionamento para facilitar o roteamento de chamadas e fornecer recursos avançados como encaminhamento de chamadas, transferência de chamadas e serviços de correio de voz.
-6. **Presença e Mensagens Instantâneas**: O SIP não se limita à comunicação de voz e vídeo. Ele também suporta presença e mensagens instantâneas, permitindo uma ampla gama de aplicativos de comunicação unificada.
+1. **Protocolo baseado em texto**: SIP é um protocolo baseado em texto, o que o torna legível por humanos e mais fácil de depurar. Baseia-se em um modelo de requisição-resposta, similar ao HTTP, e utiliza métodos como INVITE, ACK, BYE e CANCEL para controlar sessões de chamada.
+2. **Escalabilidade e Flexibilidade**: SIP é altamente escalável e pode ser usado em implantações de pequena escala assim como em ambientes empresariais e de nível carrier. Pode ser facilmente estendido com novas funcionalidades, tornando-o adaptável a vários casos de uso e requisitos.
+3. **Interoperabilidade**: A ampla adoção e padronização do SIP garantem melhor interoperabilidade entre diferentes dispositivos, aplicações e provedores de serviço, promovendo comunicação contínua entre várias plataformas.
+4. **Design Modular**: SIP funciona com outros protocolos como **RTP (Real-time Transport Protocol)** para transmissão de mídia e **SDP (Session Description Protocol)** para descrever sessões multimídia. Esse design modular permite maior flexibilidade e compatibilidade com diferentes tipos de mídia e codecs.
+5. **Servidores Proxy e Redirect**: SIP pode usar servidores proxy e redirect para facilitar o roteamento de chamadas e fornecer funcionalidades avançadas como encaminhamento de chamadas, transferência de chamadas e serviços de voicemail.
+6. **Presence e Instant Messaging**: SIP não se limita a voz e vídeo. Também suporta presence e instant messaging, permitindo uma ampla gama de aplicações de comunicação unificada.
 
-Apesar de suas muitas vantagens, o SIP pode ser complexo de configurar e gerenciar, especialmente ao lidar com problemas de travessia de NAT e firewall. No entanto, sua versatilidade, escalabilidade e amplo suporte na indústria o tornam uma escolha popular para comunicação VoIP e multimídia.
+Apesar de suas muitas vantagens, o SIP pode ser complexo de configurar e gerenciar, particularmente quando se lida com traversal de NAT e questões de firewall. Contudo, sua versatilidade, escalabilidade e amplo suporte na indústria o tornam uma escolha popular para VoIP e comunicação multimídia.
 
-### Métodos SIP
+### SIP Methods
 
-Os métodos principais do SIP definidos na **RFC 3261** incluem:
+Os métodos centrais do SIP definidos em **RFC 3261** incluem:
 
 1. **INVITE**: Usado para **iniciar uma nova sessão (chamada)** ou modificar uma existente. O método INVITE carrega a descrição da sessão (tipicamente usando SDP) para informar o destinatário sobre os detalhes da sessão proposta, como tipos de mídia, codecs e protocolos de transporte.
-2. **ACK**: Enviado para **confirmar o recebimento** de uma resposta final a uma solicitação INVITE. O método ACK garante a confiabilidade das transações INVITE fornecendo reconhecimento de ponta a ponta.
-3. **BYE**: Usado para **encerrar uma sessão estabelecida (chamada)**. O método BYE é enviado por qualquer uma das partes na sessão para indicar que deseja encerrar a comunicação.
-4. **CANCEL**: Enviado para **cancelar uma solicitação INVITE pendente** antes que a sessão seja estabelecida. O método CANCEL permite que o remetente cancele uma transação INVITE se mudar de ideia ou se não houver resposta do destinatário.
+2. **ACK**: Enviado para **confirmar o recebimento** de uma resposta final a uma requisição INVITE. O método ACK garante a confiabilidade das transações INVITE fornecendo uma confirmação de ponta a ponta.
+3. **BYE**: Usado para **terminar uma sessão estabelecida (chamada)**. O método BYE é enviado por qualquer uma das partes na sessão para indicar que deseja encerrar a comunicação.
+4. **CANCEL**: Enviado para **cancelar um INVITE pendente** antes que a sessão seja estabelecida. O método CANCEL permite ao remetente abortar uma transação INVITE se mudar de ideia ou se não houver resposta do destinatário.
 5. **OPTIONS**: Usado para **consultar as capacidades de um servidor SIP ou agente de usuário**. O método OPTIONS pode ser enviado para solicitar informações sobre métodos suportados, tipos de mídia ou outras extensões sem realmente estabelecer uma sessão.
-6. **REGISTER**: Usado por um agente de usuário para **registrar sua localização atual em um servidor registrador SIP**. O método REGISTER ajuda a manter um mapeamento atualizado entre o URI SIP de um usuário e seu endereço IP atual, permitindo o roteamento e a entrega de chamadas.
+6. **REGISTER**: Usado por um agente de usuário para **registrar sua localização atual em um servidor registrar SIP**. O método REGISTER ajuda a manter um mapeamento atualizado entre o SIP URI de um usuário e seu endereço IP atual, possibilitando o roteamento e a entrega de chamadas.
 
 > [!WARNING]
-> Note que para chamar alguém **não é necessário usar o REGISTER** para nada.\
-> No entanto, é possível que para realizar um **INVITE** o chamador precise **se autenticar** primeiro ou receberá uma resposta **`401 Unauthorized`**.
+> Note that to call someone it's **not necessário to use the REGISTER** for anything.\
+> However, it's possible that in order to perform an **INVITE** the caller needs to **authenticate** first or he will receive a **`401 Unauthorized`** response.
 
-Além desses métodos principais, existem **vários métodos de extensão SIP** definidos em outras RFCs, como:
+Além desses métodos centrais, existem **vários métodos de extensão SIP** definidos em outros RFCs, tais como:
 
-1. **SUBSCRIBE**: Definido na RFC 6665, o método SUBSCRIBE é usado para **solicitar notificações** sobre o estado de um recurso específico, como a presença ou status de chamada de um usuário.
-2. **NOTIFY**: Também definido na RFC 6665, o método NOTIFY é enviado por um servidor para **informar um agente de usuário inscrito** sobre mudanças no estado de um recurso monitorado.
-3. **REFER**: Definido na RFC 3515, o método REFER é usado para **solicitar que o destinatário realize uma transferência ou se refira a um terceiro**. Isso é tipicamente usado para cenários de **transferência de chamadas**.
-4. **MESSAGE**: Definido na RFC 3428, o método MESSAGE é usado para **enviar mensagens instantâneas entre agentes de usuário SIP**, permitindo comunicação baseada em texto dentro da estrutura SIP.
-5. **UPDATE**: Definido na RFC 3311, o método UPDATE permite **modificar uma sessão sem afetar o estado do diálogo existente**. Isso é útil para atualizar parâmetros de sessão, como codecs ou tipos de mídia, durante uma chamada em andamento.
-6. **PUBLISH**: Definido na RFC 3903, o método PUBLISH é usado por um agente de usuário para **publicar informações de estado de eventos em um servidor**, tornando-as disponíveis para outras partes interessadas.
+1. **SUBSCRIBE**: Definido em RFC 6665, o método SUBSCRIBE é usado para **solicitar notificações** sobre o estado de um recurso específico, como a presence de um usuário ou o status de uma chamada.
+2. **NOTIFY**: Também definido em RFC 6665, o método NOTIFY é enviado por um servidor para **informar um agente de usuário inscrito** sobre mudanças no estado de um recurso monitorado.
+3. **REFER**: Definido em RFC 3515, o método REFER é usado para **solicitar que o destinatário realize uma transferência ou encaminhe para um terceiro**. Isso é tipicamente usado em cenários de **transferência de chamadas**.
+4. **MESSAGE**: Definido em RFC 3428, o método MESSAGE é usado para **enviar mensagens instantâneas entre user agents SIP**, possibilitando comunicação baseada em texto dentro do framework SIP.
+5. **UPDATE**: Definido em RFC 3311, o método UPDATE permite **modificar uma sessão sem afetar o estado do diálogo existente**. Isso é útil para atualizar parâmetros de sessão, como codecs ou tipos de mídia, durante uma chamada em andamento.
+6. **PUBLISH**: Definido em RFC 3903, o método PUBLISH é usado por um agente de usuário para **publicar informações de estado de eventos em um servidor**, tornando-as disponíveis para outras partes interessadas.
 
-### Códigos de Resposta SIP
+### SIP Response Codes
 
-- **1xx (Respostas Provisórias)**: Essas respostas indicam que a solicitação foi recebida e o servidor está continuando a processá-la.
-- 100 Trying: A solicitação foi recebida e o servidor está trabalhando nela.
-- 180 Ringing: O chamado está sendo alertado e atenderá a chamada.
-- 183 Session Progress: Fornece informações sobre o progresso da chamada.
-- **2xx (Respostas de Sucesso)**: Essas respostas indicam que a solicitação foi recebida, compreendida e aceita com sucesso.
-- 200 OK: A solicitação foi bem-sucedida e o servidor a atendeu.
-- 202 Accepted: A solicitação foi aceita para processamento, mas ainda não foi concluída.
-- **3xx (Respostas de Redirecionamento)**: Essas respostas indicam que mais ações são necessárias para atender à solicitação, tipicamente contatando um recurso alternativo.
-- 300 Multiple Choices: Existem várias opções disponíveis, e o usuário ou cliente deve escolher uma.
-- 301 Moved Permanently: O recurso solicitado foi atribuído a um novo URI permanente.
-- 302 Moved Temporarily: O recurso solicitado está temporariamente disponível em um URI diferente.
-- 305 Use Proxy: A solicitação deve ser enviada a um proxy especificado.
-- **4xx (Respostas de Erro do Cliente)**: Essas respostas indicam que a solicitação contém uma sintaxe incorreta ou não pode ser atendida pelo servidor.
-- 400 Bad Request: A solicitação estava malformada ou inválida.
-- 401 Unauthorized: A solicitação requer autenticação do usuário.
-- 403 Forbidden: O servidor entendeu a solicitação, mas se recusa a atendê-la.
-- 404 Not Found: O recurso solicitado não foi encontrado no servidor.
-- 408 Request Timeout: O servidor não recebeu uma solicitação completa dentro do tempo que estava preparado para esperar.
-- 486 Busy Here: O chamado está atualmente ocupado e não pode atender a chamada.
-- **5xx (Respostas de Erro do Servidor)**: Essas respostas indicam que o servidor falhou em atender a uma solicitação válida.
-- 500 Internal Server Error: O servidor encontrou um erro ao processar a solicitação.
-- 501 Not Implemented: O servidor não suporta a funcionalidade necessária para atender à solicitação.
-- 503 Service Unavailable: O servidor está atualmente incapaz de lidar com a solicitação devido a manutenção ou sobrecarga.
-- **6xx (Respostas de Falha Global)**: Essas respostas indicam que a solicitação não pode ser atendida por nenhum servidor.
-- 600 Busy Everywhere: Todos os destinos possíveis para a chamada estão ocupados.
-- 603 Decline: O chamado não deseja participar da chamada.
-- 604 Does Not Exist Anywhere: O recurso solicitado não está disponível em nenhum lugar da rede.
+- **1xx (Respostas Provisórias)**: Essas respostas indicam que a requisição foi recebida e que o servidor está continuando a processá-la.
+- 100 Trying: The request was received, and the server is working on it.
+- 180 Ringing: The callee is being alerted and will take the call.
+- 183 Session Progress: Provides information about the progress of the call.
+- **2xx (Successful Responses)**: Essas respostas indicam que a requisição foi recebida, entendida e aceita com sucesso.
+- 200 OK: The request was successful, and the server has fulfilled it.
+- 202 Accepted: The request was accepted for processing, but it hasn't been completed yet.
+- **3xx (Redirection Responses)**: Essas respostas indicam que é necessária ação adicional para cumprir a requisição, tipicamente contactando um recurso alternativo.
+- 300 Multiple Choices: There are multiple options available, and the user or client must choose one.
+- 301 Moved Permanently: The requested resource has been assigned a new permanent URI.
+- 302 Moved Temporarily: The requested resource is temporarily available at a different URI.
+- 305 Use Proxy: The request must be sent to a specified proxy.
+- **4xx (Client Error Responses)**: Essas respostas indicam que a requisição contém sintaxe inválida ou não pode ser atendida pelo servidor.
+- 400 Bad Request: The request was malformed or invalid.
+- 401 Unauthorized: The request requires user authentication.
+- 403 Forbidden: The server understood the request but refuses to fulfill it.
+- 404 Not Found: The requested resource was not found on the server.
+- 408 Request Timeout: The server did not receive a complete request within the time it was prepared to wait.
+- 486 Busy Here: The callee is currently busy and unable to take the call.
+- **5xx (Server Error Responses)**: Essas respostas indicam que o servidor falhou em atender a uma requisição válida.
+- 500 Internal Server Error: The server encountered an error while processing the request.
+- 501 Not Implemented: The server does not support the functionality required to fulfill the request.
+- 503 Service Unavailable: The server is currently unable to handle the request due to maintenance or overload.
+- **6xx (Global Failure Responses)**: Essas respostas indicam que a requisição não pode ser atendida por nenhum servidor.
+- 600 Busy Everywhere: All possible destinations for the call are busy.
+- 603 Decline: The callee does not wish to participate in the call.
+- 604 Does Not Exist Anywhere: The requested resource is not available anywhere in the network.
 
 ## Exemplos
 
-### Exemplo SIP INVITE
+### Exemplo de SIP INVITE
 ```
 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>Cada Parâmetro Explicado</summary>
 
-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Esta linha indica o método (INVITE), o URI de solicitação (sip:[jdoe@example.com](mailto:jdoe@example.com)) e a versão SIP (SIP/2.0).
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - O cabeçalho Via especifica o protocolo de transporte (UDP) e o endereço do cliente (pc33.example.com). O parâmetro "branch" é usado para detecção de loops e correspondência de transações.
-3. **Max-Forwards**: `Max-Forwards: 70` - Este campo de cabeçalho limita o número de vezes que a solicitação pode ser encaminhada por proxies para evitar loops infinitos.
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - O cabeçalho To especifica o destinatário da chamada, incluindo seu nome de exibição (John Doe) e URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - O cabeçalho From especifica o remetente da chamada, incluindo seu nome de exibição (Jane Smith) e URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). O parâmetro "tag" é usado para identificar exclusivamente o papel do remetente no diálogo.
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - O cabeçalho Call-ID identifica exclusivamente uma sessão de chamada entre dois agentes de usuário.
-7. **CSeq**: `CSeq: 314159 INVITE` - O cabeçalho CSeq contém um número de sequência e o método usado na solicitação. É usado para corresponder respostas a solicitações e detectar mensagens fora de ordem.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - O cabeçalho Contact fornece uma rota direta para o remetente, que pode ser usada para solicitações e respostas subsequentes.
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Esta linha indica o método (INVITE), o URI de requisição (sip:[jdoe@example.com](mailto:jdoe@example.com)) e a versão do SIP (SIP/2.0).
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - O cabeçalho Via especifica o protocolo de transporte (UDP) e o endereço do cliente (pc33.example.com). O parâmetro "branch" é usado para detecção de loop e correspondência de transações.
+3. **Max-Forwards**: `Max-Forwards: 70` - Este campo limita o número de vezes que a requisição pode ser encaminhada por proxies para evitar loops infinitos.
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - O cabeçalho To especifica o destinatário da chamada, incluindo seu nome exibido (John Doe) e o SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - O cabeçalho From especifica o remetente da chamada, incluindo seu nome exibido (Jane Smith) e o SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). O parâmetro "tag" é usado para identificar de forma única o papel do remetente no diálogo.
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - O cabeçalho Call-ID identifica de forma única uma sessão de chamada entre dois agentes de usuário.
+7. **CSeq**: `CSeq: 314159 INVITE` - O cabeçalho CSeq contém um número de sequência e o método usado na requisição. Ele é usado para correlacionar respostas com requisições e detectar mensagens fora de ordem.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - O cabeçalho Contact fornece uma rota direta para o remetente, que pode ser usada para requisições e respostas subsequentes.
 9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - O cabeçalho User-Agent fornece informações sobre o software ou hardware do remetente, incluindo seu nome e versão.
 10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - O cabeçalho Allow lista os métodos SIP suportados pelo remetente. Isso ajuda o destinatário a entender quais métodos podem ser usados durante a comunicação.
-11. **Content-Type**: `Content-Type: application/sdp` - O cabeçalho Content-Type especifica o tipo de mídia do corpo da mensagem, neste caso, SDP (Session Description Protocol).
+11. **Content-Type**: `Content-Type: application/sdp` - O cabeçalho Content-Type especifica o tipo de mídia do corpo da mensagem, neste caso SDP (Session Description Protocol).
 12. **Content-Length**: `Content-Length: 142` - O cabeçalho Content-Length indica o tamanho do corpo da mensagem em bytes.
-13. **Message Body**: O corpo da mensagem contém a descrição da sessão SDP, que inclui informações sobre os tipos de mídia, codecs e protocolos de transporte para a sessão 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` - Versão do protocolo (0 para SDP)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originador e identificador da sessão
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originador e identificador de sessão
 - `s=-` - Nome da sessão (um único hífen indica que não há nome de sessão)
 - `c=IN IP4 pc33.example.com` - Informações de conexão (tipo de rede, tipo de endereço e endereço)
-- `t=0 0` - Informações de tempo (horários de início e parada, 0 0 significa que a sessão não está limitada)
-- `m=audio 49170 RTP/AVP 0` - Descrição da mídia (tipo de mídia, número da porta, protocolo de transporte e lista de formatos). Neste caso, especifica um fluxo de áudio usando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e formato 0 (PCMU/8000).
-- `a=rtpmap:0 PCMU/8000` - Atributo mapeando o formato (0) para o codec (PCMU) e sua taxa de clock (8000 Hz).
+- `t=0 0` - Informações de timing (tempos de início e término, 0 0 significa que a sessão não é limitada)
+- `m=audio 49170 RTP/AVP 0` - Descrição de mídia (tipo de mídia, número da porta, protocolo de transporte e lista de formatos). Neste caso, especifica um fluxo de áudio usando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) e o formato 0 (PCMU/8000).
+- `a=rtpmap:0 PCMU/8000` - Atributo mapeando o formato (0) para o codec (PCMU) e sua taxa de relógio (8000 Hz).
 
 </details>
 
-### Exemplo de SIP REGISTER
+### SIP REGISTER Exemplo
 
-O método REGISTER é usado no Protocolo de Iniciação de Sessão (SIP) para permitir que um agente de usuário (UA), como um telefone VoIP ou um softphone, **registre sua localização em um servidor registrador SIP**. Este processo informa ao servidor **onde encaminhar as solicitações SIP recebidas destinadas ao usuário registrado**. O servidor registrador geralmente faz parte de um servidor proxy SIP ou de um servidor de registro dedicado.
+O método REGISTER é usado no Session Initiation Protocol (SIP) para permitir que um user agent (UA), como um telefone VoIP ou um softphone, **registre sua localização em um servidor registrador SIP**. Esse processo permite que o servidor saiba **para onde encaminhar as requisições SIP recebidas destinadas ao usuário registrado**. O servidor registrador normalmente faz parte de um SIP proxy ou de um servidor de registro dedicado.
 
-Aqui está um exemplo detalhado das mensagens SIP envolvidas em um processo de autenticação REGISTER:
+Here's a detailed example of the SIP messages involved in a REGISTER authentication process:
 
-1. Solicitação inicial **REGISTER** do UA para o servidor registrador:
+1. Initial **REGISTER** request from UA to the registrar server:
 ```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
 ```
-Esta mensagem inicial de REGISTER é enviada pelo UA (Alice) para o servidor registrador. Ela inclui informações importantes, como a duração de registro desejada (Expires), o URI SIP do usuário (sip:[alice@example.com](mailto:alice@example.com)) e o endereço de contato do usuário (sip:alice@192.168.1.100:5060).
+Esta mensagem inicial REGISTER é enviada pela UA (Alice) ao servidor registrador. Ela inclui informações importantes, como a duração desejada do registro (Expires), o SIP URI do usuário (sip:[alice@example.com](mailto:alice@example.com)) e o endereço de contato do usuário (sip:alice@192.168.1.100:5060).
 
 2. **401 Unauthorized** resposta do servidor registrador:
-```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
 ```
-O servidor registrador responde com uma mensagem "401 Unauthorized", que inclui um cabeçalho "WWW-Authenticate". Este cabeçalho contém informações necessárias para que o UA se autentique, como o **domínio de autenticação, nonce e algoritmo**.
+O servidor registrar responde com uma mensagem "401 Unauthorized", que inclui um cabeçalho "WWW-Authenticate". Esse cabeçalho contém informações necessárias para que o UA se autentique, como o **realm de autenticação, nonce e algoritmo**.
 
-3. Solicitação REGISTER **com credenciais de autenticação**:
+3. Requisição REGISTER **com credenciais de autenticação**:
 ```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
 ```
-O UA envia outra solicitação REGISTER, desta vez incluindo o **cabeçalho "Authorization" com as credenciais necessárias, como o nome de usuário, realm, nonce e um valor de resposta** calculado usando as informações fornecidas e a senha do usuário.
+O UA envia outro REGISTER request, desta vez incluindo o cabeçalho **"Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value** calculado usando as informações fornecidas e a senha do usuário.
 
-É assim que a **resposta de Authorization** é calculada:
+É assim que a **Authorization response** é calculada:
 ```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. **Resposta de registro** bem-sucedido do servidor registrador:
+4. **Resposta de registro bem-sucedido** do servidor registrador:
 ```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
 ```
-Após o servidor registrador verificar as credenciais fornecidas, **ele envia uma resposta "200 OK" para indicar que o registro foi bem-sucedido**. A resposta inclui as informações de contato registradas e o tempo de expiração para o registro. Neste ponto, o agente do usuário (Alice) está registrado com sucesso no servidor registrador SIP, e as solicitações SIP recebidas para Alice podem ser roteadas para o endereço de contato apropriado.
+Após o servidor registrar verificar as credenciais fornecidas, **ele envia uma resposta "200 OK" para indicar que o registro foi bem-sucedido**. A resposta inclui as informações de contato registradas e o tempo de expiração do registro. Neste ponto, o user agent (Alice) está registrado com sucesso no SIP registrar server, e requisições SIP entrantes para Alice podem ser roteadas para o endereço de contato apropriado.
 
-### Exemplo de Chamada
+### Call Example
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
-> Não é mencionado, mas o Usuário B precisa ter enviado uma **mensagem REGISTER para o Proxy 2** antes de poder receber chamadas.
+> [!TIP]
+> Não está mencionado, mas o User B precisa ter enviado uma **mensagem REGISTER para o Proxy 2** antes de ele poder receber chamadas.
 
+
+
+---
+
+## Segurança SIP e Pentesting Notes
+
+Esta seção adiciona dicas práticas específicas de protocolo sem duplicar a orientação mais ampla sobre VoIP. Para a metodologia de ataque end-to-end em VoIP, ferramentas e cenários, veja:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Fingerprinting and Discovery
+
+- Envie uma requisição OPTIONS e analise os headers `Allow`, `Supported`, `Server` e `User-Agent` para fingerprinting de dispositivos e stacks:
+
+```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 das diferenças entre `401/407` vs `404/403` em `REGISTER`/`INVITE`. Harden os servidores para responder de forma uniforme.
+- Asterisk chan_sip: configure `alwaysauthreject=yes` (geral) para evitar divulgar usuários válidos. Em versões mais novas do Asterisk (PJSIP), guest calling é desabilitado a menos que um endpoint `anonymous` seja definido e um comportamento similar de "always auth reject" é o padrão; ainda assim, imponha ACLs de rede e fail2ban na perímetro.
+
+### SIP Digest Authentication: algorithms and cracking
+
+- O SIP comumente usa autenticação no estilo HTTP-Digest. Historicamente MD5 (e MD5-sess) são prevalentes; stacks mais novos suportam SHA-256 e SHA-512/256 conforme RFC 8760. Prefira esses algoritmos mais fortes em implantações modernas e desative MD5 quando possível.
+- Cracking offline a partir de um pcap é trivial para digests MD5. Depois de extrair o challenge/response, você pode usar o modo 11400 do hashcat (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 defines SHA-256 and SHA-512/256 for HTTP Digest (used by SIP). A adoção é desigual; garanta que suas ferramentas suportem esses algoritmos ao mirar PBXs modernos.
+
+### SIP over TLS (SIPS) and over WebSockets
+
+- Criptografia de sinalização:
+- URIs `sips:` e TCP/TLS tipicamente na porta 5061. Verifique a validação de certificados nos endpoints; muitos aceitam certificados self-signed ou wildcard, possibilitando MitM em implantações fracas.
+- Softphones WebRTC frequentemente usam SIP sobre WebSocket conforme RFC 7118 (`ws://` ou `wss://`). Se o PBX expõe WSS, teste autenticação e CORS, e assegure que limites de taxa sejam aplicados também no front-end HTTP.
+
+### DoS quick checks (protocol level)
+
+- O flooding de INVITE, REGISTER ou mensagens malformadas pode esgotar o processamento de transações.
+- Exemplo simples de rate-limiting para 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 (publicado em 17 de maio de 2024): Em releases específicos do Asterisk, `res_pjsip_endpoint_identifier_ip` podia identificar incorretamente requisições SIP não autorizadas como um endpoint local, potencialmente permitindo ações não autorizadas ou exposição de informações. Corrigido nas versões 18.23.1, 20.8.1 e 21.3.1. Valide a versão do seu PBX ao testar e reporte de forma responsável.
+
+### Hardening checklist (SIP-specific)
+
+- Prefira TLS para sinalização e SRTP/DTLS-SRTP para mídia; desative cleartext quando possível.
+- Exija senhas fortes e algoritmos de digest robustos (SHA-256/512-256 onde suportado; evite MD5).
+- Para Asterisk:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, ACLs CIDR `permit`/`deny` por endpoint.
+- PJSIP: não crie um endpoint `anonymous` a menos que necessário; imponha `acl`/`media_acl` por endpoint; habilite fail2ban ou equivalente.
+- Ocultação de topologia em proxies SIP (por exemplo, outbound proxy/edge SBC) para reduzir information leakage.
+- Tratamento estrito de `OPTIONS` e limites de taxa; desative métodos não usados (por exemplo, `MESSAGE`, `PUBLISH`) se não forem necessários.
+
+
+
+## Referências
+
+- 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}}