th requests and responses may contain message bodies, separated from the message headers by an empty line. The message body carried by SIP messages is usually a session description, but it can consist of any opaque object. Because SIP proxies do not need to examine the message SIP: Protocol Operation Laura SIP proxy Figure 5-21 Via headers store (1) INVITE SIP:Bob.Johnson@company.com SIP/2.0 Via: SIP/2.0/UDP workstation1000.university.com 5060 (2) INVITE SIP:Bob@131.160.1.112 SIP/2.0 the path taken by Via: SIP/2.0/UDP 131.160.1.100: 5060 a request. Via: SIP/2.0/UDP workstation1000.university.com 5060 (3) 200 OK Via: SIP/2.0/UDP 131.160.1.100: 5060 Via: SIP/2.0/UDP workstation 1000.university.com: 5060 (4) 200 OK Via: SIP/2.0/UDP workstation 1000.university.com: 5060 (5) ACK Bob.Johnson@company.com SIP/2.0 Via: SIP/2.0/UDP workstation1000.university.com: 5060 Conversation (6) BYE SIP:Bob.Johnson@company.com SIP/2.0 Via: SIP/2.0/UDP workstation1000.university.com 5060 (7) 200 OK Via: SIP/2.0/UDP workstation1000 .university.com: 5060 tion1000.university.com 131.160.1.100 131.160.1.112 body, content is transparent to them. As a result, session descriptions are transmitted end to end between UAs. All information proxies need in order to route SIP messages is contained in the request and status lines and in the SIP headers. Because SIP bodies are only meaningful to the UA, message bodies can be encrypted end to end without losing any functionality. Some proxies, however, might want to examine the session description. An example is a security proxy (firewall) that wants information about media being exchanged SO that it can exclude unauthorized flows. For instance, if a company decides that its employees cannot establish video- conferences, the firewall can intercept all video streams while still letting audio streams pass through. The following is an example of an SDP session description in a SIP body: o=Bob 2890844526 2890842807 IN IP4 131.160.1.112 s=I want to know how you are doing c=IN IP4 131.160.1.112 t=0 0 m=aud