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

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

@@ -8,65 +8,65 @@ SIP (Session Initiation Protocol) es un **protocolo de señalización y control
 
 Algunas características clave de SIP incluyen:
 
-1. **Protocolo basado en texto**: SIP es un protocolo basado en texto, lo que lo hace legible para humanos y más fácil de depurar. Se basa en un modelo de solicitud-respuesta, similar a HTTP, y utiliza métodos como INVITE, ACK, BYE y CANCEL para controlar las sesiones de llamada.
-2. **Escalabilidad y Flexibilidad**: SIP es altamente escalable y puede ser utilizado en implementaciones a pequeña escala, así como en entornos empresariales y de grado de operador. Se puede extender fácilmente con nuevas características, lo que lo hace adaptable a varios casos de uso y requisitos.
-3. **Interoperabilidad**: La amplia adopción y estandarización de SIP aseguran una mejor interoperabilidad entre diferentes dispositivos, aplicaciones y proveedores de servicios, promoviendo una comunicación fluida a través de varias plataformas.
-4. **Diseño Modular**: SIP trabaja con otros protocolos como **RTP (Real-time Transport Protocol)** para la transmisión de medios y **SDP (Session Description Protocol)** para describir sesiones multimedia. Este diseño modular permite una mayor flexibilidad y compatibilidad con diferentes tipos de medios y códecs.
-5. **Servidores Proxy y de Redirección**: SIP puede utilizar servidores proxy y de redirección para facilitar el enrutamiento de llamadas y proporcionar características avanzadas como desvío de llamadas, transferencia de llamadas y servicios de correo de voz.
+1. **Protocolo basado en texto**: SIP es un protocolo basado en texto, lo que lo hace legible para humanos y más fácil de depurar. Se basa en un modelo de solicitud-respuesta, similar a HTTP, y usa métodos como INVITE, ACK, BYE y CANCEL para controlar las sesiones de llamada.
+2. **Escalabilidad y Flexibilidad**: SIP es altamente escalable y puede utilizarse en despliegues de pequeña escala así como en entornos empresariales y de nivel carrier. Puede extenderse fácilmente con nuevas funcionalidades, lo que lo hace adaptable a distintos casos de uso y requisitos.
+3. **Interoperabilidad**: La amplia adopción y estandarización de SIP garantizan una mejor interoperabilidad entre diferentes dispositivos, aplicaciones y proveedores de servicio, promoviendo una comunicación sin fricciones entre diversas plataformas.
+4. **Diseño modular**: SIP funciona con otros protocolos como **RTP (Real-time Transport Protocol)** para la transmisión de medios y **SDP (Session Description Protocol)** para describir sesiones multimedia. Este diseño modular permite mayor flexibilidad y compatibilidad con distintos tipos de medios y códecs.
+5. **Servidores Proxy y Redirect**: SIP puede usar servidores proxy y redirect para facilitar el enrutamiento de llamadas y ofrecer funciones avanzadas como desvío de llamadas, transferencia de llamadas y servicios de buzón de voz.
 6. **Presencia y Mensajería Instantánea**: SIP no se limita a la comunicación de voz y video. También soporta presencia y mensajería instantánea, habilitando una amplia gama de aplicaciones de comunicación unificada.
 
-A pesar de sus muchas ventajas, SIP puede ser complejo de configurar y gestionar, particularmente al tratar con problemas de NAT y firewall. Sin embargo, su versatilidad, escalabilidad y amplio soporte en la industria lo convierten en una opción popular para VoIP y comunicación multimedia.
+A pesar de sus muchas ventajas, SIP puede ser complejo de configurar y gestionar, especialmente al tratar con traversal de NAT y problemas de firewall. Sin embargo, su versatilidad, escalabilidad y amplio soporte en la industria lo convierten en una opción popular para VoIP y comunicación multimedia.
 
 ### Métodos SIP
 
-Los métodos SIP fundamentales definidos en **RFC 3261** incluyen:
+Los métodos centrales de SIP definidos en **RFC 3261** incluyen:
 
