Subject: [Sipping] Review of draft-ietf-sipping-race-examples-01.txt (version 2)

From: [email-masked]
Date: Mon, 14 May 2007 12:22:08 -0400

[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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 18:29:58 -0400

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