Draft:  draft-ietf-sipping-race-examples-01
Reviewer: Anders Kristensen [andersk@cisco.com]
Review Date: 5/23/2007
Review Deadline: 5/14/2007
Status: WGLC  

Summary: This draft is on the right track but has open issues, described in the review. 

Comments:
----------
1) Fig 1: New 2xx's (2xx with previously unseen To tag) can also be 
received after ACK for the first 2xx has been sent.

2) Fig 1: According to the caption, the BYE transition from Confirmed to 
Mortal is for outgoing BYEs only. Should be for either incoming or outgoing.

3) Fig 2: The 2xx event in the Moratorium state is for retransmissions? 
I don't think 2xx retranmissions are relevant for this FSM and I would 
suggest removing the transition. The diagram (rightly) doesn't show 
other message retransmissions.

4) The text in 3.1.4 makes it sounds as if 491 could be used instead of 
200 in this flow:

    As it can be seen in Section 3.3.2
    below, the 491 response seems to be closely related to session
    establishment, even in cases other than INVITE cross-over.  This
    example recommends 200 be sent instead of 491 because it does not
    have influence on session.  However, a 491 response can also lead to
    the same outcome, so the either response can be used.

There's a disclaimer earlier in the section but even so this text is 
misleading.

5) Section 3.3.3: why single out REFER? All other requests received in 
the Mortal state result in 481 too, right?

6) Appendix A:

    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.

I don't think it triggers confusion. The behavior is, I believe, well 
defined and the example call flow is valid, no? I don't particularly 
think the draft needs to advise against sending BYEs in this situation.

7) Appendix C:

    Similarly, the Expires header does not have direct influence on the
    dialog state transition, but it indirectly affect the state
    transition because its expiration triggers the sending of CANCEL.

Do you mean in the UAC or proxy? The UAC presumably knows without 
inspecting its own INVITE when to CANCEL. According to 3261, sec 16.10 
its optional for proxies to cancel based on Expires:

    A stateful proxy MAY generate CANCEL requests for pending INVITE
    client transactions based on the period specified in the INVITE's
    Expires header field elapsing.

8) Appendix E: It's up to the UAC whether to terminate dialogs 
established by second and subsequent 2xx. The text makes it sound as if 
it's mandatory.

Some general comments:

9) I wonder whether the doc really needs to get into explaining SIP 
dialog behavior in quite so much detail. Isn't that done well enough 
elsewhere?

10) The "Message Details" seems overly, well, detailed. I think the 
flows can be understood with less verbosity.

11) Since the draft is in WGLC I'll mention that the document would 
benefit from some overall anglicization.