Internet Engineering Task Force M. HASEBE Internet-Draft NTT-East Expiration: Apr 21th, 2006 J. KOSHIKO NTT-East Y. SUZUKI NTT-East T. YOSHIKAWA NTT-East Oct 21, 2005 Session Initiation Protocol Exceptional Procedure Examples draft-hasebe-sipping-exceptional-procedure-examples-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document gives examples of Session Initiation Protocol (SIP) exceptional-procedure call flows. These senarios are confusing and this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and Clients. The scenarios include SIP session establishment. Call flow diagrams and message details are shown. Table of Contents Hasebe [Page 1] Internet Draft Exceptional Procedure Examples Oct 21th,2005 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. General Assumptions. . . . . . . . . . . . . . . . . . . 3 1.2. Legend for Message Flows . . . . . . . . . . . . . . . . 3 1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . 4 2. Exceptional Procedure. . . . . . . . . . . . . . . . . . . . . 4 2.1. CANCEL crossover . . . . . . . . . . . . . . . . . . . . 5 2.2. BYE crossover. . . . . . . . . . . . . . . . . . . . . . 8 2.3. Session timer crossover(re-INVITE,BYE) . . . . . . . . . 12 2.4. REFER crossover(REFER,BYE) . . . . . . . . . . . . . . . 16 2.5. A BYE is sent immediately after sending of a re-INVITE . 20 2.6. re-INVITE crossover. . . . . . . . . . . . . . . . . . . 23 2.7. Initial INVITE retransmission. . . . . . . . . . . . . . 30 2.8. Early Dialog . . . . . . . . . . . . . . . . . . . . . . 32 2.9. CANCEL crossover via a stateful proxy. . . . . . . . . . 41 2.10. A retransmited 200 OK after sending a BYE. . . . . . . . 47 2.11. A BYE on the early dialog. . . . . . . . . . . . . . . . 51 3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4. Intellectual Property Statement. . . . . . . . . . . . . . . . 54 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 55 1. Overview The call flows shown in this document were derived in the design of a SIP IP communications network. These examples are difficult to interpret the behaviors of user agent based on RFCs. In various situations which may happen when SIP is implemented, especially,when a situation which serves as a norm of inplementing in RFC is not illustrated, by showing operation of a terminal or a server as an example, it will be a help to a SIP implementors. For example, the sequence which CANCEL and 200 OK for INVITE cross each other is possible. INVITE transaction obviously exists from UAC's point of view, when the UAC sends a CANCEL message. However, when the UAS sends a 200 OK response for INVITE and then receives CANCEL message, there is not INVITE transaction anymore from UAS's point of view. In such a case, it's not easy to specify the response from the UAS in RFCs. This document clarifies SIP UA behaviors when messages cross each other as exceptional-procedure conditions. By clarifying operation under exceptional-procedure conditions, different interpretations between implementations are avoided and interoperability is expected to be promoted. It is the hope of the authors that this document will be useful for SIP implementors, designers, and protocol researchers and will help them achieve the goal of a standard implementation of RFC 3261 [1]. Hasebe [Page 2] Internet Draft Exceptional Procedure Examples Oct 21th,2005 These call flows are based on the current version 2.0 of SIP in RFC 3261 [1] with SDP usage described in RFC 3264 [2]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4]. 1.1. General Assumptions A number of architecture, network, and protocol assumptions underlie the call flows in this document. Note that these assumptions are not requirements. They are outlined in this section so that they may be taken into consideration and help in understanding of the call flow examples. These flows do not assume specific underlying transport protocols such as TCP, TLS, and UDP. See the discussion in RFC 3261 for details on the transport issues for SIP. 1.2. Legend for Message Flows Dashed lines (---) and slash lines (/,\) represent signaling messages that are mandatory to the call scenario.(X) represents crossover of signaling messages. Arrow indicate the direction of message flow. Double dashed lines (===) represent media paths between network elements. Messages with parentheses around their name represent optional messages. Messages are identified in the Figures as F1, F2, etc. These numbers are used for references to the message details that follow the Figure. Comments in the message details are shown in the following form: /* Comments. */ 1.3. SIP Protocol Assumptions This document does not prescribe the flows precisely as they are shown, but rather illustrates the principles for best practice. They are best practice usages (orderings, syntax, selection of features for the purpose, or handling of error) of SIP methods, headers and parameters. NOTE: The flows in this document must not be copied as they are by implementors because additional characteristics were incorporated into the document for ease of Hasebe [Page 3] Internet Draft Exceptional Procedure Examples Oct 21th,2005 explanation. To sum up, the procedures described in this document represent well-reviewed examples of SIP usage, which are best common practice according to IETF consensus. For simplicity in reading and editing the document, there are a number of differences between some of the examples and actual SIP messages. Examples are: Call-IDs are often repeated; CSeq often begins, at 1; header fields are usually shown in the same order; usually only the minimum required header field set is shown; and and Accept, Allow, etc are not shown. Actors: Element Display Name URI IP Address ------- ------------ --- ---------- User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 Proxy Server ss.atlanta.example.com 192.0.2.111 2. Exceptional Procedures This section details exceptional procedures between two SIP User Agents (UAs): Alice and Bob. Alice (sip:alice@atlanta.example.com) and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP-enabled devices. This document clarifies how SIP UA should behave when messages cross each other in exceptional-procedure conditions. For example, the sequence which CANCEL and 200OK for INVITE cross each other is possible. INVITE transaction obviously exists from UAC's point of view, when the UAC sends a CANCEL message. However, when the UAS sends a 200 OK response for INVITE and then receives CANCEL message, there is not INVITE transaction anymore from UAS's point of view. Actually, the UAS state has already transit to confirmed dialog already. Examples of such exceptional procedures are shown below. 2.1. CANCEL crossover Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| Hasebe [Page 4] Internet Draft Exceptional Procedure Examples Oct 21th,2005 | | |CANCEL F3 200 OK F4 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | ACK F6 481 F5 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | Both Way RTP Media | |<======================>| | BYE F7 | |----------------------->| | 200 F8 | |<-----------------------| | | | | In this scenario, Alice sends a CANCEL and Bob sends a 200 OK response to the initial INVITE message at the same time. Then Bob sends a 481 response in response to the CANCEL from Alice. UAC can terminate the session by sending a BYE immediately after receiving 200 OK for INVITE. By transmitting a BYE after 200 OK, "it just means that the software in his phone needs to maintain state for a short while in order to clean up properly." (RFC3261,15) In this sequence, it is recommended that caller terminates the session by sending a BYE. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Hasebe [Page 5] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 CANCEL Alice -> Bob CANCEL sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 /* When Alice sends a CANCEL, INVITE transaction exists. */ F4 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 Hasebe [Page 6] Internet Draft Exceptional Procedure Examples Oct 21th,2005 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* Alice sends a CANCEL and Bob sends a 200 OK response to the initial INVITE message at the same time. From Bob's point of view, an INVITE transaction is completed by sending of the final response (200 OK). A 200 OK and a CANCEL crossed each other and inconsistency has arisen in the state of INVITE transaction of Alice and Bob. */ F5 481 Call/Transaction Dose Not Exist Bob -> Alice SIP/2.0 481 Call/Transaction Dose Not Exist Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 CANCEL Contact: Content-Length: 0 /* The final respons to INVITE transaction has already sent while CANCEL request targeting this INVITE transaction is received, so Bob returns a 481 response. */ F6 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* Bob has sent the final response, and a CANCEL becomes invalid. RTP streams are established.*/ F7 BYE Alice -> Bob Hasebe [Page 7] Internet Draft Exceptional Procedure Examples Oct 21th,2005 BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 F8 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 2.2. BYE crossover Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE F5 BYE F6 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | 481 F8 481 F7 | |--------- ----------| | \ / | | X | Hasebe [Page 8] Internet Draft Exceptional Procedure Examples Oct 21th,2005 | / \ | |<-------- --------->| | | | | In this scenario, Alice and Bob send a BYE at the same time. A session is ended shortly after a BYE request is passed to a client transaction. According to 15.1.1 of RFC3261, a dialog seems to be completed by a response or timeout of a BYE. Therefore, UA can normally transmit and receive a request until it receives a response. However, when UA sends a BYE, it determines that the dialog is completed. So, in this scenario, it is recommended that UA ends a dialog immediately after sending a BYE. In this case, both UA return a 481 response. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Hasebe [Page 9] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between Alice and Bob */ /* Bob hangs up with Alice. Note that the CSeq is NOT 2, since Alice and Bob maintain their own independent CSeq counts. (The INVITE was request 1 generated by Alice, and the BYE is request 1 generated by Bob) */ F5 BYE Alice -> Bob BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 Hasebe [Page 10] Internet Draft Exceptional Procedure Examples Oct 21th,2005 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Alice terminates a session by sending a BYE. RTP streams are terminated. */ /* The session is terminated by sending a BYE. Although the dialog is completed by receiving a response or a timeout, when UA sends a BYE, it determines that the dialog is completed. */ F6 BYE Bob -> Alice BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Content-Length: 0 /* Bob has also transmitted a BYE simultaneously with Alice. Bob terminates a session and dialog. */ F7 481 Call/Transaction Does Not Exist Bob -> Alice SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 ;received=192.0.2.201 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Since the dialog is already terminated, the BYE is returned by a 481. */ Editor's Note: UA would send a 200 OK response to the BYE or not? It is thought that it is necessary to clarify the dialog state. F8 481 Call/Transaction Does Not Exist Alice -> Bob Hasebe [Page 11] Internet Draft Exceptional Procedure Examples Oct 21th,2005 SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 BYE Content-Length: 0 /* Since Bob has terminated the dialog by sending a BYE, a BYE which Alice sent is also returned by a 481. */ 2.3. Session timer crossover(re-INVITE,BYE) Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE F5 re-INVITE F6| |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | 481 F8 200 F7 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | ACK F9 | |<-----------------------| | | In this scenario, Bob sends a re-INVITE, and Alice sends a BYE at the same time. The re-INVITE of Bob is returned by a 481. Although TU of Bob has terminated the dialog by sending a BYE, Hasebe [Page 12] Internet Draft Exceptional Procedure Examples Oct 21th,2005 the client transaction of a re-INVITE still exists. Therefore, a clienttransaction sends ACK to 481 response. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Supported: timer Session-Expires: 300 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Require: timer Session-Expires: 300;refresher=uas Hasebe [Page 13] Internet Draft Exceptional Procedure Examples Oct 21th,2005 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* Since there was no specification of refresher, Bob sets refresher=uas. */ F4 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between Alice and Bob */ /* Bob hangs up with Alice. Note that the CSeq is NOT 2, since Alice and Bob maintain their own independent CSeq counts. (The INVITE was request 1 generated by Alice, and the BYE is request 1 generated by Bob) */ F5 BYE Alice -> Bob BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 Hasebe [Page 14] Internet Draft Exceptional Procedure Examples Oct 21th,2005 /* Alice sends a BYE and terminates a session and dialog. */ F6 re-INVITE Bob -> Alice INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Session-Expires: 300;refresher=uac Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 /* Alice sends a BYE, and Bob sends a re-INVITE at the same time. From Alice's point of view, the dialog is completed, and in Bob's view, the dialog is terminated. The state of a dialog is mismatching. */ F7 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 ;received=192.0.2.201 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 F8 481 Call/Transaction Does Not Exist Alice -> Bob SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 /* Since Alice has already terminated the dialog by sending a BYE, she returns a 481. */ F9 ACK Bob -> Alice Hasebe [Page 15] Internet Draft Exceptional Procedure Examples Oct 21th,2005 ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 2.4. REFER crossover(REFER,BYE) Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | BYE F5 REFER F6 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | 481 F8 200 F7 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | | In this scenario, Bob sends a REFER, and Alice sends a BYE at the same time. Bob send a REFER in the same dialog. From Alice's point of view, as 2.2 described, a dialog is terminated by sending a BYE request, and Alice returns a 481 to the REFER. (If a dialog is terminated after receiving the response of a BYE or expiration of timer, Alice returns 202 to the REFER and the REFER method is successful. Also when a dialog is terminated, it is not clear whether UA continues call transfer. ) Hasebe [Page 16] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Supported: timer Session-Expires: 300 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Require: timer Session-Expires: 300;refresher=uas From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Hasebe [Page 17] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between Alice and Bob */ /* Bob hangs up with Alice. Note that the CSeq is NOT 2, since Alice and Bob maintain their own independent CSeq counts. (The INVITE was request 1 generated by Alice, and the BYE is request 1 generated by Bob) */ F5 BYE Alice -> Bob BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Alice sends a BYE and terminates a session and dialog. */ F6 REFER Bob -> Alice Hasebe [Page 18] Internet Draft Exceptional Procedure Examples Oct 21th,2005 REFER sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Refer-To: sip:carol@cleveland.example.org Contact: CSeq: 1 REFER Content-Length: 0 /* Alice sends a BYE, and Bob sends a REFER at the same time. Bob sends a REFER as REFER method in the same dialog. From Alice's point of view, the dialog is completed, and in Bob's view, the dialog is terminated. The state of a dialog is mismatching. */ F7 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 F8 481 Call/Transaction Does Not Exist Alice -> Bob SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 REFER Content-Length: 0 /* Since Alice has already terminated the dialog by sending a BYE, she returns a 481. */ 2.5. A BYE is sent immediately after sending of a re-INVITE Alice Bob | | | INVITE F1 | |----------------------->| Hasebe [Page 19] Internet Draft Exceptional Procedure Examples Oct 21th,2005 | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4 | |----------------------->| | Both Way RTP Media | |<======================>| | | | re-INVITE F5 | |<-----------------------| | 200 F7 BYE F6 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | 200 OK F8 | |----------------------->| | | | | In this scenario, Bob sends a BYE immediately after sending a re-INVITE, (A user is not conscious that refresher sends a re-INVITE automatically. For example, in the case of a telephone application, it is possible that a user places a receiver immediately after refresher.) When Alice receives a BYE other than ACK,she stops retransmitting of 200 OK. Since ACK for 2xx responses is not a server transaction, it is that UAS core transmits directly. this case is different from the case of an error response in 2.4. With UAS core, since the dialog which matches 200 OK received is terminated, 200 OK is ignored, without sending ACK. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Supported: timer Session-Expires: 300 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com Hasebe [Page 20] Internet Draft Exceptional Procedure Examples Oct 21th,2005 CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Require: timer Session-Expires: 300;refresher=uas From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Hasebe [Page 21] Internet Draft Exceptional Procedure Examples Oct 21th,2005 F4 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between Alice and Bob */ /* Bob hangs up with Alice. Note that the CSeq is NOT 2, since Alice and Bob maintain their own independent CSeq counts. (The INVITE was request 1 generated by Alice, and the BYE is request 1 generated by Bob) */ F5 re-INVITE Bob -> Alice INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Session-Expires: 300;refresher=uac Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 F6 BYE Bob -> Alice BYE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Bob sends a BYE immediately after sending of a re-INVITE, Bob terminates a session and dialog, without receiving the response to re-INVITE. */ F7 200 OK Alice -> Bob Hasebe [Page 22] Internet Draft Exceptional Procedure Examples Oct 21th,2005 SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.201 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 /* Bob sends a BYE, and Alice returns 200 OK to a re-INVITE. The state of a dialog is mismatching.*/ F8 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds8 ;received=192.0.2.201 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* The UAC core of Bob does not send a ACK after receiving 200 OK to a re-INVITE.(Bob has terminated the dialog by sending of a BYE.) The UAS core of Alice does not retransmit 200 OK to a re-INVITE. (Since the dialog is terminated by reception of BYE, Alice does not retransmit 200 OK even if she does not receive ACK from Bob.) */ 2.6. re-INVITE crossover Alice Bob | | | INVITE F1 | |--------------------------->| | 180 Ringing F2 | |<---------------------------| | | | 200 OK F3 | |<---------------------------| | ACK F4 | |--------------------------->| | Both Way RTP Media | |<==========================>| | | |re-INVITE F5 re-INVITE F6 | Hasebe [Page 23] Internet Draft Exceptional Procedure Examples Oct 21th,2005 |------------ -------------| | \ / | | X | | / \ | |<----------- ------------>| | 491 F8 491 F7 | |------------ -------------| | \ / | | X | | / \ | |<----------- ------------>| | ^ ACK F9 ^ ACK F10| |--|--------- ----|--------| | | \ / | | | | X | | | | / \ | | |<-|---------- ---|------->| | | | | | |0-2.0 sec | | | | | | | v re-INVITE F11 | | |<------------------|--------| | 200 OK F12 | | |-------------------|------->| | ACK F13 | | |<------------------|--------| | | | | |2.1-4.0 sec | | | | re-INVITE F14 v | |--------------------------->| | 200 OK F15 | |<---------------------------| | ACK F16 | |--------------------------->| | | | | In this scenario, Alice and Bob send a re-INVITE at the same time. When two re-INVITEs cross in the same dialog, they resend re-INVITEs after different intervals.(RFC3261,14.1) When Alice sends an initial INVITE, an INVITE will be sent again after 2.1-4.0 seconds because she generated the Call-ID (owner of the Call-ID). Bob will send an INVITE again after 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID. Therefore, each user agent must remember whether they has generated the Call-ID of the dialog or not, in case INVITEs may be crossed by another INVITE. Hasebe [Page 24] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Supported: timer Session-Expires: 300 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Require: timer Session-Expires: 300;refresher=uas From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Hasebe [Page 25] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between Alice and Bob */ F5 re-INVITE Alice -> Bob INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 151 v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly F6 re-INVITE Bob -> Alice Hasebe [Page 26] Internet Draft Exceptional Procedure Examples Oct 21th,2005 INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 Session-Expires: 300;refresher=uac Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 /* A case where a re-INVITE for a session refresh and a re-INVITE for hold are sent at the same time. */ F7 491 Request Pending Bob -> Alice SIP/2.0 491 Request Pending Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 0 /* Since an INVITE is in process, a 491 response are returned. */ F8 491 Request Pending Alice -> Bob SIP/2.0 491 Request Pending Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 F9 ACK(INVITE) Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0 F10 ACK(INVITE) Alice -> Bob Hasebe [Page 27] Internet Draft Exceptional Procedure Examples Oct 21th,2005 ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F11 re-INVITE Bob -> Alice INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 Session-Expires: 300;refresher=uac Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* Since Bob is not the owner of Call-ID, Bob sends an INVITE again after 0.0-2.0 seconds. */ F12 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashds7.1 Session-Expires: 300;refresher=uac Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com Hasebe [Page 28] Internet Draft Exceptional Procedure Examples Oct 21th,2005 s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F13 ACK Bob -> Alice ACK sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 Session-Expires: 300;refresher=uac Max-Forwards: 70 From: Bob ;tag=8321234356 To: Alice ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0 F14 re-INVITE Alice -> Bob INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 3 INVITE Content-Length: 151 v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly /* Since Alice is the owner of Call-ID, Alice sends an INVITE again after 2.1-4.0 seconds. */ F15 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9.1 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com Hasebe [Page 29] Internet Draft Exceptional Procedure Examples Oct 21th,2005 CSeq: 3 INVITE Content-Length: 151 v=0 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly F16 ACK Alice -> Bob ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f2.1 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 3 ACK Content-Length: 0 2.7. Initial INVITE retransmission Alice Bob | | | ini-INVITE F1 | |------------------------------->| | 180 F2(Packet loss) | | X<---------------------| | | | ini-INVITE F4 200 F3 | |------------- --------------| Terminate(ServerTransaction) | \ / | | X | | / \ | |<------------ ------------->| | ACK F5 | |------------------------------->| | | | | In this scenario, all provisional responses to the initial INVITE (ini-INVITE) are lost, and UAC retransmits an ini-INVITE. At the same time as retransmission, UAS generates a 200 OK to the ini-INVITE and it terminate an INVITE server transaction. Hasebe [Page 30] Internet Draft Exceptional Procedure Examples Oct 21th,2005 (RFC3261,13.3.1.4) After sending a 200 OK, a TU of UAS processes ACK and retransmission of 200 OK.(RFC3261,17.1) A TU of UAS processes a retransmited ini-INVITE, but it doesn't have a To-tag, therefore the TU cannot use a mechanism to recognize the dialog by From-tag, Call-ID and To-tag. However, it must recognize a retransmited ini-INVITE correctly by From-tag and Call-ID. (It must not construct a new dialog in response to a retransmited ini-INVITE regarding it as a request outside dialog.) Since TU of UAS retransmits a 200 OK according to the timer during it waits for ACK, it doesn't need to retransmit 200 OK for the retransmited ini-INVITE. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 /* A 180 response is lost and does not reach Alice. */ Hasebe [Page 31] Internet Draft Exceptional Procedure Examples Oct 21th,2005 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* Bob sends a 200 OK and terminates the INVITE transaction at the same time. TU performs retransmitting of a 200 OK directly.*/ F4 INVITE(retransmission) Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* Since F2 is lost, Alice retransmits an ini-INVITE. The retransmited INVITE does not match any existing transaction because Bob has Hasebe [Page 32] Internet Draft Exceptional Procedure Examples Oct 21th,2005 already sent a 200 OK. Moreover, the retransmited ini-INVITE does not have a To-tag, so it doesn't match any existing dialog. Therefore, Bob have to recognize the retransmited INVITE correctly, without treating with the new INVITE. */ F5 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 2.8. Early Dialog Alice Proxy Bob Carol | | | | | INVITE(sdp1) F1 | | | |--------------------->| INVITE(sdp1) F2 | | | 100 Trying F3 |--------------------->| | |<---------------------| 183(sdp2)To-tag=1 F4 | | | 183(sdp2)To-tag=1 F5 |<---------------------| | |<---------------------| | | | PRACK F6 | | | |--------------------->| PRACK F7 | | | |--------------------->| | | | 200(PRACK) F8 | | | 200(PRACK) F9 |<---------------------| | |<---------------------| | | |<=============Both Way RTP Media============>| | | | CANCEL F10 | | | |--------------------->| | | | 200(CANCEL) F11 | | | |<---------------------| | | | 487(INVITE) F12 | | | |<---------------------| | | | ACK(INVITE) F13 | | | |--------------------->| | | | | | | | | | | INVITE(sdp1) F14 | | |---------------------------->| | | 180 To-tag=2 F15 | | 180 To-tag=2 F16 |<----------------------------| |<---------------------| | Hasebe [Page 33] Internet Draft Exceptional Procedure Examples Oct 21th,2005 | | 200(sdp3)To-tag=2 F17 | | 200(sdp3)To-tag=2 F18|<----------------------------| |<---------------------| | | ACK F19 | | |--------------------->| ACK F20 | | |---------------------------->| |<================Both Way RTP Media================>| | | | | | | In this scenario, a proxy is forking to another address (Carol), when Bob don't return final response. When a proxy sends INVITEs to two or more addresses, two or more early dialogs may be established at UAC. At UAC, all early dialogs are released when the final response of ini-INVITE is received. (RFC3261,13.2.2.4) Only the confirmed dialog continues after a 200 OK reception. Even if Bob is replaced by Media Server, you have the result appear to UAC just as this call flow. In this sequence, Bob can terminate the early media when he receives CANCEL, but Alice dos not have the trigger to terminate the early dialog. When Bob stops sending RTP by the CANCEL from Proxy, it seems to Alice that RTP breaks off suddenly. Message Details F1 INVITE Alice -> Proxy INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Supported: 100rel Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Hasebe [Page 34] Internet Draft Exceptional Procedure Examples Oct 21th,2005 F2 INVITE Proxy -> Bob INVITE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 69 Record-Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Supported: 100rel Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F3 100 Trying Proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 F4 183 Session Progress Bob -> Proxy SIP/2.0 183 Session Progress Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 ;received=192.0.2.233 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Hasebe [Page 35] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Contact: Require: 100rel Content-Type: application/sdp Content-Length: 148 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.100 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F5 183 Session Progress Proxy -> Alice SIP/2.0 183 Session Progress Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE RSeq: 1 Contact: Require: 100rel Content-Type: application/sdp Content-Length: 148 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.100 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* Early dialog is established between Alice and Bob,and early media is also established at the same time. */ F6 PRACK Alice -> Proxy PRACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com Hasebe [Page 36] Internet Draft Exceptional Procedure Examples Oct 21th,2005 CSeq: 2 PRACK RAck: 1 1 INVITE Content-Length: 0 F7 PRACK Proxy -> Bob PRACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 PRACK RAck: 1 1 INVITE Content-Length: 0 F8 200 OK(PRACK) Bob -> Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 PRACK Contact: Content-Length: 0 F9 200 OK(PRACK) Proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 PRACK Content-Length: 0 F10 CANCEL Proxy -> Bob CANCEL sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Hasebe [Page 37] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Content-Length: 0 /* The proxy cancels the INVITE to Bob, and sends an INVITE to Carol. Although the continuation of early media after CANCEL reception depends on the implementation of the user agent, Alice does not know that the proxy cancels the INVITE, therefore, when Bob stops early media after CANCEL reception, it seems to her that the sound stops suddenly. */ F11 200 OK(CANCEL) Bob -> Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 F12 487 Request Terminated(INVITE) Bob -> Proxy SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 F13 ACK(INVITE) Proxy -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F14 INVITE Proxy -> Carol INVITE sip:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK83749a.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Hasebe [Page 38] Internet Draft Exceptional Procedure Examples Oct 21th,2005 ;received=192.0.2.101 Max-Forwards: 69 Record-Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Supported: 100rel Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F15 180 Ringing Carol -> Proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK83749a.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=456654 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content Length:0 F16 180 Ringing Proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=456654 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content Length:0 /* Proxy and Alice establish the second Early dialog when they Hasebe [Page 39] Internet Draft Exceptional Procedure Examples Oct 21th,2005 receive a 180 response from Carol. */ F17 200 OK Carol -> Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK83749a.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=456654 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content Length: 151 v=0 o=carol 2890844922 2890844922 IN IP4 client.chicago.example.com s=Session SDP c=IN IP4 client.chicago.example.com t=3034423619 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F18 200 OK Proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=456654 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content Length: 151 v=0 o=carol 2890844922 2890844922 IN IP4 client.chicago.example.com s=Session SDP c=IN IP4 client.chicago.example.com t=3034423619 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* By 200 OK response, all early dialogs are terminated except for ones that was confirmed. */ Hasebe [Page 40] Internet Draft Exceptional Procedure Examples Oct 21th,2005 F19 ACK Alice -> Proxy ACK sip:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=456654 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F20 ACK Proxy -> Carol ACK sip:carol@client.chicago.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9 ;received=192.0.2.101 Max-Forwards: 69 From: Alice ;tag=9fxced76sl To: Bob ;tag=456654 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 2.9. CANCEL crossover via a stateful proxy Alice Proxy Bob | | | | INVITE F1 | | |--------------------->| INVITE F2 | | 100 Trying F3 |--------------------->| |<---------------------| 180 Ringing F4 | | 180 F5 |<---------------------| |<---------------------| | | | | | CANCEL F6 | | |--------------------->| CANCEL F7 200 F8 | | 200(CANCEL) F9 |--------- --------| |<---------------------| \ / | | | X | | | / \ | | 200(INVITE) F10 |<-------- ------->| |<---------------------| 481(CANCEL) F11 | | ACK F12 |<---------------------| |--------------------->| ACK F13 | | |--------------------->| Hasebe [Page 41] Internet Draft Exceptional Procedure Examples Oct 21th,2005 | BYE F14 | | |--------------------->| BYE F15 | | |--------------------->| | | 200 F16 | | 200 F17 |<---------------------| |<---------------------| | | | | | | | If a CANCEL crosses a 200 OK to an INVITE between Bob and a stateful proxy, the UAC may receive a 200 OK to the INVITE after receiving 200 OK to the CANCEL. TU must manage a CANCEL transaction and an INVITE transaction independently, and even if a CANCEL is successful, TU cannot terminate an INVITE transaction, as described on 9.1 of RFC3261. Like a CANCEL crossover of 2.1, the UAC may send a BYE and terminate the session immediately after receiving 200 OK to an INVITE. Message Details F1 INVITE Alice -> Proxy INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 INVITE Proxy -> Bob INVITE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 69 Hasebe [Page 42] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Record-Route: From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F3 100 Trying Proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Content-Length: 0 F4 180 Ringing Bob -> Proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 ;received=192.0.2.233 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F5 180 Ringing Proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Hasebe [Page 43] Internet Draft Exceptional Procedure Examples Oct 21th,2005 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F6 CANCEL Alice -> Proxy CANCEL sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 F7 CANCEL Proxy -> Bob CANCEL sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 /* Proxy sent a 200 OK to the CANCEL and Bob sent INVITE at the same time. */ F8 200 OK(INVITE) Bob -> Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 ;received=192.0.2.233 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 148 Hasebe [Page 44] Internet Draft Exceptional Procedure Examples Oct 21th,2005 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.100 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F9 200 OK(CANCEL) Proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 /* Since CANCEL requests are hop-by-hop, the proxy answers with a 200 OK to the CANCEL of Alice. Note that the 200 OK doesn't mean the success of the CANCEL to the INVITE. */ F10 200 OK(INVITE) Proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 148 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.100 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F11 481 Call/Transaction Does Not Exist Bob -> Proxy Hasebe [Page 45] Internet Draft Exceptional Procedure Examples Oct 21th,2005 SIP/2.0 481 Call/Transaction Does Not Exist Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.2 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 CANCEL Content-Length: 0 /* Since Bob has already sent 200 OK to INVITE, CANCEL fails with 481 response. */ F12 ACK Alice -> Proxy ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F13 ACK Proxy -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK721e.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bq9 ;received=192.0.2.101 Max-Forwards: 69 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 F14 BYE Alice -> Proxy BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5 Max-Forwards: 70 Route: From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 BYE Content-Length: 0 Hasebe [Page 46] Internet Draft Exceptional Procedure Examples Oct 21th,2005 /* Alice may send a BYE and terminate the sessin immediately on receipt of a 200 OK after the CANCEL. */ F15 BYE Proxy -> Bob BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK739578.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5 ;received=192.0.2.101 Max-Forwards: 69 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 BYE Content-Length: 0 F16 200 OK Bob -> Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP ss.atlanta.example.com:5060;branch=z9hG4bK739578.1 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 BYE Content-Length: 0 F17 200 OK Proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74be5 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 BYE Content-Length: 0 2.10. A retransmited 200 OK after sending A BYE Alice Bob | | | INVITE F1 | |----------------------->| Hasebe [Page 47] Internet Draft Exceptional Procedure Examples Oct 21th,2005 | 180 Ringing F2 | |<-----------------------| | | | 200 OK F3 | |<-----------------------| | ACK F4(packet loss) | |-------------->X | | Both Way RTP Media | |<======================>| | BYE F6 200 F5 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | ACK F7 200 F8 | |--------- ----------| | \ / | | X | | / \ | |<-------- --------->| | | | | In this scenario, a ACK request to a 200 OK response is lost(or delay), immediately after Bob sends the retransmited 200 OK to ini-INVITE and Alice sends a BYE at the same time. (Usually UAS don't terminate the session with a BYE, but it's possible in the case of a CANCEL clossover since Alice sends a BYE immediately after sending a ACK.) Depending on the implement of a SIP user agent, Alice may start a session again by reception of the retransmited 200 OK with SDP since she has already terminated a session by sending a BYE. In that case, if UAC receives a retransmited 200 OK after sending a BYE, you should not start a session again since the session which is not associated with dialog remains. Moreover, in the case where UAS sends an offer with a 200 OK, if UAS receives a retransmited ACK after receiving a BYE, UAS should not start a session again for the same reason. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Hasebe [Page 48] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 F3 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Hasebe [Page 49] Internet Draft Exceptional Procedure Examples Oct 21th,2005 F4 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* A ACK request is lost. */ F5 200 OK Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* UAS retransmits a 200 OK to an ini-INVITE since it didn't receive a ACK. */ F6 BYE Alice -> Bob BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 Hasebe [Page 50] Internet Draft Exceptional Procedure Examples Oct 21th,2005 /* Bob retransmits a 200 OK and Alice sends a BYE at the same time. */ F7 ACK Alice -> Bob ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0 /* UAC retransmits a ACK since it received a retransmited 200 OK. Alice has already terminated a session by sending a BYE. She should not start a session again by receiving a retransmited 200 OK. */ F8 200 OK(BYE) Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Bob sends a 200 OK to a BYE. */ Editor's Note It would be needed clarify related with Dialogue status and the waiting timer of re-send message. 2.11. A BYE on the early dialog Alice Bob | | | INVITE F1 | |----------------------->| | 180 Ringing F2 | |<-----------------------| | | | BYE F3 | |----------------------->| | 200 OK(BYE) F4 | Hasebe [Page 51] Internet Draft Exceptional Procedure Examples Oct 21th,2005 |<-----------------------| | 487 F5 | |<-----------------------| | ACK F6 | |----------------------->| | | | | In this scenario, Alice establishes an early dialog with the receiving 180 response. Alice sends a BYE on the early dialog. According to Section 15 of RFC3261, callee's UA MUST NOT send a BYE on early dialogs, but the caller's UA MAY send a BYE on early dialogs. Message Details F1 INVITE Alice -> Bob INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 180 Ringing Bob -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 Hasebe [Page 52] Internet Draft Exceptional Procedure Examples Oct 21th,2005 /* Alice forms an early dialog by receiving a 180 response to ini-INVITE. However Bob is not sure that Alice received the 180 response. */ F3 BYE Alice -> Bob BYE sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Alice sends a BYE on the early dialog and Alice terminates a session (if any). */ F4 200 OK(BYE) Bob -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashds9 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 BYE Content-Length: 0 /* Bob sends a 200 OK to a BYE of Alice, and Bob terminates a session (if any). */ F5 487 Request Terminated(INVITE) Bob -> Alice SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bd5 ;received=192.0.2.101 From: Alice ;tag=9fxced76sl To: Bob ;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: Content-Length: 0 /* Bob should terminate the early dialog when he receives a BYE. Bob sends a 487 response to terminate a INVITE transaction in the similar way to handle a CANCEL from Alice, because the INVITE transaction remains after terminating the early dialog. */ Hasebe [Page 53] Internet Draft Exceptional Procedure Examples Oct 21th,2005 F6 ACK Alice -> Bob ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Contact: Content-Length: 0 /* Alice sends an ACK to a 487 response as processing of the ini-INVITE transaction. (The dialog has been already terminated, but the ini-INVITE transaction remains) */ 3. References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, April 2002. [3] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. [4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2003. [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)", RFC 3262, June 2002. 4. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in Hasebe [Page 54] Internet Draft Exceptional Procedure Examples Oct 21th,2005 this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 5. Authors' Addresses All listed authors actively contributed large amounts of text to this document. Miki Hasebe NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan EMail: hasebe.miki@east.ntt.co.jp Jun Koshiko NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan EMail: j.koshiko@east.ntt.co.jp Yasushi Suzuki NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan EMail: suzuki.yasushi@east.ntt.co.jp Tomoyuki Yoshikawa NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan EMail: tomoyuki.yoshikawa@east.ntt.co.jp Hasebe [Page 55] Internet Draft Exceptional Procedure Examples Oct 21th,2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hasebe [Page 56] Internet Draft Exceptional Procedure Examples Oct 21th,2005 The Expiration date for this Internet Draft is: August 14th, 2005 Hasebe [Page 57] Internet Draft Exceptional Procedure Examples Oct 21th,2005