Re: [Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)
Miki HASEBE <hasebe.miki@east.ntt.co.jp> Wed, 23 May 2007 07:01 UTC
Return-path: <sipping-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqkqM-0003wn-P4; Wed, 23 May 2007 03:01:10 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1HqkqL-0003we-D3 for sipping-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 03:01:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqkqL-0003wW-30 for sipping@ietf.org; Wed, 23 May 2007 03:01:09 -0400
Received: from eastmail2.ntt-east.co.jp ([202.229.5.45] helo=evx2.enoc.east.ntt.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqkqJ-0004Ec-EY for sipping@ietf.org; Wed, 23 May 2007 03:01:09 -0400
Received: from emix2.enoc.east.ntt.co.jp by evx2.enoc.east.ntt.co.jp with ESMTP id l4N713h21335; Wed, 23 May 2007 16:01:03 +0900 (JST)
Received: from cip3.noc.east.ntt.co.jp by emix2.enoc.east.ntt.co.jp with ESMTP id l4N712K22027; Wed, 23 May 2007 16:01:02 +0900 (JST)
Received: from mail.east.ntt.co.jp ([10.8.52.77]) by cip3.noc.east.ntt.co.jp (MOS 3.4.6-GR) with SMTP id CUH35142; Wed, 23 May 2007 16:01:02 +0900 (JST)
Message-Id: <200705230701.CUH35142@cip3.noc.east.ntt.co.jp>
Date: Wed, 23 May 2007 16:03:29 +0900
From: Miki HASEBE <hasebe.miki@east.ntt.co.jp>
X-Mailer: EdMax Ver2.85.5F
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e19fe12a2b60f5c397f73b74149e8776
Cc: pkyzivat@cisco.com, sipping@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Errors-To: sipping-bounces@ietf.org
Hi Dale, Thank you for your many comments. I apologize for late reply. The answers are inline. Thanks, Miki <Dale.Worley@comcast.net> wrote: > > [This version of my review includes some additional explanation of > some of the technical suggestions.] > > 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. I will correct this point. As you proposed in the figure below, I will add an arrow which indicates the start of the DSM. > Add transition to show that transition from Confirmed to Mortal can be > by receiving BYE as well as sending BYE. I will correct this point. Currently, the figure shows the behavior in UAC and shows only the sending of BYE by UAC, but I will change the figure to show the behavior in Caller and indicate the reception of BYE. Accordingly, the title will be changed from (UAC) to (Caller). > 2xx with new tag can be received in Established and Mortal states, > which requires 2 new edges in the DSM. Regarding your point about the arrow for the reception of 2xx with new tag, the current expression lacks clarity. I will correct this point. The original figure looked as if the dialog state in Caller changes upon the reception of 2xx with new tag. But this is not the case. I don't mean that the state of the existing dialog in Caller changes. What is meant is that a new DSM is created upon the reception of 2xx with new tag in the period between receiving of the first 2xx response to INVITE and 64*T1 end. (Detail for this behavior is shown in Appendix E) I mended the figure so that it does not mislead. In a similar way, I made correction for the Eartly state so that it shows that a new DSM is created in Caller, instead of showing state transition at the Early state as in the original figure. Does the corrected figure, shown below, seem acceptable to you? +-----------------------------------------------+ | Preparative | | +----------+ +--------------+ | | | | 100 | | | ----C--->| Trying |---------->| Proceeding | | | | | | | | | +----------+ +--------------+ | | | +-----------------------------------------------+ | | | | 3xx-6xx | 1xx-tag | 2xx | | | | | 1xx-tag | | V w/new tag | | +-----------------+ [new DSM] | | 3xx-6xx | | | (new DSM | +<--------| Early | | instance | | | |<--+ created) | | +-----------------+ | | | | | 2xx w/new tag | | BYE | 2xx | [new DSM] | | +------------>+<-+ | (new DSM | | | | instance +-----C------------C-----+ +-----------C------+ | created) | | Terminated | | | Confirmed | | | | | +<----C---------| | | | | | | | BYE(sr) | | | | | | V | | V | | | 2xx | +-----------+ | | +-----------+ | | | +---C--| |---C-+ | | | | | | | | | Mortal | | | BYE(r)| | Moratorium|<-C--+ | +---C->| |<--C-+ | | | | | ACK | +-----------+ | | +-----------+ | | | | | | | | | | | Timeout | | | ACK | | | | | | | | | V V | | V | | +---------------+ | | +-----------+ | | | | | | | |--C-+ | | Morgue | | | |Established| | | 2xx,ACK | | | | | | |<-C-+ | +---------------+ | | +-----------+ | | | | | +------------------------+ +------------------+ > 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). The original figure does not show the reception of 200 in the Established state because it is not involved with dialog state transition. It is a mere retransmission on the INVITE transaction. So the dialog state does not move back to the Moratorium state upon the reception, and the state change does not occur. So I will add the arc from Established to Established. In the same way, I will also add the arc from Mortal to Mortal which is described as follows. They have already been reflected in the figure above. > 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. This behavior, too, is just a retransmission behavior by the INVITE transaction and does not cause dialog state transition, so the original figure does not show this. The details for the behavior upon the reception of 200 to INVITE in the Mortal state are shown in Appendix D. > 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". I will correct these points. > -- 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.) I will address it as mentioned above. > Expanded label of arc from Moratorium to Moratorium. I correct this as you proposed. > +-----------------------------------------------+ > | 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. As you pointed out, RFC 3261 is very clear about 100 Trying, so I will correct the text. > -- 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. Mortal is the state until BYE transaction is terminated. Mortal state does not relate to INVITE transaction (3xx-6xx) because it terminates instantly the dialog. I would like to modify the text to say that termination of the transaction causes transit to Morgue. Mortal (Mort): Caller and callee enter the Mortal state by sending or receiving a BYE. UA MUST NOT send any new requests within the dialog because 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 addresses the case where BYE is sent by both a caller and a callee to exchange reports about the session when it is being terminated. Therefore the UA possesses dialog information for internal processing but the dialog shouldn't be externally visible. The UA stops managing its dialog state and changes it to the Morgue state, when the BYE transaction is terminated. Morgue (Morg): The dialog no longer exists in this state. Sending or receiving of signaling which influences a dialog is not performed. (A dialog is literally terminated.) Caller and callee enter Morgue state via the termination of the BYE or INVITE transaction. As for your comments about presentation and nits, I will reflect as you proposed. Thank you very much for your many valuable comments. I will address them in the revised version of the draft. Miki > ----- 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 > > oChange "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". > > ----- > > Dale > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors at cs.columbia.edu for questions on current sip > Use sip at ietf.org for new developments of core SIP > > > > Prev by Date: Re: [Sipping] I-D on service identification now available > Next by Date: Re: [Sipping] I-D on service identification now available > Previous by thread: [Sipping] Comments on draft-marjou-sipping-b2bua-00.txt > Next by thread: [Sipping] Accounting and Billing Service Indicator Example > Index(es): > Date > Thread --------------------------------------------------------- Miki HASEBE Research and Development Center NTT-east Corporation Telephone +81 3 5359 5104 Facsimile +81 3 5359 1236 E-mail: hasebe.miki@east.ntt.co.jp 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan --------------------------------------------------------- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP
- [Sipping] Review of draft-ietf-sipping-race-examp… Dale.Worley
- Re: [Sipping] Review of draft-ietf-sipping-race-e… Paul Kyzivat
- Re: [Sipping] Review of draft-ietf-sipping-race-e… Miki HASEBE