-1. **INVITE**: Utilizado para **iniciar una nueva sesión (llamada)** o modificar una existente. El método INVITE lleva la descripción de la sesión (típicamente usando SDP) para informar al destinatario sobre los detalles de la sesión propuesta, como tipos de medios, códecs y protocolos de transporte.
-2. **ACK**: Enviado para **confirmar la recepción** de una respuesta final a una solicitud INVITE. El método ACK asegura la fiabilidad de las transacciones INVITE proporcionando un reconocimiento de extremo a extremo.
-3. **BYE**: Utilizado para **terminar una sesión establecida (llamada)**. El método BYE es enviado por cualquiera de las partes en la sesión para indicar que desea finalizar la comunicación.
-4. **CANCEL**: Enviado para **cancelar una solicitud INVITE pendiente** antes de que se establezca la sesión. El método CANCEL permite al remitente abortar una transacción INVITE si cambia de opinión o si no hay respuesta del destinatario.
-5. **OPTIONS**: Utilizado para **consultar las capacidades de un servidor SIP o agente de usuario**. El método OPTIONS puede ser enviado para solicitar información sobre métodos soportados, tipos de medios u otras extensiones sin establecer realmente una sesión.
-6. **REGISTER**: Utilizado por un agente de usuario para **registrar su ubicación actual con un servidor registrador SIP**. El método REGISTER ayuda a mantener un mapeo actualizado entre el URI SIP de un usuario y su dirección IP actual, habilitando el enrutamiento y la entrega de llamadas.
+1. **INVITE**: Usado para **iniciar una nueva sesión (llamada)** o modificar una existente. El método INVITE transporta la descripción de la sesión (típicamente usando SDP) para informar al destinatario sobre los detalles de la sesión propuesta, como tipos de medio, códecs y protocolos de transporte.
+2. **ACK**: Enviado para **confirmar la recepción** de una respuesta final a una solicitud INVITE. El método ACK asegura la fiabilidad de las transacciones INVITE proporcionando un acuse de recibo de extremo a extremo.
+3. **BYE**: Usado para **terminar una sesión establecida (llamada)**. El método BYE es enviado por cualquiera de las partes en la sesión para indicar que desean finalizar la comunicación.
+4. **CANCEL**: Enviado para **cancelar un INVITE pendiente** antes de que se establezca la sesión. El método CANCEL permite al remitente abortar una transacción INVITE si cambia de opinión o si no hay respuesta del destinatario.
+5. **OPTIONS**: Usado para **consultar las capacidades de un servidor SIP o user agent**. El método OPTIONS puede enviarse para solicitar información sobre métodos soportados, tipos de medio u otras extensiones sin establecer realmente una sesión.
+6. **REGISTER**: Usado por un user agent para **registrar su ubicación actual en un servidor registrador SIP**. El método REGISTER ayuda a mantener un mapeo actualizado entre el SIP URI de un usuario y su dirección IP actual, permitiendo el enrutamiento y la entrega de llamadas.
 
 > [!WARNING]
-> Tenga en cuenta que para llamar a alguien **no es necesario usar el REGISTER** para nada.\
-> Sin embargo, es posible que para realizar un **INVITE** el llamante necesite **autenticarse** primero o recibirá una respuesta **`401 Unauthorized`**.
+> Tenga en cuenta que para llamar a alguien **no es necesario usar REGISTER** para nada.\
+> Sin embargo, es posible que, para realizar un **INVITE**, el llamante necesite **autenticarse** primero o recibirá una **`401 Unauthorized`**.
 
-Además de estos métodos fundamentales, hay **varios métodos de extensión SIP** definidos en otros RFC, tales como:
+Además de estos métodos centrales, existen **varios métodos de extensión SIP** definidos en otras RFCs, tales como:
 
