Re: [Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)
Paul Kyzivat <pkyzivat@cisco.com> Fri, 18 May 2007 22:30 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 1HpAxY-0000OZ-I7; Fri, 18 May 2007 18:30:04 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1HpAxX-0000OS-E2 for sipping-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 18:30:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpAxX-0000OK-3n for sipping@ietf.org; Fri, 18 May 2007 18:30:03 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpAxW-00045n-85 for sipping@ietf.org; Fri, 18 May 2007 18:30:03 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 May 2007 18:30:02 -0400
X-IronPort-AV: i="4.14,553,1170651600"; d="scan'208"; a="121520967:sNHT130499500"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4IMU1qV007821; Fri, 18 May 2007 18:30:01 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4IMU0Bi027810; Fri, 18 May 2007 22:30:01 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 18:30:01 -0400
Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 18:30:00 -0400
Message-ID: <464E28E6.4020504@cisco.com>
Date: Fri, 18 May 2007 18:29:58 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Dale.Worley@comcast.net
Subject: Re: [Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)
References: <200705141622.l4EGM8EX027770@dragon.ariadne.com>
In-Reply-To: <200705141622.l4EGM8EX027770@dragon.ariadne.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 May 2007 22:30:00.0634 (UTC) FILETIME=[126BA1A0:01C7999C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=30859; t=1179527401; x=1180391401; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sipping]=20Review=20of=20draft-ietf-sipping-race-exa mples-01.txt=09(version=0A=202) |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=UAqFB4tgvhovIAgz+QtaNry7qRll996IKFyu/PgmMD0=; b=wLXrBCCtmXrKD6QdTPLDXf80qeTaxb1bSn94L6j5klqoWLEfhP0UGISI8/XqFb1gumuR/mvA VXBxz0/nNKIEqPi5zZnZPoDRDaXFA7lKCZF3C4+lBf4lbJ7HLFEXHIfU;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: efecd979fb9d15792ac142aa0178058d
Cc: 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
Dale, Thank you for the very detailed review and constructive comments. You obviously put a lot of work into this. I've been putting off responding to your comments until I had time to look into them carefully. Meanwhile Miki had been working on responses and we just compared notes. I am going to defer to his response that will include my thoughts as well. Thanks, Paul 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. > > 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". > > ----- > > 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@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ 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