[Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)
Dale.Worley@comcast.net Mon, 14 May 2007 16:22 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 1HndJN-0005ur-CH; Mon, 14 May 2007 12:22:13 -0400
Received: from sipping by megatron.ietf.org with local (Exim 4.43) id 1HndJM-0005um-Jl for sipping-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 12:22:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndJM-0005ue-9j for sipping@ietf.org; Mon, 14 May 2007 12:22:12 -0400
Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HndJK-0003hT-Uw for sipping@ietf.org; Mon, 14 May 2007 12:22:12 -0400
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070514162209b1100kadpfe>; Mon, 14 May 2007 16:22:09 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l4EGM8ZZ027774 for <sipping@ietf.org>; Mon, 14 May 2007 12:22:08 -0400
Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l4EGM8EX027770; Mon, 14 May 2007 12:22:08 -0400
Date: Mon, 14 May 2007 12:22:08 -0400
Message-Id: <200705141622.l4EGM8EX027770@dragon.ariadne.com>
To: sipping@ietf.org
From: Dale.Worley@comcast.net
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 093e26f1a1ce195f411d3b0c3b9d5e74
Subject: [Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)
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
[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] 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