-1. **SUBSCRIBE**: Definido en RFC 6665, el método SUBSCRIBE se utiliza para **solicitar notificaciones** sobre el estado de un recurso específico, como la presencia de un usuario o el estado de la llamada.
-2. **NOTIFY**: También definido en RFC 6665, el método NOTIFY es enviado por un servidor para **informar a un agente de usuario suscrito** sobre cambios en el estado de un recurso monitoreado.
-3. **REFER**: Definido en RFC 3515, el método REFER se utiliza para **solicitar que el destinatario realice una transferencia o refiera a un tercero**. Esto se utiliza típicamente para escenarios de **transferencia de llamadas**.
-4. **MESSAGE**: Definido en RFC 3428, el método MESSAGE se utiliza para **enviar mensajes instantáneos entre agentes de usuario SIP**, habilitando la comunicación basada en texto dentro del marco SIP.
-5. **UPDATE**: Definido en RFC 3311, el método UPDATE permite **modificar una sesión sin afectar el estado del diálogo existente**. Esto es útil para actualizar parámetros de sesión, como códecs o tipos de medios, durante una llamada en curso.
-6. **PUBLISH**: Definido en RFC 3903, el método PUBLISH es utilizado por un agente de usuario para **publicar información del estado del evento a un servidor**, haciéndola disponible para otras partes interesadas.
+1. **SUBSCRIBE**: Definido en RFC 6665, el método SUBSCRIBE se usa para **solicitar notificaciones** sobre el estado de un recurso específico, como la presencia de un usuario o el estado de una llamada.
+2. **NOTIFY**: También definido en RFC 6665, el método NOTIFY es enviado por un servidor para **informar a un user agent suscrito** sobre cambios en el estado de un recurso monitorizado.
+3. **REFER**: Definido en RFC 3515, el método REFER se usa para **solicitar que el destinatario realice una transferencia o refiera a un tercero**. Esto se usa típicamente en escenarios de **transferencia de llamadas**.
+4. **MESSAGE**: Definido en RFC 3428, el método MESSAGE se usa para **enviar mensajes instantáneos entre user agents SIP**, habilitando comunicación basada en texto dentro del marco SIP.
+5. **UPDATE**: Definido en RFC 3311, el método UPDATE permite **modificar una sesión sin afectar el estado del diálogo existente**. Esto es útil para actualizar parámetros de la sesión, como códecs o tipos de medio, durante una llamada en curso.
+6. **PUBLISH**: Definido en RFC 3903, el método PUBLISH es usado por un user agent para **publicar información del estado de eventos en un servidor**, haciéndola disponible para otras partes interesadas.
 
 ### Códigos de Respuesta SIP
 
-- **1xx (Respuestas Provisionales)**: Estas respuestas indican que la solicitud fue recibida y el servidor está continuando su procesamiento.
+- **1xx (Respuestas provisionales)**: Estas respuestas indican que la solicitud fue recibida y el servidor continúa procesándola.
 - 100 Trying: La solicitud fue recibida y el servidor está trabajando en ella.
 - 180 Ringing: El destinatario está siendo alertado y tomará la llamada.
 - 183 Session Progress: Proporciona información sobre el progreso de la llamada.
-- **2xx (Respuestas Exitosas)**: Estas respuestas indican que la solicitud fue recibida, entendida y aceptada con éxito.
+- **2xx (Respuestas exitosas)**: Estas respuestas indican que la solicitud fue recibida, entendida y aceptada correctamente.
 - 200 OK: La solicitud fue exitosa y el servidor la ha cumplido.
 - 202 Accepted: La solicitud fue aceptada para su procesamiento, pero aún no se ha completado.
-- **3xx (Respuestas de Redirección)**: Estas respuestas indican que se requiere una acción adicional para cumplir con la solicitud, típicamente contactando un recurso alternativo.
+- **3xx (Respuestas de redirección)**: Estas respuestas indican que se requiere una acción adicional para cumplir la solicitud, típicamente contactando un recurso alternativo.
 - 300 Multiple Choices: Hay múltiples opciones disponibles y el usuario o cliente debe elegir una.
 - 301 Moved Permanently: El recurso solicitado ha sido asignado a un nuevo URI permanente.
 - 302 Moved Temporarily: El recurso solicitado está temporalmente disponible en un URI diferente.
