Subject: [Sipping] Comments on draft-ietf-sipping-race-examples-00

From: [email-masked]
Date: Wed, 27 Dec 2006 23:03:02 -0500

I've read over draft-ietf-sipping-race-examples-00.  Please consider
the following questions for clarification.

Thanks,

Dale
----------------------------------------------------------------------
** Content

In section 2:

* Figure 1:  The figure does not show the generation of DSMs by new
tags as clearly as it might.  The difficulty is that the new DSMs are
not really generated by the existing DSM (the DSM for the first dialog
generated by the early dialog).  In reality, DSMs are generated from
the INVITE transaction -- as long as the INVITE transaction is alive,
if it receives a response with a new tag, a DSM is generated for the
dialog created by that response.

There is one exception -- the first DSM, in the Trying state, is
generated when the INVITE is sent, and the first to-tag that is
received causes that DSM to transition into the other states.

Later new to-tags cause the generation of new DSMs in much the same
way that the first DSM is generated.  But since new DSMs are generated
by responses with tags, they start in the Early, Confirmed, or
Terminated state, never the Preparative state.

* Figure 1:  There seem to be missing cases:  BYE(r) will transition
from Early and Confirmed to Mortal.

* The handling of ACK is more complicated than is shown here.  For
instance, if BYE is sent or received in Moratorium state, the dialog
goes to Mortal state, but it must still send ACK.  

For example, see the figure in section 3.1.6.  The UAC in Mortal state
receives 200 for an INVITE, and must re-send ACK.  Neither the receive
nor the send are shown as possible in Figure 1.

Might it be better to consider ACK part of the INVITE transaction
(despite that it has a different CSeq number), and leave sending the
ACK to the INVITE transaction state machine, rather than having the
DSM send it?

* In the state diagrams, I think it would be easier to understand the
designations of the states if they were placed below the message
send/receive that causes the transition into the state.  This is
because the UA is in that state for a period of time, rather than at a
particular moment, and placing the label below the message shows that
the state continues downward until the next state.

For example, change this:

  State  Alice                               Bob  State
         |                                     |
         |            ini-INVITE F1            |
    Pre  |------------------------------------>|  Pre
         |         180 F2(Packet loss)         |
         |            x<-----------------------|  Ear
         |                                     |
         | ini-INVITE(=F1) F4           200 F3 |
         |------------------     --------------|  Mora
         |                   \ /               |
         |                    X                |
         |                   / \               |
   Mora  |<-----------------     ------------->|  *race*
         |                ACK F5               |
    Est  |------------------------------------>|  Est
         |                                     |
         |                                     |

into this:

  State  Alice                               Bob  State
         |                                     |
         |            ini-INVITE F1            |
         |------------------------------------>|  
    Pre  |         180 F2(Packet loss)         |  Pre 
         |            x<-----------------------|        
         |                                     |  Ear 
         | ini-INVITE(=F1) F4           200 F3 |        
         |------------------     --------------|        
         |                   \ /               |  Mora
         |                    X                |      
         |                   / \               |
         |<-----------------     ------------->|  *race*
   Mora  |                ACK F5               |
         |------------------------------------>|  
    Est  |                                     |  Est
         |                                     |

In section 3.1.6:

* The phrase "Alice may want to start a session again" does not
seem to correspond with the rest of the paragraph.

In Appendix A:

* The figure is hard to read because the responses aren't labeled to
show which requests they are from.  This version is easier to read:

Appendix A - BYE on the Early Dialog

   This section, related to Section 3.1.3, explains why BYE is not
   recommended in the Early state, illustrating the case in which BYE
   in the Early dialog triggers confusion.

   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,INV) F14    |<-------------------------------|
     |<--------------------|                                |
     |   ACK(2) F15        |                                |
     |-------------------->|            ACK(2) F16          |
     |                     |------------------------------->|
     |   BYE(2) F17        |                                |
     |-------------------->|            BYE(2) F18          |
     |                     |------------------------------->|
     |                     |            200(2,BYE) F19      |
     |   200(2,BYE) F20    |<-------------------------------|
     |<--------------------|                                |
     |                     |                                |
     |                     |                                |

In Appendix B:

* It is always possible for a re-sent request to receive a 500 (Out Of
Order) response if the recipient has already processed a later
request.  So this sentence:

   UAS's TU sends an appropriate error response (probably 481) for F4
   INVITE, because the TU knows that the dialog which matches to the
   INVITE is in the Terminated state.

should be revised to:

   UAS's TU sends an appropriate error response for F4 INVITE, either
   481 (because the TU knows that the dialog which matches to the
   INVITE is in the Terminated state) or 500 (because the re-sent F4
   has an out-of-order CSeq).

** Editorial

"s.b." = "should be".  Quoted words in [brackets] are shown for
context.

In Table of Contents:

* Section 3 s.b. titled "Race conditions".

* Section 3.3 s.b. titled "Other race conditions".

* Section 3.3.1 s.b. titled "Re-INVITE crossover".

In section 2:

* "[some internal states] showed [in the FSM]" s.b. "shown".

* Figures 1 and 2 are not put entirely on their own pages with their
own captions.  Page breaks should be added to force alignment.

* The caption for Figure 1 ("Figure 1 represents ... dialog usage.")
is not separated from the following paragraph ("UAC MAY send a BYE in
the early state...")

* "[the Early dialog] between [a particular UA]" s.b. "with".

* Line 50 of page 8 contains non-ASCII characters:  "[information
about]??[the dialog which is being terminated]".

In section 3.1.6:

* Near the top of page 22, "BYE request at the same time.  Depending
on the implementation" looks like there might be a paragraph break
intended between the two sentences.

In Appendix C:

* It would be clearer to revise this sentence:

   (Note that, from the point of UAC's behavior, it can be expected
   that UAS receives BYE immediately after the reception of CANCEL and
   moves to the Terminated state.  However, the UAS's state does not
   transit until it actually receives BYE.)

to:

   (Note that, because of UAC's behavior, a UAS that receives a CANCEL
   in the Confirmed state can expect to receive a BYE immediately and
   move to the Terminated state.  However, the UAS's state does not
   transit until it actually receives BYE.)

In Appendix D:

* "[However, the ACK for 2xx and] the one [for error responses are
both a part of the INVITE transaction, even though their] hadlings
differ" s.b "the ACK" and "handling differs".

In Acknowledgment:

* "[for] the [comments on this document]" s.b. "their".
----------------------------------------------------------------------

_______________________________________________
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