 currently working at 131.160.1.112, answers the call. The forking proxy receives a 200 OK from SIP:Bob@131.160.1.112 and it for- wards this response to Laura's UA. Because the session is already estab- lished between Laura and Bob, the forking proxy wants to stop the other searches initiated, so it sends two CANCELs, one to each location, to close out the searches (Figure 5-5). Remember that a CANCEL request does not affect a transaction once a final response has been sent. Therefore, in our example, even if the forking proxy sends a CANCEL to SIP:Bob@131.160.1.112, the session between Bob and Laura would persist. CANCEL cannot terminate an ongoing trans- action. It is ignored by completed transactions. Forking 131.160.1.112 Figure 5-5 Laura proxy company.com university.com Proxy canceling INVITE transactions. (1) INVITE (2) INVITE (3) INVITE (4) INVITE (5) 200 OK (6) 200 OK (7) ACK Conversation (8) CANCEL (9) 200 OK (10) 487 Cancelled (11) ACK (12) CANCEL (13) 200 OK (14) 487 Cancelled (15) ACK SIP: Protocol Operation BYE BYE requests are used to abandon sessions. In two-party sessions, abandonment by one of the parties implies that the session is terminated. For instance, when Bob sends a BYE to Laura, their session is automati- cally terminated (Figure 5-6). In multicast scenarios, however, a BYE request from one of the participants just means that a particular partici- pant leaves the conference. The session itself is not affected. In fact, it's common practice in large multicast sessions to not send a BYE when leav- ing the session. REGISTER Users send REGISTER requests to inform a server (in this case, referred to as a registrar) about their current location. Bob can send a REGISTER to the registrar at company.com directing that all incoming requests for SIP:Bob.Johnson@company.com should be proxied, or redi- rected, to SIP:Bob@131.160.1.112 (Figure 5-7). SIP servers are usually co-located with SIP registrars. A SIP registrar can send all information received in various REGISTER requests to a sin- gle loca