2 Thus, it creates a new INVITE with Bob's location as the Request-URI, adding its address to the request as a Via header: 131.160.1.110. Notice that the message body remains untouched. SIP servers do not typically modify message bodies. Chapter 5 INVITE sip:Bob@131.160.1.112 SIP/2.0 Via: SIP/2.0/UDP 131.160.1.110 Via: SIP/2.0/UDP workstation1000.university.com:5060 From: Laura Brown <sip:Laura.Brown@university.com> To: Bob Johnson <sip:Bob.Johnson@company.com> Call-ID: 12345678@workstation1000.university.com CSeq: 1 INVITE Contact: Laura Brown <sip:Laura@workstation1000.university.com> Content-Type: application/sdp Content-Length: 154 o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com s=Let us talk for a while C=IN IP4 138.85.27.10 t=0 0 m=audio 20002 RTP/AVP 0 Provisional Response from Bob to Proxy Upon receiving the INVITE, Bob's UA must initiate alerting, SO it returns a provisional response announcing that alerting has begun. The Via headers are copied from the INVITE received. They will ensure that the response traverses the proxy first, 131.160.1.110, and then arrives at Laura's UA, worksta- tion1234.university.com at UDP port number 5060. Bob's UA adds a Contact header to the response containing the SIP URL where Bob can be reached directly; from now on, subsequent requests will be sent directly from Laura's UA to Bob's UA. Bob's UA also adds a tag parameter to the To header, naming the SIP UA that Bob is currently using. The tag info helps to differentiate the responses that Laura might get if a forking proxy in the path tried to reach Bob at sev- eral locations. To avoid confusing Laura's UA, each of Bob's UAs will have answered with a different tag. SIP/2.0 180 Ringing Via: SIP/2.0/UDP 131.160.1.110 Via: SIP/2.0/UDP workstation1000.university.com:! 5060 SIP: Protocol Operation From: Laura Brown <sip:Laura.Brown@university.com> To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159 Call-ID: 12345678@workstation1000.university.com CSeq: 1 INVITE Contact: Bob Johnson <sip:Bob@131.160.1.