-- 305 Use Proxy: La solicitud debe ser enviada a un proxy especificado.
-- **4xx (Respuestas de Error del Cliente)**: Estas respuestas indican que la solicitud contiene una sintaxis incorrecta o no puede ser cumplida por el servidor.
-- 400 Bad Request: La solicitud estaba mal formada o era inválida.
-- 401 Unauthorized: La solicitud requiere autenticación del usuario.
+- 305 Use Proxy: La solicitud debe enviarse a un proxy especificado.
+- **4xx (Respuestas de error del cliente)**: Estas respuestas indican que la solicitud contiene sintaxis incorrecta o no puede ser cumplida por el servidor.
+- 400 Bad Request: La solicitud fue malformada o inválida.
+- 401 Unauthorized: La solicitud requiere autenticación de usuario.
 - 403 Forbidden: El servidor entendió la solicitud pero se niega a cumplirla.
 - 404 Not Found: El recurso solicitado no fue encontrado en el servidor.
-- 408 Request Timeout: El servidor no recibió una solicitud completa dentro del tiempo que estaba preparado para esperar.
-- 486 Busy Here: El destinatario está actualmente ocupado y no puede tomar la llamada.
-- **5xx (Respuestas de Error del Servidor)**: Estas respuestas indican que el servidor no pudo cumplir con una solicitud válida.
+- 408 Request Timeout: El servidor no recibió una solicitud completa dentro del tiempo que estaba dispuesto a esperar.
+- 486 Busy Here: El destinatario está actualmente ocupado y no puede atender la llamada.
+- **5xx (Respuestas de error del servidor)**: Estas respuestas indican que el servidor falló al intentar cumplir una solicitud válida.
 - 500 Internal Server Error: El servidor encontró un error al procesar la solicitud.
-- 501 Not Implemented: El servidor no soporta la funcionalidad requerida para cumplir con la solicitud.
+- 501 Not Implemented: El servidor no soporta la funcionalidad requerida para cumplir la solicitud.
 - 503 Service Unavailable: El servidor no puede manejar la solicitud actualmente debido a mantenimiento o sobrecarga.
-- **6xx (Respuestas de Fallo Global)**: Estas respuestas indican que la solicitud no puede ser cumplida por ningún servidor.
+- **6xx (Respuestas de fallo global)**: Estas respuestas indican que la solicitud no puede ser cumplida por ningún servidor.
 - 600 Busy Everywhere: Todos los destinos posibles para la llamada están ocupados.
 - 603 Decline: El destinatario no desea participar en la llamada.
 - 604 Does Not Exist Anywhere: El recurso solicitado no está disponible en ninguna parte de la red.
@@ -94,41 +94,41 @@ 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>
+<summary>Cada parámetro explicado</summary>
 
