Search K
Appearance
Appearance
Other ways to support HackTricks:
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:
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:
โ ๏ธ
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:
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/8000te
INVITE sip:jdoe@example.com SIP/2.0
- This line indicates the method (INVITE), the request URI (sip:jdoe@example.com), and the SIP version (SIP/2.0).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.Max-Forwards: 70
- This header field limits the number of times the request can be forwarded by proxies to avoid infinite loops.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).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). The "tag" parameter is used to uniquely identify the sender's role in the dialog.Call-ID: a84b4c76e66710
- The Call-ID header uniquely identifies a call session between two user agents.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.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.User-Agent: ExampleSIPClient/1.0
- The User-Agent header provides information about the software or hardware of the sender, including its name and version.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.Content-Type: application/sdp
- The Content-Type header specifies the media type of the message body, in this case, SDP (Session Description Protocol).Content-Length: 142
- The Content-Length header indicates the size of the message body in bytes.v=0
- Protocol version (0 for SDP)o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
- Originator and session identifiers=-
- 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).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:
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), and the user's contact address (sip:alice@192.168.1.100:5060).
cssCopy codeSIP/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.
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 Authorizarion response is calculated:
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}")
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.
โน๏ธ
It's not mentioned, but User B needs to have sent a REGISTER message to Proxy 2 before he is able to receive calls.
Other ways to support HackTricks: