Transactions

8.1 A transaction: one request and all its responses

SIP does its work in small exchanges. Each exchange is a transaction:

A transaction has two sides. The client transaction sends the request and receives the responses. The server transaction receives the request and sends the responses. Above each side sits the transaction user (TU): the UA core in a phone, or the proxy core in a stateful proxy. The TU decides what to send; the transaction makes sure it arrives.

Transactions exist hop by hop. In a call from Alice through Proxy B to Bob, there are two INVITE transactions: Alice’s client transaction with Proxy B’s server transaction, and Proxy B’s client transaction with Bob’s server transaction. A stateless proxy is not part of either:

8.2 How elements match a transaction

Every request carries a branch in its top Via. The branch names the transaction, so it must be new for every new request:

The branch starts with the magic cookie z9hG4bK. The cookie tells the receiver that the sender follows RFC 3261, so the branch is unique and can be used as the key:

The two sides match differently:

There is one exception for the method: an ACK matches the INVITE transaction it acknowledges.

Pick a message below and watch Bob — or Alice — look for its transaction.

Via: SIP/2.0/UDP 192.0.2.10:5060;branch=z9hG4bK74bf9
CSeq: 1 INVITE

8.3 Four state machines

RFC 3261 defines a state machine for each side of each kind of transaction. INVITE is different because a person must answer it: it can take many seconds, so it uses a three-way handshake (INVITE, final response, ACK). Every other method is a quick two-way exchange.

The player shows one hop: Alice’s client transaction on the left, Bob’s server transaction on the right, and the messages between them. Step through the call, then press Lose this… on any message and watch the timers take over.

Things to try:

• INVITE, 486, lose the 486. Timer G sends it again after 500 ms; Alice’s transaction, already waiting in Completed, ACKs the copy.
• INVITE, Bob is down, UDP. Seven INVITEs, then Timer B ends the attempt at 32 s. Switch to TCP: the connection fails at once.
• OPTIONS, answers after 6 s. Bob sends 100 Trying at 3.5 s, and Alice’s retransmissions slow down to one every 4 s.
• INVITE, 200 OK, every ACK lost. The 32-second drop — see Common mistakes below.

8.4 Timers

All the timers grow from three values:

Retransmit timers start at T1 and double. For an INVITE, there is no cap:

For everything else, the interval stops growing at T2:

Timeout timers are 64×T1 — 32 seconds by default:

Timer C is a proxy timer: a stateful proxy uses it to give up on an INVITE branch that has no final response after more than 3 minutes.

Change T1 below and see every schedule stretch with it. A larger T1 suits slow links, such as satellite; the RFC allows it.

8.5 Retransmissions: UDP only

UDP gives no delivery guarantee, so the transaction layer retransmits. TCP and TLS deliver every byte or report an error, so the transaction layer does not:

A retransmission is a byte-for-byte copy: same branch, same CSeq, same everything. The receiver’s transaction absorbs it, and may answer with the last response it sent. The 100 Trying exists mainly to stop INVITE retransmissions early:

8.6 ACK for a non-2xx and ACK for a 2xx

The ACK comes in two kinds, and they behave very differently:

Why the difference? A forked INVITE can be answered by several phones, and the caller must see — and ACK — every 2xx. So proxies forward each 2xx, and the 2xx and its ACK travel between the two UAs. The callee’s UA core sends the 2xx again until the ACK arrives, even over TCP, because a later hop may be UDP:

8.7 CANCEL: its own transaction, aimed at another

A CANCEL copies the top Via of the INVITE it cancels — with the same branch — so each hop can find that INVITE:

But its CSeq method is CANCEL, so it is a transaction of its own, with its own 200 OK:

The result is two transactions on each hop: the CANCEL transaction, answered 200 OK, and the INVITE transaction, which ends with 487 Request Terminated and its ACK. Like the ACK for a non-2xx, a CANCEL is hop by hop: each proxy answers it and sends its own CANCEL downstream.

8.8 Later fixes: RFC 6026 and RFC 4320

Field experience found two problems in the RFC 3261 machines.

RFC 6026: the Accepted state. In RFC 3261, an INVITE transaction ends the moment it sends or receives a 2xx. A late copy of the INVITE then matches nothing, and a proxy may treat it as a new call:

RFC 6026 adds an Accepted state on both sides. The transaction stays there for 64×T1 (Timer L on the server, Timer M on the client), absorbs INVITE copies, and passes each 2xx and ACK to the TU:

It also stops proxies from forwarding stray responses — responses that match no transaction — which attackers could use to bounce traffic:

Switch the RFC 6026 box in the player above on and off to compare the two machines.

RFC 4320: non-INVITE fixes. A non-INVITE transaction must finish quickly, so RFC 4320 removes two kinds of useless messages. Only 100 is allowed as a provisional response — and over UDP, only after Timer E has grown to T2:

And a late 408 is pointless, because the client has already timed out:

Common mistakes

Summary

• A transaction is one request and its responses, between a client transaction and a server transaction on one hop. UAs and stateful proxies keep transactions; stateless proxies do not.
• The top Via branch, starting with z9hG4bK, names the transaction. Servers also compare the sent-by and the method; clients compare the CSeq method.
• Four state machines: INVITE and non-INVITE, client and server.
• Over UDP, requests and responses are retransmitted at T1, 2×T1, 4×T1… (capped at T2 except for Timer A). After 64×T1 = 32 s, the attempt times out. Over TCP and TLS, the transaction layer does not retransmit.
• The ACK for 300–699 is part of the INVITE transaction: same branch, hop by hop. The ACK for 2xx is a new transaction: new branch, end to end. A lost ACK for a 2xx ends the call after 32 seconds.
• CANCEL shares the INVITE’s branch but is its own transaction.
• RFC 6026 adds the Accepted state and stops stray responses; RFC 4320 removes late 408s and early provisional responses to non-INVITE requests.