-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Esta línea indica el método (INVITE), la URI de solicitud (sip:[jdoe@example.com](mailto:jdoe@example.com)), y la versión SIP (SIP/2.0).
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - El encabezado Via especifica el protocolo de transporte (UDP) y la dirección del cliente (pc33.example.com). El parámetro "branch" se utiliza para la detección de bucles y la coincidencia de transacciones.
-3. **Max-Forwards**: `Max-Forwards: 70` - Este campo de encabezado limita el número de veces que la solicitud puede ser reenviada por proxies para evitar bucles infinitos.
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - El encabezado To especifica el destinatario de la llamada, incluyendo su nombre para mostrar (John Doe) y la URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)).
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - El encabezado From especifica el remitente de la llamada, incluyendo su nombre para mostrar (Jane Smith) y la URI SIP (sip:[jsmith@example.org](mailto:jsmith@example.org)). El parámetro "tag" se utiliza para identificar de manera única el rol del remitente en el diálogo.
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - El encabezado Call-ID identifica de manera única una sesión de llamada entre dos agentes de usuario.
-7. **CSeq**: `CSeq: 314159 INVITE` - El encabezado CSeq contiene un número de secuencia y el método utilizado en la solicitud. Se utiliza para hacer coincidir respuestas con solicitudes y detectar mensajes fuera de orden.
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - El encabezado Contact proporciona una ruta directa al remitente, que puede ser utilizada para solicitudes y respuestas posteriores.
-9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - El encabezado User-Agent proporciona información sobre el software o hardware del remitente, incluyendo su nombre y versión.
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - El encabezado Allow enumera los métodos SIP soportados por el remitente. Esto ayuda al destinatario a entender qué métodos se pueden utilizar durante la comunicación.
-11. **Content-Type**: `Content-Type: application/sdp` - El encabezado Content-Type especifica el tipo de medio del cuerpo del mensaje, en este caso, SDP (Protocolo de Descripción de Sesión).
-12. **Content-Length**: `Content-Length: 142` - El encabezado Content-Length indica el tamaño del cuerpo del mensaje en bytes.
-13. **Message Body**: El cuerpo del mensaje contiene la descripción de sesión SDP, que incluye información sobre los tipos de medios, códecs y protocolos de transporte para la sesión propuesta.
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Esta línea indica el método (INVITE), el request URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) y la versión de SIP (SIP/2.0).
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - El header Via especifica el protocolo de transporte (UDP) y la dirección del cliente (pc33.example.com). El parámetro "branch" se usa para la detección de bucles y el emparejamiento de transacciones.
+3. **Max-Forwards**: `Max-Forwards: 70` - Este campo limita el número de veces que la petición puede ser reenviada por proxies para evitar bucles infinitos.
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - El header To especifica el destinatario de la llamada, incluyendo su display name (John Doe) y el SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - El header From especifica el remitente de la llamada, incluyendo su display name (Jane Smith) y el SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). El parámetro "tag" se usa para identificar de forma única el rol del remitente en el diálogo.
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - El header Call-ID identifica de manera única una sesión de llamada entre dos user agents.
+7. **CSeq**: `CSeq: 314159 INVITE` - El header CSeq contiene un número de secuencia y el método usado en la petición. Se usa para emparejar respuestas con peticiones y detectar mensajes fuera de orden.
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - El header Contact proporciona una ruta directa al remitente, que puede ser usada para peticiones y respuestas subsecuentes.
+9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - El header User-Agent ofrece información sobre el software u hardware del remitente, incluyendo su nombre y versión.
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - El header Allow lista los métodos SIP soportados por el remitente. Esto ayuda al receptor a entender qué métodos pueden usarse durante la comunicación.
+11. **Content-Type**: `Content-Type: application/sdp` - El header Content-Type especifica el tipo de medio del cuerpo del mensaje, en este caso SDP (Session Description Protocol).
+12. **Content-Length**: `Content-Length: 142` - El header Content-Length indica el tamaño del cuerpo del mensaje en bytes.
+13. **Message Body**: El cuerpo del mensaje contiene la descripción de sesión SDP, que incluye información sobre tipos de media, codecs y protocolos de transporte para la sesión propuesta.
 
 - `v=0` - Versión del protocolo (0 para SDP)
-- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originador e identificador de sesión
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originador e identificador de la sesión
 - `s=-` - Nombre de la sesión (un solo guion indica que no hay nombre de sesión)
 - `c=IN IP4 pc33.example.com` - Información de conexión (tipo de red, tipo de dirección y dirección)
-- `t=0 0` - Información de tiempo (tiempos de inicio y parada, 0 0 significa que la sesión no está limitada)
-- `m=audio 49170 RTP/AVP 0` - Descripción del medio (tipo de medio, número de puerto, protocolo de transporte y lista de formatos). En este caso, especifica un flujo de audio utilizando RTP/AVP (Protocolo de Transporte en Tiempo Real / Perfil de Audio y Video) y formato 0 (PCMU/8000).
-- `a=rtpmap:0 PCMU/8000` - Atributo que mapea el formato (0) al códec (PCMU) y su tasa de reloj (8000 Hz).
+- `t=0 0` - Información de tiempo (tiempos de inicio y parada; 0 0 significa que la sesión no está acotada)
+- `m=audio 49170 RTP/AVP 0` - Descripción de media (tipo de media, número de puerto, protocolo de transporte y lista de formatos). En este caso, especifica un flujo de audio usando RTP/AVP (Real-time Transport Protocol / Audio Video Profile) y el formato 0 (PCMU/8000).
+- `a=rtpmap:0 PCMU/8000` - Atributo que mapea el formato (0) al codec (PCMU) y su tasa de reloj (8000 Hz).
 
 </details>
 
 ### Ejemplo de SIP REGISTER
 
