daemon-sec-cheatsheet

sip-session-initiation-protocol.md (25012B)

---

 ---
 title: "SIP (Session Initiation Protocol)"
 section: "Network Services"
 sectionSlug: "network-services-pentesting"
 sourcePath: "src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: false
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # SIP (Session Initiation Protocol)
 
 ## Basic information<sup>[[4]](#references)</sup>
 
 SIP (Session Initiation Protocol) is a **signaling and call control protocol** widely used for establishing, modifying, and terminating multimedia sessions, including voice, video, and instant messaging, over IP networks. Developed by the **Internet Engineering Task Force (IETF)**, SIP is defined in **RFC 3261** and has become the de facto standard for VoIP and unified communications.
 
 Some key features of SIP include:
 
 1. **Text-based Protocol**: SIP is a text-based protocol, which makes it human-readable and easier to debug. It is based on a request-response model, similar to HTTP, and uses methods like INVITE, ACK, BYE, and CANCEL for controlling call sessions.
 2. **Scalability and Flexibility**: SIP is highly scalable and can be used in small-scale deployments as well as large enterprise and carrier-grade environments. It can be easily extended with new features, making it adaptable to various use cases and requirements.
 3. **Interoperability**: SIP's widespread adoption and standardization ensure better interoperability between different devices, applications, and service providers, promoting seamless communication across various platforms.
 4. **Modular Design**: SIP works with other protocols like **RTP (Real-time Transport Protocol)** for media transmission and **SDP (Session Description Protocol)** for describing multimedia sessions. This modular design allows for greater flexibility and compatibility with different media types and codecs.
 5. **Proxy and Redirect Servers**: SIP can use proxy and redirect servers to facilitate call routing and provide advanced features like call forwarding, call transfer, and voicemail services.
 6. **Presence and Instant Messaging**: SIP is not limited to voice and video communication. It also supports presence and instant messaging, enabling a wide range of unified communication applications.
 
 Despite its many advantages, SIP can be complex to configure and manage, particularly when dealing with NAT traversal and firewall issues. However, its versatility, scalability, and extensive support across the industry make it a popular choice for VoIP and multimedia communication.
 
 ### SIP methods<sup>[[4]](#references)</sup>
 
 The core SIP methods defined in **RFC 3261** include:
 
 1. **INVITE**: Used to **initiate a new session (call)** or modify an existing one. The INVITE method carries the session description (typically using SDP) to inform the recipient about the details of the proposed session, such as media types, codecs, and transport protocols.
 2. **ACK**: Sent to **confirm the receipt** of a final response to an INVITE request. The ACK method ensures the reliability of INVITE transactions by providing end-to-end acknowledgement.
 3. **BYE**: Used to **terminate an established session (call)**. The BYE method is sent by either party in the session to indicate that they wish to end the communication.
 4. **CANCEL**: Sent to **cancel a pending INVITE** request before the session is established. The CANCEL method allows the sender to abort an INVITE transaction if they change their mind or if there is no response from the recipient.
 5. **OPTIONS**: Used to **query the capabilities of a SIP server or user agent**. The OPTIONS method can be sent to request information about supported methods, media types, or other extensions without actually establishing a session.
 6. **REGISTER**: Used by a user agent to **register its current location with a SIP registrar server**. The REGISTER method helps in maintaining an up-to-date mapping between a user's SIP URI and their current IP address, enabling call routing and delivery.
 
 > [!WARNING]
 > A caller does **not need to use `REGISTER`** to call another party.\
 > The caller may nevertheless need to authenticate before sending an **`INVITE`**, or the server will return **`401 Unauthorized`**.
 
 In addition to these core methods, there are **several SIP extension methods** defined in other RFCs, such as:
 
 1. **SUBSCRIBE**: Defined in RFC 6665, the SUBSCRIBE method is used to **request notifications** about the state of a specific resource, such as a user's presence or call status.
 2. **NOTIFY**: Also defined in RFC 6665, the NOTIFY method is sent by a server to **inform a subscribed user agent** about changes in the state of a monitored resource.
 3. **REFER**: Defined in RFC 3515, the REFER method is used to **request that the recipient performs a transfer or refers to a third party**. This is typically used for **call transfer** scenarios.
 4. **MESSAGE**: Defined in RFC 3428, the MESSAGE method is used to **send instant messages between SIP user agents**, enabling text-based communication within the SIP framework.
 5. **UPDATE**: Defined in RFC 3311, the UPDATE method allows **modifying a session without affecting the state of the existing dialog**. This is useful for updating session parameters, such as codecs or media types, during an ongoing call.
 6. **PUBLISH**: Defined in RFC 3903, the PUBLISH method is used by a user agent to **publish event state information to a server**, making it available to other interested parties.
 
 ### SIP response codes<sup>[[5]](#references)</sup>
 
 - **1xx (Provisional Responses)**: These responses indicate that the request was received, and the server is continuing to process it.
   - 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)**: These responses indicate that the request was successfully received, understood, and accepted.
   - 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)**: These responses indicate that further action is required to fulfill the request, typically by contacting an alternate resource.
   - 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)**: These responses indicate that the request contains bad syntax or cannot be fulfilled by the server.
   - 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)**: These responses indicate that the server failed to fulfill a valid request.
   - 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)**: These responses indicate that the request cannot be fulfilled by any server.
   - 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.
 
 ## Examples<sup>[[4]](#references)</sup>
 
 ### SIP INVITE Example
 
 ```text
 INVITE sip:jdoe@example.com SIP/2.0
 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 To: John Doe <sip:jdoe@example.com>
 From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
 Call-ID: a84b4c76e66710
 CSeq: 314159 INVITE
 Contact: <sip:jsmith@pc33.example.com>
 User-Agent: ExampleSIPClient/1.0
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
 Content-Type: application/sdp
 Content-Length: 142
 
 v=0
 o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
 s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
 a=rtpmap:0 PCMU/8000
 ```
 
 <details>
 
 <summary>Each Param Explained</summary>
 
 1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - This line indicates the method (INVITE), the request URI (sip:[jdoe@example.com](mailto:jdoe@example.com)), and the SIP version (SIP/2.0).
 2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - The Via header specifies the transport protocol (UDP) and the client's address (pc33.example.com). The "branch" parameter is used for loop detection and transaction matching.
 3. **Max-Forwards**: `Max-Forwards: 70` - This header field limits the number of times the request can be forwarded by proxies to avoid infinite loops.
 4. **To**: `To: John Doe <sip:jdoe@example.com>` - The To header specifies the recipient of the call, including their display name (John Doe) and SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)).
 5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - The From header specifies the sender of the call, including their display name (Jane Smith) and SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)). The "tag" parameter is used to uniquely identify the sender's role in the dialog.
 6. **Call-ID**: `Call-ID: a84b4c76e66710` - The Call-ID header uniquely identifies a call session between two user agents.
 7. **CSeq**: `CSeq: 314159 INVITE` - The CSeq header contains a sequence number and the method used in the request. It's used to match responses to requests and detect out-of-order messages.
 8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - The Contact header provides a direct route to the sender, which can be used for subsequent requests and responses.
 9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - The User-Agent header provides information about the software or hardware of the sender, including its name and version.
 10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - The Allow header lists the SIP methods supported by the sender. This helps the recipient understand which methods can be used during the communication.
 11. **Content-Type**: `Content-Type: application/sdp` - The Content-Type header specifies the media type of the message body, in this case, SDP (Session Description Protocol).
 12. **Content-Length**: `Content-Length: 142` - The Content-Length header indicates the size of the message body in bytes.
 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` - Protocol version (0 for SDP)
 - `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Originator and session identifier
 - `s=-` - Session name (a single hyphen indicates no session name)
 - `c=IN IP4 pc33.example.com` - Connection information (network type, address type, and address)
 - `t=0 0` - Timing information (start and stop times, 0 0 means the session is not bounded)
 - `m=audio 49170 RTP/AVP 0` - Media description (media type, port number, transport protocol, and format list). In this case, it specifies an audio stream using RTP/AVP (Real-time Transport Protocol / Audio Video Profile) and format 0 (PCMU/8000).
 - `a=rtpmap:0 PCMU/8000` - Attribute mapping the format (0) to the codec (PCMU) and its clock rate (8000 Hz).
 
 </details>
 
 ### SIP REGISTER Example
 
 The REGISTER method is used in Session Initiation Protocol (SIP) to allow a user agent (UA), such as a VoIP phone or a softphone, to **register its location with a SIP registrar server**. This process lets the server know **where to route incoming SIP requests destined for the registered user**. The registrar server is usually part of a SIP proxy server or a dedicated registration server.
 
 Here's a detailed example of the SIP messages involved in a REGISTER authentication process:
 
 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
 Max-Forwards: 70
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>
 Call-ID: 1234567890@192.168.1.100
 CSeq: 1 REGISTER
 Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
 
 This initial REGISTER message is sent by the UA (Alice) to the registrar server. It includes important information such as the desired registration duration (Expires), the user's SIP URI (sip:[alice@example.com](mailto:alice@example.com)), and the user's contact address (sip:alice@192.168.1.100:5060).
 
 2. **401 Unauthorized** response from the registrar server:
 
 ```text
 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
 Call-ID: 1234567890@192.168.1.100
 CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
 
 The registrar server responds with a "401 Unauthorized" message, which includes a "WWW-Authenticate" header. This header contains information required for the UA to authenticate itself, such as the **authentication realm, nonce, and algorithm**.
 
 3. REGISTER request **with authentication credentials**:
 
 ```text
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 Max-Forwards: 70
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>
 Call-ID: 1234567890@192.168.1.100
 CSeq: 2 REGISTER
 Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 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
 ```
 
 The UA sends another REGISTER request, this time including the **"Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value** calculated using the provided information and the user's password.
 
 This is how the **Authorization response** is calculated:
 
 ```python
 import hashlib
 
 def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
     # 1. Calculate HA1 (concatenation of username, realm, and password)
     ha1_input = f"{username}:{realm}:{password}"
     ha1 = hashlib.md5(ha1_input.encode()).hexdigest()
 
     # 2. Calculate HA2 (concatenation of method and uri)
     ha2_input = f"{method}:{uri}"
     ha2 = hashlib.md5(ha2_input.encode()).hexdigest()
 
     # 3. Calculate the final response value (concatenation of h1, stuff and h2)
     response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
     response = hashlib.md5(response_input.encode()).hexdigest()
 
     return response
 
 # Example usage
 username = "alice"
 password = "mysecretpassword"
 realm = "example.com"
 method = "REGISTER"
 uri = "sip:example.com"
 nonce = "abcdefghijk"
 nc = "00000001"
 cnonce = "lmnopqrst"
 qop = "auth"
 
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
 
 4. **Successful registration** response from the registrar server:
 
 ```yaml
 SIP/2.0 200 OK
 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
 Call-ID: 1234567890@192.168.1.100
 CSeq: 2 REGISTER
 Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
 
 After the registrar server verifies the provided credentials, **it sends a "200 OK" response to indicate that the registration was successful**. The response includes the registered contact information and the expiration time for the registration. At this point, the user agent (Alice) is successfully registered with the SIP registrar server, and incoming SIP requests for Alice can be routed to the appropriate contact address.
 
 ### Call Example
 
 <figure><img src="https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/188de82beb54e70956b2952367a0af91d26758b8/src/images/image%20%281101%29.png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
 > It's not mentioned, but User B needs to have sent a **REGISTER message to Proxy 2** before he is able to receive calls.
 
 
 ---
 
 ## SIP Security and Pentesting Notes
 
 This section adds practical, protocol-specific tips without duplicating the broader VoIP guidance. For end-to-end VoIP attacking methodology, tools and scenarios, see:
 
 [Readme](/hacktricks/network-services-pentesting/pentesting-voip/overview)
 
 ### Fingerprinting and Discovery
 
 - Send an OPTIONS request and review `Allow`, `Supported`, `Server` and `User-Agent` headers to fingerprint devices and 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 typically abuses differences between `401/407` vs `404/403` on `REGISTER`/`INVITE`. Harden servers to reply uniformly.
   - 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.
 
 ### SIP Digest Authentication: algorithms and 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.<sup>[[2]](#references)</sup> Prefer these stronger algorithms in modern deployments and disable MD5 when possible.
 - Offline cracking from a PCAP is practical for weak MD5 digests. After extracting the challenge/response, you can use 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 defines SHA-256 and SHA-512/256 for HTTP Digest (used by SIP). Adoption is uneven; ensure your tools handle these when targeting modern PBXs.<sup>[[2]](#references)</sup>
 
 ### SIP over TLS (SIPS) and over WebSockets
 
 - Signaling encryption:
   - `sips:` URIs and TCP/TLS typically on 5061. Verify certificate validation on endpoints; many accept self-signed or wildcard certs, enabling MitM in weak deployments.
   - WebRTC softphones often use SIP over WebSocket per RFC 7118 (`ws://` or `wss://`). If the PBX exposes WSS, test authentication and CORS, and ensure rate limits are enforced on the HTTP front end as well.
 
 ### DoS quick checks (protocol level)
 
 - Flooding INVITE, REGISTER or malformed messages can exhaust transaction processing.
 - Simple rate-limiting example for 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 (published May 17, 2024): In specific Asterisk releases, `res_pjsip_endpoint_identifier_ip` could misidentify unauthorized SIP requests as a local endpoint, potentially enabling unauthorized actions or information exposure. Fixed in 18.23.1, 20.8.1 and 21.3.1. Validate your PBX version when testing and report responsibly.<sup>[[3]](#references)</sup>
 
 ### SDP/ICE candidate parsing as an RCE surface
 
 SIP endpoints often parse **embedded SDP** from `INVITE` requests before authentication or user interaction. If optional **ICE** support is enabled, `a=candidate:` attributes become an extra parser attack surface that is easy to miss during reviews because the bug lives in the **SDP helper**, not in the top-level SIP state machine.<sup>[[1]](#references)</sup>
 
 - **Reachability pattern**: `INVITE` over UDP/5060 -> `Content-Type: application/sdp` -> SDP line starting with `a=candidate:` -> ICE-specific parser.
 - **Common bug class**: copy the full candidate line into a **fixed stack buffer** with `memcpy`/`strcpy` and then NUL-terminate it **without checking the destination size**.
 - **Exploit validation on ARM**: build the candidate as `a=candidate:` + fill bytes + register markers, then confirm control of saved registers / `pc` in the crash dump. When the exact prefix length matters, count protocol bytes first.
 - **Why this matters**: SIP parsers frequently run as a privileged monolithic process inside phones/PBX components, so a parser bug in a rarely-used feature can still become **unauthenticated RCE**.
 
 Minimal malformed body pattern:
 
 ```text
 c=IN IP4 192.0.2.10
 m=audio 40000 RTP/AVP 0
 a=rtpmap:0 PCMU/8000/1
 a=candidate:AAAA...[oversized candidate line]...
 ```
 
 #### Practical exploitation workflow for SIP/SDP parser bugs
 
 1. **Confirm the feature gate**: look for device/PBX options enabling ICE, TURN, STUN, SRTP negotiation, video, or vendor extensions.
 2. **Trigger the parser with a valid SIP envelope** so the malformed field reaches the deep protocol helper instead of being rejected by superficial syntax checks.
 3. **Measure the exact overwrite layout** from the field prefix to the saved return state (`pc`/`lr` on ARM, `rip` on x86_64).
 4. **Run `checksec` / inspect mitigations** to decide between shellcode, ret2libc, or a full ROP chain.
 5. If **NX** is enabled and the main binary is non-PIE but loaded at addresses containing **NUL bytes**, check `/proc/<pid>/maps` for **shared libraries mapped at stable non-null bases** and pivot the ROP chain there instead of using low-address gadgets from the main binary.
 
 > [!TIP]
 > Text-based protocol exploit development is often constrained by forbidden bytes (`0x00`, `\r`, `\n`, separators such as `:` or space). When choosing gadgets or fake arguments, validate that the full address encoding survives the parser and any tokenization step.
 
 ### Hardening checklist (SIP-specific)
 
 - Prefer TLS for signaling and SRTP/DTLS-SRTP for media; disable cleartext where feasible.
 - Enforce strong passwords and digest algorithms (SHA-256/512-256 where supported; avoid MD5).
 - For 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 information leakage.
 - Strict `OPTIONS` handling and rate limits; disable unused methods (e.g., `MESSAGE`, `PUBLISH`) if not required.
 
 ## References
 
 - [1] [Rapid7: CVE-2026-0826 - Critical unauthenticated stack buffer overflow in HP Poly VVX and Trio VoIP Phones](https://www.rapid7.com/blog/post/ve-cve-2026-0826-critical-unauthenticated-stack-buffer-overflow-hp-poly-vvx-trio-voip-phones-fixed/)
 - [2] [RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too)](https://www.rfc-editor.org/rfc/rfc8760)
 - [3] [Asterisk Security Advisory GHSA-qqxj-v78h-hrf9 for CVE-2024-35190](https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9)
 - [4] [RFC 3261 – SIP: Session Initiation Protocol](https://www.rfc-editor.org/rfc/rfc3261)
 - [5] [IANA – Session Initiation Protocol (SIP) Parameters](https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml)