Route and Record- Route. A proxy may want to remain in the signalling path after the first INVITE for many reasons. One of them is security. Some domains have a security proxy, a firewall, that filters incoming SIP messages. SIP messages that do not successfully traverse the security proxy are not accepted into the domain. Another reason is service provision. A proxy that provides a session-related service needs to know as a matter of course when the ses- sion is over; for our purposes, this is when one UA sends a BYE request to another. We saw already an example of such a service in Figure 5-9. The call stateful proxy of that example had to see the BYE from Laura to Bob in order to e-mail Bob with information about the duration of the call. Figure 5-18 illustrates how these two headers work. Laura sends an INVITE to Bob. The INVITE traverses a SIP proxy that wishes to be in the signalling path for subsequent requests between Laura and Bob. The proxy adds a Record-Route header containing its address to the INVITE. Bob's Chapter 5 Laura SIP proxy Figure 5-18 Route headers have a (1) INVITE SIP: Bob.Johnson@company.com SIP/2.0 (2) INVITE SIP:Bob@131.160.1.112 SIP/2.0 proxy staying in the Record-Route:<SIP:Bob.Johnson@company.com; signalling path maddr=131.160.1.112 throughout the (3) 200 OK Contact: <SIP:Bob@131.160.1.112: whole session. Record-Route:<SIP:Bob.Johnson@company.com; (4) 200 OK maddr=131.160.1.112 Contact:<SIP:Bob@131.160.1.112> Record-Route:<SIP:Bob.Johnson@company.com; (5) ACK SIP:Bob.Johnson@company.com SIP/2.0 maddr=123.160.1.110 Route:<SIP:Bob@131.160.1.112> (6) ACK SIP:Bob@131.160.1.112 SIP/2.0 Conversation (7) BYE SIP: Bob.Johnson@company.com SIP/2.0 Route:<SIP: Bob@131.160.1.112 (8) BYE SIP:Bob@131. 160.1.112 SIP/2.0 (9) 200 OK (10) 200 OK UA receives the INVITE complete with this Record-Route header and includes it in the 200 OK response. Bob's UA also adds its Contact header to the response. The maddr parameter that appears in the Record-Route just contains the IP address of the server, which