eries of lost packets on a heavily loaded IP link can cause retrans- missions, which in turn produce more lost packets and can push the link into congestion collapse. Also, UDP may only be used for SIP when the message (and its response) is known to be less than the Message Transport Unit (MTU) size of the IP network. For simple SIP messages, this is not a problem. However, for large messages containing multiple message bodies and large header fields, this can be a problem. In this case, TCP must be used, since SIP does not support fragmenta- tion at the SIP layer. 100.101.102.103 200.201.202.203 UDP Datagram Source IP: 100.101.102.103 Source port: 42172 Destination IP: 200.201.202.203 Destination port: 5060 200 OK UDP Datagram Source IP: 200.201.202.203 Source port: 60134 Destination IP: 100.101.102.103 Destination port: 5060 Figure 2.5 Transmission of SIP messages using UDP. SIP: Understanding the Session Initiation Protocol 2.5.2 TCP Transport TCP provides a reliable transport layer, but at a cost of complexity and transmis- sion delay over the network. The use of TCP for transport in a SIP message exchange is shown in Figure 2.6. This example shows an INVITE sent by a user agent at 100 101.102.103 to a type of SIP server called a redirect server at 200.201.202.203. A SIP redirect server does not forward INVITE requests like a proxy, but looks up the destination address and instead returns that address in a redirection class (3xx) response. The 302 Moved Tempo- rarily response is acknowledged by the user agent with an ACK message. shown in this figure is the next step, where the INVITE would be re-sent to address returned by the redirect server. As in the UDP example, the well-known SIP port number of 5060 is chosen for the destination port, and the source port is chosen from an available pool of port numbers. Before the message can be sent, however, the TCP connection must be opened between the two end points. This transport layer datagram exchange is shown in Figure 2.6 as a single arrow, but it is actually 