Draft: draft-ietf-sipping-race-examples-01.txt Reviewer: Dale.Worley@comcast.net Review Date: 14 May 2007 Review Deadline: 14 May 2007 Status: WGLC Summary: This draft is on the right track but has open issues, described in the review. This review is divided into three sections: technical issues, presentation issues, and nits. ----- Technical -- Section 2, Figure 1 The figure needs some additional arrows to handle 2xx responses with new tags that arrive after the dialog is established, and even when it is terminated. Similarly, it needs some additional arrows to handle retransmitted 2xx responses that are soliciting retransmission of ACK. Add incoming arrow to show where the DSM starts. Add transition to show that transition from Confirmed to Mortal can be by receiving BYE as well as sending BYE. 2xx with new tag can be received in Established and Mortal states, which requires 2 new edges in the DSM. 2xx with same tag can be received in Established state (which transits to Moratorium, which presumably immediately re-sends ACK and transits back to Established). 2xx with same tag can be received in Mortal state (if the UAC has sent ACK and then BYE, but ACK was lost). The ACK must be re-sent. Remove specification of the timer from Mortal to Morgue. (See description on page 9.) +-----------------------------------------------+ | Preparative | | +----------+ +--------------+ | | | | 100 | |-----C-+ ----C-->| Trying |---------->| Proceeding | | | 100 | | | | |<----C-+ | +----------+ +--------------+ | | | +-----------------------------------------------+ | | | | 3xx-6xx | 1xx-tag | 2xx | | | | V | | +------------------+ | | 3xx-6xx | |--+ 1xx-tag | +<--------| Early | | w/new tag | | | |<-+ (new DSM | | +------------------+ instance | | | | created) | | | BYE | 2xx | | | +------------>+<-+ | | | +-----C------------C-----+ +-----------C------+ | | Terminated | | | Confirmed | | | | +<----C---------| | | | | | | BYE(sr) | | | | | V | | V | | 2xx | +------------+ | | +-----------+ | | +---C-| |---C-+ | | |--C-+ 2xx | | | | Mortal | | | BYE(r)| | Moratorium| | | w/new tag | +---C>| |<--C-+ | | |<-C-+ (new DSM | ACK | +------------+---C---------C-->+-----------+ | | instance | | | | 2xx | ^ | | | created) | | | Timeout | w/new | 2xx | | ACK | | | | | | tag | | | | | | V V | (new DSM| | V | | | +---------------+ | instance| +-----------+ | | | | | | created)| | |--C-+ | | Morgue | | | |Established| | | | | | | | | | | +---------------+ | | +-----------+ | | | | | +------------------------+ +------------------+ (r): indicates only reception is allowed. (sr): indicates that both sending and reception are allowed. Where (r) or (sr) is not indicated, response means receive, request means send. Figure 1. DSM for INVITE dialog usage (UAC) -- Section 2, page 6 establish a dialog by receiving a new response to the INVITE even though it had sent a BYE and terminated the dialog (see Appendix A). Change "sent a BYE" to "sent a BYE or CANCEL". -- Section 2, Figure 2 Add incoming arrow to show where the DSM starts. Remove specification of the timer from Mortal to Morgue. (See description on page 9.) Expanded label of arc from Moratorium to Moratorium. +-----------------------------------------------+ | Preparative | | +----------+ +--------------+ | INV | | | 100 | |-----C-+ ----C-->| Trying |---------->| Proceeding | | | 100 | | | | |<----C-+ | +----------+ +--------------+ | | | +-----------------------------------------------+ | | | | 3xx-6xx | 1xx-tag | 2xx | | | | V | | +------------------+ | | 3xx-6xx | |--+ | +<--------| Early | | 1xx-tag | | | |<-+ | | +------------------+ | | | | | | | BYE | 2xx | | | +------------>+<-+ | | | +-----C------------C-----+ +-----------C------+ | | Terminated | | | Confirmed | | | | +<----C---------| | | | | | | BYE(sr) | | | | | V | | V | | | +------------+ | | +-----------+ | | | | |---C-+ | | |--C-+ | | | Mortal | | | BYE | | Moratorium| | | 2xx | | | |<--C-+ | | |<-C-+ if ACK not | | +------------+ | | +-----------+ | received | | | | | | | | | | Timeout | | | ACK | | | | | | | | | V V | | V | | +---------------+ | | +-----------+ | | | | | | | | | | | Morgue | | | |Established| | | | | | | | | | | +---------------+ | | +-----------+ | | | | | +------------------------+ +------------------+ (sr): indicates that both sending and reception are allowed. Where (sr) is not indicated, response means send, request means receive. Figure 2. DSM for INVITE dialog usage (UAS) -- Section 2, page 8 This phrase is used twice on this page: 1xx (usually 100 trying) without To-tag. UAC may retransmit an However RFC 3261 section 8.2.6.2 makes it clear that only 100 may have no to-tag. But perhaps this statement is used to provide defined handling of an error situation. -- Section 2, page 9 Correct the explanation of the timer to transit from Mortal to Morgue state: Mortal (Mort): Caller and callee becomes Mortal state by sending or receiving a BYE. UA MUST NOT send any new requests since there is no dialog. (Here the new requests do not include ACK for 2xx and BYE for 401 or 407 as further explained in the Appendix D below.) In this state, only BYE or its response can be handled, and no other messages can be received. This is because the use case is taken into consideration that BYE is sent by both a caller and a callee to exchange reports about the session when it is being terminated. Therefore, UA possesses dialog information for internal process but dialog shouldn't exist outwardly. The UA stops managing its dialog state and changes it to the Morgue state, when the BYE transaction is finished by timer (Timer F or Timer K for UAC. Timer J for UAS). Change the last sentence to: The UA stops managing its dialog state and changes it to the Morgue state, when the final transaction is finished by timer. The timer is determined by whether the UA is acting as UAS or UAC for the transaction that caused it to enter Mortal state, and type type of transaction. The timer to use is: Function Transaction Timer RFC 3261 [1] section UAC sends INVITE, D 17.1.1, figure 5 receives 3xx-6xx UAC sends BYE K 17.1.2, figure 6 UAS receives INVITE, I 17.2.1, figure 7 sends 3xx-6xx UAS receives BYE J 17.2.2, figure 8 I may be wrong about the correct timer in each situation, as I have just copied the final timer from each figure. But the description does need this sort of reorganization, because the choice of timer depends on whether the UA is acting as UAC or UAS in the transaction that ends the dialog (which may not be the same as UAC or UAS in regard to starting the dialog). And given the large number of possibilities, cross-referencing the appropriate sections of RFC 3261 seems advisable. ----- Presentation -- "RFC3261" vs. "RFC 3261" The form "RFCnnnn" is used 16 times in the text, and the form "RFC nnnn" is used 11 times. Since the second form is used in the References, I suggest changing all uses to the second. -- Section 3.1.2 page 12 Lower the labels "Pre" and "Ear" by one line. State Alice Bob State | | | INVITE F1 | |----------------------------->| Pre | 180 Ringing F2 | Pre |<-----------------------------| Ear | | Ear |CANCEL F3 200(INVITE) F4| |------------ -------------| | \ / | Mora | X | | / \ | |<----------- ------------>| *race* Mora | | | ACK F6 200(CANCEL) F5| |------------ -------------| Est | \ / | | X | | / \ | |<----------- ------------>| | | Est | One Way RTP Media | | (Two Way RTP Media possible) | |<=============================| | BYE F7 | |----------------------------->| Mort | 200 F8 | Mort |<-----------------------------| | ^ ^ | | | Timer K | | | V | | Morg | Timer J | | | V | | | Morg | | -- Section 3.1.2, page 13 F6 ACK Alice -> Bob /* INVITE is successful, and the CANCEL becomes invalid. Bob establishes RTP streams. However, the next BYE request immediately terminates the dialog and session. */ Should be indented as: F6 ACK Alice -> Bob /* INVITE is successful, and the CANCEL becomes invalid. Bob establishes RTP streams. However, the next BYE request immediately terminates the dialog and session. */ -- Message labels These would be more clear if they were written like "200 F5(=F3)". In addition, some responses and ACKs should be labeled with the request that they correspond to. The figures that are affected are: section 3.1.4, page 15 becomes: State Alice Bob State | | | ini-INVITE w/offer1 F1 | |------------------------------->| Pre | 180 F2 | Pre |<-------------------------------| Ear | | Ear | 200(ini-INV) w/answer1 F3 | |<-------------------------------| Mora | ACK F4(packet loss) | Mora |-------------------->x | Est | | | re-INVITE F6 200 F5(=F3) | | w/offer2 w/answer1 | |------------- --------------| | \ / | | X | | / \ | |<------------ ------------->| *race* | 200(re-INV) F8| | ACK F7(=F4) w/answer2 | |------------- --------------| | \ / | | X | | / \ | |<------------ ------------->| next page: | ACK (re-INV) F9 | Est |------------------------------->| | | | | page 19: F9 ACK Alice -> Bob becomes: F9 ACK (re-INVITE) Alice -> Bob section 3.1.5, page 19 becomes: State Alice Bob State | | | ini-INVITE (no offer) F1 | |------------------------------->| Pre | 180 F2 | Pre |<-------------------------------| Ear | | Ear | 200(ini-INV) w/offer1 F3 | |<-------------------------------| Mora | ACK w/answer1 F4(packet loss) | Mora |-------------------->x | Est | | | re-INVITE F6 200 F5(=F3) | | w/offer2 w/offer1 | |------------- --------------| | \ / | | X | | / \ | |<------------ ------------->| | ACK F7(=F4) 491(re-INV) F8| |------------- --------------| | \ / | | X | | / \ | |<------------ ------------->| | ACK (re-INV) F9 | Est |------------------------------->| | | | | page 22: F9 ACK Alice -> Bob becomes: F9 ACK (re-INVITE) Alice -> Bob section 3.1.6, page 22 becomes: State Alice Bob State | | | INVITE F1 | |-------------------------->| Pre | 180 Ringing F2 | Pre |<--------------------------| Ear | | Ear | 200 OK F3 | |<--------------------------| Mora | ACK F4(packet loss) | Mora |--------------->x | Est | Both Way RTP Media | |<=========================>| | BYE F6 200 F3(=F5)| |----------- -----------| Mort | \ / | | X | | / \ | |<---------- ---------->| *race* |ACK F7(=F4) 200(BYE) F8| Mort |----------- -----------| | \ / | | X | | / \ | |<---------- ---------->| | ^ ^ | | | Timer K | | | V | | Morg | Timer J | | | V | | | Morg | | section 3.2.2, page 28: | / \ | *race* |<-------- --------->| | | Mort | 481 F8 200 F7 | | (re-INV) (BYE) | |--------- ----------| | \ / |^ | X || | / \ ||Timer J |<-------- --------->|| ^| ACK (re-INV) F9 || ||<-----------------------|| Timer K|| || || || V| || Morg | |V | | Morg | | page 29: F7 200 OK Bob -> Alice becomes: F7 200 OK (BYE) Bob -> Alice F8 481 Call/Transaction Does Not Exist Alice -> Bob becomes: F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob page 30: F9 ACK Bob -> Alice becomes: F9 ACK (re-INVITE) Bob -> Alice section 3.2.3, page 30 becomes: State Alice Bob | | | INVITE F1 | |----------------------->| Pre | 180 Ringing F2 | Pre |<-----------------------| Ear | | Ear | 200 OK F3 | |<-----------------------| Mora | ACK F4 | Mora |----------------------->| Est | Both Way RTP Media | Est |<======================>| | | | re-INVITE F5 | |<-----------------------| | 200 F7 BYE F6 | |--------- ----------| | \ / | Mort | X | | / \ | |<-------- --------->| *race* Mort | 200 F8 ACK F9 | | (BYE) (re-INV) | |--------- ----------| | ^ \ / | | | X | | | / \ | |<-------- --------->| | | ^ | | | Timer K | | | | V | | | Timer J | Morg | V | Morg | | | | page 32: F9 ACK Bob -> Alice becomes: F9 ACK (re-INVITE) Bob -> Alice section 3.3.2, page 39 becomes: | / \ | |<----------- ------------>| | 491 F8 491 F7 | | (re-INVITE) (UPDATE) | |------------ -------------| | \ / | | X | | / \ | |<----------- ------------>| | ^ ACK F9 ^ | |<-|----------------|--------| | | | | | |0-2.0 sec | | | | | | | v re-INVITE F10 | | |<------------------|--------| | 200 OK F11 | | |-------------------|------->| | ACK F12 | | |<------------------|--------| | | | | |2.1-4.0 sec | | | | UPDATE F13 v | |--------------------------->| | 200 OK F14 | |<---------------------------| | | | | page 40: F7 491 Request Pending Bob -> Alice becomes: F7 491 Request Pending (UPDATE) Bob -> Alice F8 491 Request Pending Alice -> Bob becomes: F8 491 Request Pending (re-INVITE) Alice -> Bob section 3.3.3, page 42 becomes: State Alice Bob State | | | INVITE F1 | |----------------------->| Pre | 180 Ringing F2 | Pre |<-----------------------| Ear | | Ear | 200 OK F3 | |<-----------------------| Mora | ACK F4 | Mora |----------------------->| Est | Both Way RTP Media | Est |<======================>| | | | BYE F5 REFER F6 | |--------- ----------| Mort | \ / | | X | | / \ | *race* |<-------- --------->| | | Mort | 481 F8 200 F7 | | (REFER) (BYE) | |--------- ----------| | \ / ^ | | X | | | / \ | | |<-------- --------->| | ^ | | | | Timer K | | | V | | Morg | Timer J | | | V | | | Morg | | page 43: F7 200 OK Bob -> Alice becomes: F7 200 OK (BYE) Bob -> Alice F8 481 Call/Transaction Does Not Exist Alice -> Bob becomes: F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob Appendix A, page 44 becomes: Alice Proxy Bob Carol | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 F3 |----------------->| | |<---------------| 180(To-tag=1) F4 | | | 180(1) F5 |<-----------------| | |<---------------| | | | | INVITE(Fork) F6 | | |------------------------>| | | 100 F7 | | BYE(1) F8 |<------------------------| |--------------->| BYE(1) F9 | | | |----------------->| | | | 200(1,BYE) F10 | | | 200(1,BYE) F11 |<-----------------| | |<---------------| 487(1,INV) F12 | | | |<-----------------| | | | ACK(1) F13 | | | |----------------->| | | | | | | | | | | 200(To-tag=2) F13 | | 200(2) F14 |<------------------------| |<---------------| | | ACK(2) F15 | | |--------------->| ACK(2) F16 | | |------------------------>| | BYE(2) F17 | | |--------------->| BYE(2) F18 | | |------------------------>| | | 200(2) F19 | | 200(2) F20 |<------------------------| |<---------------| | | | | | | | -- Section 3.3, page 34 Change the last line of this paragraph to read: "What is established by SIP", that is, by requests that modify the dialog's media session. I think that this will connect the expression "What is established by SIP" to the more customary terminology, thus making the rest of this section clearer. ----- Nits [I have attempted to keep all changes of English usage within the authors' style.] -- Section 1.2, page 3 Dashed lines (---) and slash lines (/,\) represent signaling messages that are mandatory to the call scenario. (X) represents crossover of signaling messages. (->x,x<-) indicate that the packet is lost. Insert a space in "(/, \)" and "(->x, x<-)" to match usual English usage. I admit this is only a slight improvement, but it makes it a little more clear that the "," is a separator and not part of the symbols. -- Section 1.3, page 4 other headers which would usually be included such as Accept, Allow, etc are not shown. Add period to "etc. are not shown." -- Section 2, page 8 exists though the dialog does not existed in this state yet. Change "does not existed" to "does not exist". -- Section 2, page 9 Confirmed (Con): Sending or receiving of a 2xx final response establishes a dialog. Dialog exists in this state. The BYE request the changes state from the Confirmed to Mortal state, Change "request the changes" to "request changes the". a substate of the Terminated state. The Confirmed has two Change "The Confirmed" to "The Confirmed state". substates, the Moratorium and Established state, which are different in messages UAs are allowed to send. -- Section 2, page 9 Established (Est): The Established state is a substate of the Confirmed state and inherits the behavior of superstate. Both caller and callee may send various messages which influences a Change "which influences" to "which influence". dialog. Caller supports the transmission of ACK for a Change "ACK for" to "ACK in response to" retransmission of a 2xx response to an ini-INVITE. -- Section 3.1.1, page 11 retransmission, UAS generates a 200 OK (F3) to the ini-INVITE and it terminate an INVITE server transaction, according to Section 13.3.1.4 of RFC3261 [1]. Change "it terminate an" to "it terminates an". -- Section 3.1.2, page 13 Regardless of the success/failure of the CANCEL, Alice checks the final response to INVITE, and if she receives 200 to the INVITE request she immediately sends a BYE and terminates a dialog. (Section 15, RFC3261 [1]) Change "terminates a" to "terminates the". Bob, media may be flowing one way from Bob to Alice. From the time than an answer is received by Alice from Bob there is the possibility Change "than an answer" to "that an answer". -- Section 3.1.4, page 16 answer is in the ACK, UA should return by a 491 to the Change "return by a" to "return a". -- Appendix D, page 49 both a part of the INVITE transaction, even though their hadling Change "hadling" to "handling". -- Appendix E, page 50 ini-INVITE (See Section 11.2, 13.1, 13.2.2.4, 16.7, 19.3 etc. of Change "19.3 etc." to "19.3, etc.". response. Moreover, all mortal early dialog which do not transit to the Established state are terminated (See Section 13.2.2.4 of RFC3261). Add the sentence 'By "mortal early dialog" we mean any early dialog that the UA will terminate when another early dialog is confirmed.' -- Appendix E, page 51 However, the seesion on the mortal early dialog is terminated when Change "seesion" to "session". might want to handle things differently. For instance, a conference focus that has sent out an invite that forks may want to accept and mix all the dialogs it gets. Add the sentence 'In that case, no early dialog is treated as mortal.' -- References [8], page 53 [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", draft-ietf-sipping-dialogusage-06 (work in progress), Febrary 20, 2007. Change "Febrary" to "February".