Headers and parameters

7.1 The headers in every request

Six headers are the minimum for any request; an INVITE also needs Contact.

The header reference below covers these and about forty more. Search for a header, or pick a group, to see who adds, changes, and removes it.

Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK74bf9;rport

Watch the headers travel

Here is one INVITE on its way from Alice’s phone, behind a NAT router, through Proxy A, an SBC, and Proxy B to Bob’s phone. Each column is one hop; each marked cell is a change at that hop. Turn on Show only the headers that change to see what each element does.

7.2 Tags

A tag is a random string in From and To. The UAC adds its tag to From in the first request; the UAS adds its tag to To in its response. Together with the Call-ID, the two tags name the dialog.

Why two tags, and not just the Call-ID? Because a forked INVITE can be answered by several phones. Each one adds its own To tag, so the caller can tell the dialogs apart:

Every request inside the dialog repeats both tags, in the right places. From the caller’s side, From carries the caller’s tag; from the callee’s side — for example in Bob’s BYE — the two swap: From carries Bob’s tag, To carries Alice’s.

7.3 Via parameters

In the journey above, Alice’s phone writes its private address in Via and adds an empty rport. Proxy A fills in what it really saw: received=192.0.2.10;rport=40112 — the public address and port of the NAT router (Module 2).

7.4 Contact parameters

Contact: <sip:alice@192.0.2.10:5060;transport=tcp>;expires=3600;q=1.0
  ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>";reg-id=1

7.5 URI parameters

URI parameters live inside the angle brackets (Module 4):

7.6 Routing headers

Record-Route is added by a proxy that wants to see the rest of the dialog. The UAs turn the list into a route set, and later requests carry it as Route headers. Each proxy removes its own Route entry. Module 10 explains the details; for now, notice in the journey that Proxy A and Proxy B add Record-Route — and that the SBC removes Proxy A’s entry to hide the inner network.

7.7 Identity and privacy

The From header is written by the caller’s phone, so it proves nothing. A network that has authenticated the caller says so in P-Asserted-Identity (PAI):

• The phone may suggest which of its identities to use with P-Preferred-Identity. The first trusted proxy removes it and adds PAI.
• PAI is trusted only inside a trust domain — between elements that have agreed to trust each other, such as a carrier and its customers’ SBCs. A proxy that receives PAI from an untrusted source must replace or remove it:

• Privacy asks the network to hide things. Privacy: id asks the network to remove PAI before the call leaves the trust domain; the caller’s phone also writes an anonymous From.

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
P-Asserted-Identity: "Alice" <sip:alice@atlanta.example>, <tel:+14045550101>
Privacy: id

7.8 Redirect history: Diversion and History-Info

When a call is forwarded, the new target often needs to know who was called first and why the call moved — a voicemail system needs to know whose mailbox to open.

• Diversion (RFC 5806) answers both questions in one entry per forwarding. The RFC is Historic, but many carriers and PBXs still use it.

Diversion: <sip:+14045550102@atlanta.example>;reason=no-answer;counter=1

• History-Info (RFC 7044) is the standard replacement. Each element that forwards the request adds an entry, with an index that shows the order and a parameter that shows how the target changed: rc (same user, new Contact), mp (another user), or np (no change).

History-Info: <sip:bob@biloxi.example>;index=1
History-Info: <sip:bob@biloxi.example>;np=1;index=1.1
History-Info: <sip:bob@203.0.113.20>;index=1.1.1;rc=1.1

7.9 Session timers

SIP has no built-in keepalive for a call. If a BYE is lost, or a phone crashes, the proxies and the other phone may keep the call open for hours. Session timers (RFC 4028) fix this: one side refreshes the session with a re-INVITE or an UPDATE, and if no refresh comes, both sides end the call.

The refresher sends its refresh halfway through the interval:

In the journey above, Proxy B lowers Session-Expires from 1800 to 900: it wants to know within 15 minutes if a call is dead.

7.10 Other headers you will meet

Common mistakes

Summary

• Every request has Via, Max-Forwards, From, To, Call-ID, and CSeq; an INVITE also has Contact.
• The From tag and the To tag, with the Call-ID, name a dialog. They never change inside it.
• Via gets received and rport from the next hop, so responses find their way back through NAT.
• Contact parameters (expires, q, +sip.instance, reg-id) describe a registration; URI parameters (transport, lr, user=phone, ob) describe how to reach a URI.
• P-Asserted-Identity is a verified identity, trusted only inside a trust domain. Privacy: id hides it outside that domain.
• Diversion and History-Info record why a call was forwarded.
• Session-Expires and Min-SE make sure a dead call ends, even when a BYE is lost.