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

From: Miki HASEBE <[email-masked]>
Date: Thu, 18 Jan 2007 18:59:22 +0900

Thank you for your many usuful comments.
I apologize for late reply.
My opinions inline.

[email-masked] wrote:

> 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.

I agree that the draft has to be clear about what you pointed out.
The figure does not show the exact behavior when a response to
INVITE with a different To-tag is received in forking.

Below is how I understand your point.

For example, multiple early dialogs are established when responses
with different To-tag (here, A, B, and C) are received.
If a 2xx response with the To-tag B is received, only the early dialog
related to the tag B moves to the Confirmed state.
The other early dialogs, related to the tags A and C, are terminated
in 64*T1 after the reception of the 2xx with the tag B.

In sum, I have to describe the influence on the INVITE transaction
to state the exact behavior of mulitple early dialogs in forking.

Also, if a 2xx response with another To-tag is received in 64*T1
after the reception of the 2xx with the first tag, the early dialog
related to the second tag also moves to the Confirmed state,
resulting in the establishment of multiple confirmed dialogs.
A UAC usually does not receive multiple 2xx responses like this,
because a proxy which forked send CANCEL after it receives
a 200 response.
However, if there is a crossover of CANCEL and 2xx between the
forking proxy and a UAS, the reception of multiple 2xx with
different To-tags can happen.

The behavior of UAC in this case will be an implementational matter,
but I think the UAC will usually terminate by BYE as in CANCEL
crossover (Section 3.1.2).

I think it is difficult to include the forking case in one figure because
the handling of the dialog in forking is complicated.
Threrefore I may address this issue by adding another appendix for
the behavior in forking if necessary.
I will post to SIPPING ML about this, so I hope you could wait for that.

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

As you pointed out, the state moves to the Mortal state
after receiving BYE.
But, Figure 1 and 2 are not for the caller (e.g. Alice) and
callee (e.g. Bob), but generalized for UAC and UAS.
Therefore, Figure 2 has to be checked, instead of Figure 1,
to know the state transition upon the reception of BYE in
for example, the Early and Confirmed state.

The reason for making two figures is as follows.
A UAC is a caller when sending an INVITE request, but
this combination is invalid from the Confirmed state and
after. This would require different figures for all combinations,
caller+UAC, caller+UAS and so on, making figures more
complicated. Therefore, the figures are generalized for UAC
and UAS to simplify the figures.

So, Figure 2 has to be referred to know the behavior of UAS
upon the reception of BYE in the Confirmed state, regardless
of caller or callee.

> * 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?

Your point is absolutely right.
ACK can be sent in the Mortal state.
Care is needed for the ACK for 200 because it is generated
as a new request, but this is related to the INVITE three-way
handshake.
This is not expressed in the figure, but its handling is detailed
in Appendix D.

ACK is not expressed in the figure simply because it does not
involve in the dialog state transition.
Other messages which are not related to the state transition,
e.g. re-INVITE and UPDATE in the Confirmed state, are also
not illustrated in the figure.
This does not mean that it is banned to send messages which
are not in the figure. It just tries to omit the unrelated messages
for simplification.

I would like to handle this issue by adding some text to explain
this as above.
Do you think it is agreeable?

> * 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
>          |                                     |

Thank you for your suggestion.
I will revise the picture according to your idea.

> 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.

This is a mistake.
The correct sentence is "Alice may start a session again".

> 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    |<-------------------------------|
>      |<--------------------|                                |
>      |                     |                                |
>      |                     |                                |

Thank you for your suggestion.
I will reflect this in the next version of the draft.

> 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).

I think it is correct to respond with 500 when Cseq is
out of order.
I will correct the text.
I think there is no dialog for outwardly in the Mortal state,
but dialog is still being managed internally. Therefore I assume
it is possible to respond 500 after checking the Cseq which is
related to a dialog.

> ** Editorial

I appreciate for pointing them out.
I will take care of them in the next version.

Again, thank you for your many poductive comments.

Thank you
Miki,

> "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

_______________________________________________
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