SIP (Session Initiation Protocol)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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:
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.
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.
Interoperability: SIP's widespread adoption and standardization ensure better interoperability between different devices, applications, and service providers, promoting seamless communication across various platforms.
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.
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.
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.
The core SIP methods defined in RFC 3261 include:
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.
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.
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.
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.
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.
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.
Note that to call someone it's not neccesary 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.
In addition to these core methods, there are several SIP extension methods defined in other RFCs, such as:
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.
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.
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.
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.
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.
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.
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.
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:
Initial REGISTER request from UA to the registrar server:
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), and the user's contact address (sip:alice@192.168.1.100:5060).
401 Unauthorized response from the registrar server:
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.
REGISTER request with authentication credentials:
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 Authorizarion response is calculated:
Successful registration response from the registrar server:
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.
It's not mentioned, but User B needs to have sent a REGISTER message to Proxy 2 before he is able to receive calls.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