-El método REGISTER se utiliza en el Protocolo de Inicio de Sesión (SIP) para permitir que un agente de usuario (UA), como un teléfono VoIP o un softphone, **registre su ubicación con un servidor registrador SIP**. Este proceso permite que el servidor sepa **dónde enrutar las solicitudes SIP entrantes destinadas al usuario registrado**. El servidor registrador suele ser parte de un servidor proxy SIP o un servidor de registro dedicado.
+El método REGISTER se usa en el Session Initiation Protocol (SIP) para permitir que un user agent (UA), como un teléfono VoIP o un softphone, registre su ubicación en un servidor registrador SIP. Este proceso permite al servidor saber dónde enrutar las peticiones SIP entrantes destinadas al usuario registrado. El servidor registrador suele ser parte de un SIP proxy server o un servidor de registro dedicado.
 
-Aquí hay un ejemplo detallado de los mensajes SIP involucrados en un proceso de autenticación REGISTER:
+Aquí hay un ejemplo detallado de los mensajes SIP implicados en un proceso de autenticación REGISTER:
 
 1. Solicitud inicial **REGISTER** del UA al servidor registrador:
 ```yaml
@@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-Este mensaje inicial de REGISTER es enviado por el UA (Alice) al servidor registrador. Incluye información importante como la duración de registro deseada (Expires), el URI SIP del usuario (sip:[alice@example.com](mailto:alice@example.com)), y la dirección de contacto del usuario (sip:alice@192.168.1.100:5060).
+Este mensaje inicial REGISTER es enviado por la UA (Alice) al servidor registrador. Incluye información importante, como la duración de registro deseada (Expires), el SIP URI del usuario (sip:[alice@example.com](mailto:alice@example.com)), y la dirección de contacto del usuario (sip:alice@192.168.1.100:5060).
 
 2. **401 Unauthorized** respuesta del 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,7 +156,7 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-El servidor registrador responde con un mensaje "401 Unauthorized", que incluye un encabezado "WWW-Authenticate". Este encabezado contiene información necesaria para que el UA se autentique, como el **realm de autenticación, nonce y algoritmo**.
+El servidor registrar responde con un mensaje "401 Unauthorized", que incluye un encabezado "WWW-Authenticate". Este encabezado contiene la información requerida para que el UA se autentique, como el **realm de autenticación, nonce y algoritmo**.
 
 3. Solicitud REGISTER **con credenciales de autenticación**:
 ```vbnet
@@ -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
 ```
-El UA envía otra solicitud REGISTER, esta vez incluyendo el **"Authorization" header con las credenciales necesarias, como el nombre de usuario, realm, nonce y un valor de respuesta** calculado utilizando la información proporcionada y la contraseña del usuario.
+El UA envía otra solicitud REGISTER, esta vez incluyendo la **"Authorization" header con las credenciales necesarias, tales como username, realm, nonce y un response value** calculado usando la información proporcionada y la contraseña del usuario.
 
-Así es como se calcula la **respuesta de Authorization**:
+Así se calcula la **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. **Respuesta de registro exitoso** del servidor registrador:
+4. **Respuesta de registro exitosa** del 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
 ```
-Después de que el servidor registrador verifica las credenciales proporcionadas, **envía una respuesta "200 OK" para indicar que el registro fue exitoso**. La respuesta incluye la información de contacto registrada y el tiempo de expiración para el registro. En este punto, el agente de usuario (Alice) está registrado con éxito en el servidor registrador SIP, y las solicitudes SIP entrantes para Alice pueden ser dirigidas a la dirección de contacto apropiada.
+Después de que el servidor registrar verifica las credenciales proporcionadas, **envía una respuesta "200 OK" para indicar que el registro fue exitoso**. La respuesta incluye la información de contacto registrada y el tiempo de expiración del registro. En este punto, el agente de usuario (Alice) está registrada correctamente en el servidor registrar SIP, y las solicitudes SIP entrantes para Alice pueden enrutarse a la dirección de contacto correspondiente.
 
-### Ejemplo de Llamada
+### Ejemplo de llamada
 
 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>
 
-> [!NOTE]
-> No se menciona, pero el Usuario B necesita haber enviado un **mensaje REGISTER a Proxy 2** antes de poder recibir llamadas.
+> [!TIP]
+> No se menciona, pero User B necesita haber enviado un **REGISTER message to Proxy 2** antes de poder recibir llamadas.
 
