2.1 Addresses, ports, and sockets
Every SIP message travels inside an IP packet. Three ideas explain where it goes.
- An IP addressIP address. The address of a network interface. IPv4 addresses look like 192.0.2.10; IPv6 addresses look like 2001:db8::10. identifies a network interface. IPv4 addresses have four numbers, such as
192.0.2.10. IPv6 addresses have up to eight groups of hexadecimal digits, such as2001:db8::10. - A portport. A number from 0 to 65535 that selects one application on a host. SIP usually listens on 5060 (5061 for TLS). selects one application on that interface. A SIP phone usually listens on port
5060. - A socketsocket. One end of a network conversation, written as IP address and port, such as 192.0.2.10:5060. is the combination:
192.0.2.10:5060. A conversation between two sockets, over one transport, is a flow:
UDP 192.0.2.10:5060 → 198.51.100.10:5060
source socket destination socket
Ports you will see in SIP traces
| Port | Transport | Used for |
|---|---|---|
5060 |
UDP or TCP | SIP |
5061 |
TLS (over TCP) | SIP, encrypted |
53 |
UDP (and TCP) | DNS |
3478 |
UDP or TCP | STUN and TURN (Module 20) |
A range, often 10000–20000 |
UDP | RTP and RTCP. Each device chooses its own range. |
443 |
TCP | Secure WebSocket, often used by WebRTC clients (Module 26) |
“For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number.”Read the section ↗
Private and public addresses
Some IPv4 ranges are reserved for private networks: homes, offices, and the inside of data centres. Routers on the Internet do not forward packets to these addresses.
“The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:”Read the section ↗
Type an address, or pick an example. The table shows which range it belongs to.
Address check
Is this address reachable from the Internet?
⚠ Private address
IPv4 · in 192.168.0.0/16 · RFC 1918
Not reachable from the Internet. If it appears in a Contact header or in SDP that leaves the network, calls break.
In a SIP trace: this address in a Via, Contact, or SDP c= line that reaches the Internet is a NAT problem waiting to happen (Module 20).
| Range | Kind | Defined in |
|---|---|---|
10.0.0.0/8 | Private | RFC 1918 |
172.16.0.0/12 | Private | RFC 1918 |
192.168.0.0/16 | Private | RFC 1918 |
100.64.0.0/10 | Shared (carrier-grade NAT) | RFC 6598 |
127.0.0.0/8 | Loopback | RFC 1122 |
169.254.0.0/16 | Link-local | RFC 3927 |
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | Documentation (examples) | RFC 5737 |
fc00::/7 | Unique local (IPv6) | RFC 4193 |
fe80::/10 | Link-local (IPv6) | RFC 4291 |
2001:db8::/32 | Documentation (IPv6) | RFC 3849 |
everything else | Public | — |
2.2 UDP and TCP, the short version
IP delivers packets, one at a time, without guarantees. A transport runs on top of it. SIP can use several transports (Module 19); the two basic ones are UDP and TCP.
“All SIP elements MUST implement UDP and TCP.”Read the section ↗
| UDPUDP. A transport that sends independent packets with no connection and no retransmission. SIP over UDP retransmits by itself. | TCPTCP. A transport that opens a connection and delivers a reliable, ordered byte stream. | |
|---|---|---|
| Connection | None. Each packet stands alone. | Opened first, with a three-way handshake |
| Lost packets | Lost. SIP itself retransmits. | TCP retransmits. SIP does not. |
| Message boundaries | One SIP message per packet | A byte stream. SIP uses Content-Length to find where each message ends. |
| Large messages | Can be fragmented, and fragments get lost | No problem |
| Typical use | Most phones and trunks | TLS, WebSocket, large messages, some trunks |
Compare the two. In both flows, one packet is lost. Watch who sends it again.
UDP
OPTIONS over UDP, with one packet lost
- SIP
Alice's phone sends OPTIONS over UDP, with no connection setup. The network drops this packet.
All steps as text
- Alice → Proxy A: OPTIONS. Alice's phone sends OPTIONS over UDP, with no connection setup. The network drops this packet.
- Alice → Proxy A: OPTIONS (retransmission). No response came within 500 ms (Timer E = T1). SIP itself sends the same request again.
- Proxy A → Alice: 200 OK. Proxy A answers. The whole exchange used just three packets.
“If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds.”Read the section ↗
UDP has one more limit. A big SIP message — an INVITE with many codecs, video, and encryption keys — may not fit in one packet. RFC 3261 says when to switch to TCP:
“If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP.”Read the section ↗
2.3 DNS: from names to addresses
A phone is usually configured with a name, such as proxy.atlanta.example, not an IP address. Before the first SIP packet, it asks a DNS resolverDNS resolver. The server that a device asks to look up DNS names for it. to translate the name.
Before SIP: DNS
A DNS lookup before the first request
- SIP
- DNS / STUN / ICE
The phone knows the name proxy.atlanta.example, not its address. It asks its DNS resolver.
All steps as text
- Alice → DNS resolver: DNS query (A). The phone knows the name proxy.atlanta.example, not its address. It asks its DNS resolver.
- DNS resolver → Alice: DNS answer (A). The resolver returns the IPv4 address. The phone can keep it for 300 seconds, the TTL.
- Alice → DNS resolver: DNS query (AAAA). The phone also asks for AAAA records, which hold IPv6 addresses.
- DNS resolver → Alice: DNS answer (AAAA). The name also has an IPv6 address. This phone has only IPv4, so it uses the A record.
- Alice → Proxy A: OPTIONS. Now the phone sends SIP to 198.51.100.10. The Request-URI still contains the name.
- Proxy A → Alice: 200 OK. Proxy A answers. DNS cost two round trips before the first SIP packet.
- An A record holds an IPv4 address; an AAAA record holds an IPv6 address.
- Every answer has a TTL (time to live): how many seconds the answer may be cached.
- SIP also uses SRV and NAPTR records, which tell a client which server, port, and transport to use. Module 11 covers them.
2.4 What NAT does to a packet
Most phones sit behind a NATNAT. A router function that rewrites private addresses and ports into public ones, and back. router. The router lets many private addresses share one public address. For every packet that goes out, it rewrites the IP source address and the UDP source port, and remembers the change in a mapping table, so it can send replies back.
The router changes the IP and UDP headers. It does not change the addresses written inside the SIP text. Step through a registration, then turn rport off.
NAT
What a NAT router does to a SIP packet
| IP source | 192.168.1.20 |
|---|---|
| UDP source port | 5060 |
| IP destination | 198.51.100.10 |
| UDP destination port | 5060 |
| Via | SIP/2.0/UDP 192.168.1.20:5060;rport;branch=z9hG4bKnat01 |
| Contact | <sip:alice@192.168.1.20:5060> |
NAT mapping table
Empty. The router creates a mapping when the first packet goes out.
Alice's phone sends REGISTER. Inside the home network, every address is private.
“If this Via header field value contains an "rport" parameter with no value, it MUST set the value of the parameter to the source port of the request.”Read the section ↗
Two more facts explain most NAT problems in SIP:
- The mapping lasts only while packets flow. If nothing passes for a while, the router forgets it, and incoming requests can no longer get in.
“There is great variation in the values used by different NATs. REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies.”Read the section ↗
- The private Contact address means that nobody outside can reach the phone directly — unless something fixes it. Module 20 covers the fixes: rport, keepalives, Contact rewriting, SIP Outbound, and media relays.
2.5 How a packet capture shows the layers
A packet capture (from Wireshark, tcpdump, or sngrep) shows each packet as a stack of layers. This is the first REGISTER from Module 13, wrapped in real Ethernet, IPv4, and UDP headers. Select a layer or a field to see its bytes; point at the bytes to find their field.
Packet capture
One SIP REGISTER, layer by layer
- Ethernet, IP, UDP
- SIP
Frame: 378 bytes · 192.0.2.10:5060 → 198.51.100.20:5060 · UDP · SIP REGISTER
Source address · bytes 26–29
192.0.2.10
Where the packet comes from. A NAT router rewrites this field.
Capture tips
Where you capture changes what you see. On the phone, you see private addresses. Outside the NAT router, you see public ones. On the server, you see the server’s view. Always note where a trace was taken.
| Goal | Wireshark display filter | tcpdump capture filter |
|---|---|---|
| All SIP | sip |
port 5060 or port 5061 |
| SIP and its media | sip or rtp or rtcp |
port 5060 or udp portrange 10000-20000 |
| One call | sip.Call-ID == "3848276298220188511@192.0.2.10" |
— (filter later in Wireshark) |
| DNS too | sip or dns |
port 5060 or port 53 |
Common mistakes
“The source port is the port the phone listens on”
Behind NAT, the router changes the source port: a phone listening on 5060 appears as 40112. Over TCP, the operating system picks a random client port, such as 49152. The port where the phone listens is in the Via and Contact headers — not in the UDP or TCP header.
Remember: replies follow the Via header, with rport and received (Modules 10 and 20). Requests to the phone follow its Contact.
Capturing only port 5060
A filter on port 5060 misses SIP over TLS on 5061, SIP on non-standard ports (5080 and others are common), DNS lookups, and all RTP. The packet that explains the problem is often the one you did not capture.
Remember: capture wide first, then filter in Wireshark.
“Every private address in a trace is a bug”
Inside a home or office network, private addresses are normal. They become a problem only when they leave the network inside a SIP message: in a Via, a Contact, or an SDP c= line that reaches the Internet.
Remember: ask “which side of the NAT was this trace captured on, and where is this message going?”
“UDP is unreliable, so SIP over UDP is unreliable”
SIP over UDP has its own retransmission timers. A lost request is sent again after 500 ms, then 1 s, 2 s, and so on. That is why you often see the same message several times in a UDP trace — and why those copies are not separate calls.
Remember: retransmissions have the same Via branch and CSeq. Module 8 covers the timers.
Ignoring DNS
A wrong or slow DNS answer looks like a SIP problem: timeouts, calls to an old server, or failures in one site only. Cached answers can keep the wrong address alive for the whole TTL.
Remember: include DNS in your captures, and check the TTL of the records you depend on.
Summary
- An IP address finds the host, a port finds the application, and the two together form a socket. SIP uses 5060 (UDP or TCP) and 5061 (TLS); RTP uses a range of even ports.
- Private addresses (RFC 1918) are not reachable from the Internet. In SIP, they cause trouble when they appear inside messages that leave the network.
- Over UDP, SIP retransmits lost messages itself. Over TCP, TCP does it. Large messages must use TCP.
- DNS turns names into addresses before the first SIP packet. A records hold IPv4 addresses; AAAA records hold IPv6 addresses.
- A NAT router rewrites the IP source and the UDP port, but not the addresses inside SIP. rport lets replies find their way back; mappings expire when traffic stops.
- A capture shows Ethernet, IP, UDP, and SIP. Note where it was taken, and capture wide before you filter.