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

From: Anders Kristensen <[email-masked]>
Date: Wed, 23 May 2007 21:47:16 -0700

Some comments on the draft...

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.

Thanks,
Anders

_______________________________________________
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: Jun KOSHIKO <[email-masked]>
Date: Wed, 30 May 2007 13:43:03 +0900

Thank you for your comments.
Sorry for the late reply.

Inline.

> Mortal is for outgoing BYEs only. Should be for either incoming or outgoing.

I agree. They are to be corrected.
Please see the new Figure 1 shown in the reply to Dale's review.

> other message retransmissions.

I will add a text about retransmission you pointed out.
I'll apply policy that I wrote in the return email to Dale's comments.
So, the figures include retransmissions by dialog (UA Core) but 
do NOT include retransmissions on the transaction level
in both cases UAS (Callee) and UAC (Caller).

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

After the discussion of 491 in sipping list, I would like to reflect the
result to the description of 491 in the draft.

> the Mortal state result in 481 too, right?

Right.
It need not be REFER because other methods except BYE give the same result. 
I think that REFER is more appropriate as an example
which shows dialog state than other methods,
because whether REFER functions well or not is concerned
on dialog state. (REFER is used with draft of the dialog-usage.)

> think the draft needs to advise against sending BYEs in this situation.

There is no problem at all when UA is completely understood that
the meaning of sending BYE on the Early state. "the meaning of sending
BYE" is that BYE terminates one selected To-tag (that is, Dialog).
On the other hand, CANCEL method means that it cancels all the things
requested by INVITE. Therefore, results may differ if an intermediate
forks the request. Behavior which ends dialog alternatively in the Early
state is not common, so we made it NOT RECOMMENDED.

>     Expires header field elapsing.

An Expires header serves as an opportunity of CANCEL transmission for
UAC and Proxy. However, it is not different from the process of the
usual CANCEL, and there's nothing new. For UAS, although it becomes
an opportunity of 487, this is not different from the Dialog termination
process by the usual error. The Dialog state is not influenced directly,
so the notes about Expires may be deleted. 

> established by second and subsequent 2xx. The text makes it sound as if 

I'll add an additional explanation, because it lacks explanation.

It was felt that the sending of BYE should be emphasized because that is
what is likely to be appropriate in many common cases, and is important
for those who otherwise might forget to anticipate this case at all. But
there should be a note somewhere that it is perfectly ok to accept these
additional dialogs if the UAC thinks that makes sense for what it is
doing.

> dialog behavior in quite so much detail. Isn't that done well enough 

There may be exceptions, but this document has been shaped by things 
people ask about. If having it here helps somebody then I would rather 
leave it. (Unless it is wrong.)

> flows can be understood with less verbosity.

The level of detail has been the subject of much discussion in prior 
versions. In some cases we felt it was necessary to provide more detail 
than what is present in the single one-line summaries. (Tags, callids, 
etc.) We discussed trimming all the irrelevant lines out of the 
messages. But there is another guideline that if messages are included 
they should be "correct". (Because too many implementors have a habit of 
coding from the examples.) So what you see is the compromise. I agree 
that much of the detail is irrelevant to the document.

I was contemplating if we would be better to come up with a slightly 
more complete summary format (two lines?) that includes all the relevant 
info and yet doesn't look like an actual message. Another suggestion was 
to simply include a disclaimer explaining why it is this way.

What do you think?

> benefit from some overall anglicization.

I expect that if we don't do it the RFC Editor will.
It would be good if it's readable and comprehensible.

> Anders

Thanks,
Jun

-------------------------------------------------
Jun KOSHIKO

Next Generation Network Strategy
Research and Development Center
NTT East Corporation

Telehone   +81 3 5359 5104
Facsimille +81 3 5359 1236
E-mail: j.koshiko at east.ntt.co.jp
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
-------------------------------------------------