+
+
+---
+
+## Seguridad SIP y notas de Pentesting
+
+Esta sección añade consejos prácticos específicos del protocolo sin duplicar la orientación más amplia sobre VoIP. Para la metodología de ataque VoIP de extremo a extremo, herramientas y escenarios, vea:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### Fingerprinting and Discovery
+
+- Envía una petición OPTIONS y revisa los encabezados `Allow`, `Supported`, `Server` y `User-Agent` para identificar dispositivos y 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 típicamente abusa de las diferencias entre `401/407` vs `404/403` en `REGISTER`/`INVITE`. Endurezca los servidores para que respondan de manera uniforme.
+- Asterisk chan_sip: set `alwaysauthreject=yes` (general) to avoid disclosing valid users. In newer Asterisk (PJSIP), guest calling is disabled unless an `anonymous` endpoint is defined and similar "always auth reject" behavior is the default; still enforce network ACLs and fail2ban at the perimeter.
+
+### Autenticación SIP Digest: algoritmos y cracking
+
+- SIP commonly uses HTTP-Digest style auth. Historically MD5 (and MD5-sess) are prevalent; newer stacks support SHA-256 and SHA-512/256 per RFC 8760. Prefer these stronger algorithms in modern deployments and disable MD5 when possible.
+- El cracking offline desde un pcap es trivial para digests MD5. Tras extraer el challenge/response, puede usar hashcat modo 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 define SHA-256 y SHA-512/256 para HTTP Digest (usado por SIP). La adopción es desigual; asegúrese de que sus herramientas manejen estos algoritmos cuando apunte a PBXs modernas.
+
+### SIP over TLS (SIPS) and over WebSockets
+
+- Cifrado de señalización:
+- `sips:` URIs y TCP/TLS típicamente en 5061. Verifique la validación de certificados en los endpoints; muchos aceptan certificados self-signed o wildcard, permitiendo MitM en despliegues débiles.
+- Los softphones WebRTC suelen usar SIP sobre WebSocket según RFC 7118 (`ws://` o `wss://`). Si el PBX expone WSS, pruebe la autenticación y CORS, y asegúrese de que los rate limits se apliquen también en el front-end HTTP.
+
+### DoS: comprobaciones rápidas (nivel de protocolo)
+
+- El flooding de INVITE, REGISTER o mensajes malformados puede agotar el procesamiento de transacciones.
+- Ejemplo simple 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
+```
+
+### CVE recientes y relevantes en stacks SIP a vigilar (Asterisk PJSIP)
+
+- CVE-2024-35190 (publicado el 17 de mayo de 2024): En determinadas versiones de Asterisk, `res_pjsip_endpoint_identifier_ip` podía identificar erróneamente solicitudes SIP no autorizadas como un endpoint local, lo que podría permitir acciones no autorizadas o exposición de información. Corregido en 18.23.1, 20.8.1 y 21.3.1. Valide la versión de su PBX al probar y reporte de forma responsable.
+
+### Lista de comprobación de hardening (SIP-specific)
+
+- Prefiera TLS para señalización y SRTP/DTLS-SRTP para media; deshabilite cleartext donde sea posible.
+- Haga cumplir contraseñas fuertes y algoritmos de digest (SHA-256/512-256 cuando se soporten; evite MD5).
+- Para Asterisk:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR ACLs.
+- PJSIP: do not create an `anonymous` endpoint unless needed; enforce endpoint `acl`/`media_acl`; enable fail2ban or equivalent.
+- Topology hiding on SIP proxies (e.g., outbound proxy/edge SBC) to reduce la exposición de información.
+- Manejo estricto de `OPTIONS` y rate limits; deshabilite métodos no usados (p. ej., `MESSAGE`, `PUBLISH`) si no son necesarios.
+
+
+
+## Referencias
+
+- RFC 8760 – Usando SHA-256 y SHA-512/256 para HTTP Digest (aplica también a SIP Digest): https://www.rfc-editor.org/rfc/rfc8760
+- Asesoría GHSA de Asterisk para CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}