Subject: [Sipping] Re: draft-hasebe-sipping-exceptional-procedure-example-03

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Mar 2006 11:29:22 -0500

Miki,

I reviewed this document. It is a very valuable piece of work, and it is 
much improved from the last version. This is a difficult subject to 
present in a way that people can understand.

Here are some notes I took as I was going through the draft.

	Paul

Regarding Figure 1:

- I know this is intended to be similar to, but more complete than, the 
corresponding diagram used by the dialog event package. That diagram 
covers both the UAC and UAS, and is neutral about whether a transition 
means the sending or receipt of a message. In some cases it doesn't 
matter. But for some of the details you are trying to cover it does 
matter. It might be helpful to add to the label of each transition an 
indication of whether it is the sending or receipt of the message, or 
both. (Both could be the default.) Or perhaps for your purposes it would 
be clearer to have different elaborations of the diagram for the UAC and 
UAS.

- your diagram deviates from the one on dialog event package in some 
ways that I don't think you intend. These confused me. First, you don't 
mention CANCEL at all. And second, the 1xx transition from Early and the 
2xx transition from Moratorium don't mention that they create a new 
state machine. I had to go back to RFC4235 to figure out what those 
transitions were about.

- I think a transition is missing on 2xx from Established - creating a 
new state machine and another dialog.

- I believe some messages can be received while in the Morgue state, but 
all would leave the state unchanged. For instance a UAS could get into 
the Morgue state by sending a 4xx and still receive an UPDATE.

- I was expecting to see CANCEL as a transition in the diagram, but I 
don't. Is there a reason?

- the Mortal state is entered on BYE, but has an internal BYE transision 
as well. I think this can only happen if one is sent and the other is 
received. Is that the intent? Its not clear.

- I don't see UPDATE anywhere. Seems like it should be mentioned.

- how does this diagram apply to reINVITE? For instance, once 
established, it is possible to send or receive a reINVITE, and then send 
or receive a BYE before the reINVITE has completed. That is another kind 
of "race" condition that might be useful to clarify.

Regarding notes on the dialog states:

- Proceeding: the text says a CANCEL may be sent. But the diagram shows 
no CANCEL transitions.

- Early: says "UAC may send CANCEL in Proceeding state". Perhaps this is 
a type and should say "... Early state"??? I think there should be a 
transition from this state on CANCEL.

Section 3:

- I don't understand why the paragraph beginning "In case that CANCEL" 
is here. It seems out of place. Perhaps it was intended to be part of 
one of the state descriptions above.

Section 3.1.1:

It might be helpful to note that for messages F3 and F4 Alice and Bob 
are in inconsistent states.

Section 3.1.3:

I was trying to follow the changing dialog statea of alice and bob 
through this flow and relate it to the messages. But it wasn't entirely 
clear to me. Mostly it is the impact of CANCEL that isn't clear. I think 
it is natural to want to use the state diagram as a guide to 
understanding the flows, so it might be good to help the reader out by 
mentioning the states during the discussion of the flow. (In all the 
examples.)

Section 3.1.4:

Is it really true that an ACK is not to be sent in this case? (I was 
thinking it should be, but I don't understand the details of this and am 
willing to trust you on it.)

Section 3.1.5:

Is F6 really a reINVITE? Isn't it a retransmission of F1? or is it 
technically a reINVITE because F3 ended the transaction for F1? Isn't it 
supposed to trigger a retransmission of F4 rather than sending a fresh 
ACK? (Again this is something I don't know well, so I am asking to be 
educated.)

Section 3.2.1:

I can't quite understand what the following sentence is trying to tell 
me: "As shown in section 2, UA remains in Mortal state after sending a 
BYE until sending a BYE to actually terminating the dialog."

Later in the same paragraph is "UAs in Mortal state return error 
responses to the requests that operate dialog or session, such as 
re-INVITE, or REFER. Exception is a BYE message. UA shall return 200 OK 
to the BYE because it can give the dialog in Mortal State a finishing 
stroke and send it to the Morgue." This seems to cover valid cases as 
well as invalid ones. If Mortal state was entered by *receiving* a BYE, 
the receiving another BYE is an error. (Though there may be nothing 
better to do in that case than ignore it.) Seems like the basic rule is 
that its always ok to receive *one* BYE, but receiving more is 
erroneous. (Its hard to show that in a state machine - need to introduce 
another state. Maybe its sufficient to mention in the text.

Section 3.2.3:

I am afraid this example brings up the ugly issue of dialog usages. I 
know you wanted to stay away from that subject, so we should discuss the 
extent to which we can.

Your state machine is really for an invite dialog usage, not a dialog. 
In the current example, you say (in comment to F6): "Bob sends a REFER 
on the INVITE dialog. The state of dialog transits to Mortal state at 
the moment Alice sends a BYE..."

This is at least a little misleading. There are multiple things going on 
here:
- the REFER is sent sharing the dialog with the invite dialog usage
- the REFER implicitly *references* the invite dialog usage. The
   implication is that the resulting INVITE should replace that usage.
- the 481 response has been designed in a way that is overloaded.
   It could actually arise in two ways from this request:
   - the dialog itself could be gone, and so the refer that is
     trying to use it is rejected
   - the invite dialog usage that is implicitly referenced is gone,
     and the REFER is then rejected because of that.

A dialog can't go away until all its usages have gotten to a state where 
they no longer depend on the dialog. The invite dialog usage will have 
to be in the Morgue before the dialog can go away. (If it went away in 
the Mortal state the BYE couldn't be received.) So I think in this case 
the dialog will still be present when the REFER is received, so that 
can't be the reason for the 481. Instead, the 481 occurs for the second 
reason I listed above - for the same reason that messages that belong in 
the invite dialog usage (like UPDATE) are rejected while in the Mortal 
state.

Note that the same failure would occur if the REFER were send 
out-of-dialog and contained the new Target-Dialog header to reference 
the call to be replaced. (But this does point up a problem with 
Target-Dialog that I hadn't considered before. The REFER needs to 
identify a target dialog usage, but Target-Dialog only identifies the 
dialog. The processing of REFER must figure out that an INVITE is to be 
generated and so it is the invite dialog usage that is of interest.)

I am not certain how best to change this so it is not confusing or 
misleading and yet avoid deep involvement in the dialog usage discussion.

Section 3.2.4: I think there is something subtley wrong here. Suppose 
that the BYE (F6) was lost. In that case, Alice would keep 
retransmitting F7, expecting an ACK. As a result, I think it must be the 
receipt of F8 rather than the sending of F6 that causes bob to supress 
the sending of ACKs. If so, then since F7 is received before F8, I would 
expect to see an ACK sent.

Section 3.3.1:

I think you imply that after receiving F18 Alice should terminate the 
early dialog with Bob. In this case that is indeed the correct thing to 
do. But suppose the cancel had failed. It is possible that sometime 
after F18 Bob will return a 200 response. Alice must be prepared for 
that. It is likely that Alice would then just send a BYE to Bob. But 
that is not required - e.g. when there are multiple 2xx responses Alice 
could conference them all together. So Alice may not want to terminate 
early dialogs until enough time has passed that the invite transaction 
would have timed out.

Section 3.3.3: This seems fine. But it might be worth a note that Bob 
must not blindly retransmit F6 as F14. The changes resulting from 
F11-F13 most likely will impact what should be included in F14, and may 
well entirely eliminate the need for F14.

----------

That is all I have.

Thanks again.
Paul

Miki HASEBE wrote:
> Hi Dean,
> Hi Paul,
> Hi James,
> 
> Thank you very much for your sparing time,
> and I am looking forward to meeting you at Dallas.
> 
> I posted the new draft to sipping list,
> would you please take a look at the draft?
> I drastically update the draft based on the comment
> gotten from you last meeting.
> Although I know that you are busy,
> I am very glad if you will give me comments.
> 
> I will have a presentation in sipping-WG this time.
> Would you please help me at the presentation in sipping?
> Since I am not so good at English,
> it may be difficult to understand questions in detail.
> It would be very helpful if you could follow up during
> the question and answer period.
> 
> Best regards,
> Miki Hasebe
> 
> Jun KOSHIKO <[email-masked]> wrote:
> 
> 
>>Hi Dean,
>>Hi Paul,
>>Hi James,
>>
>>Thank you very much for your sparing time.
>>It's OK for us to have a meeting in the room to be used for ECRIT.
>>
>>  Meeting Time        3/21 (Tue)  08:00-09:00
>>  Meeting Place       the room to be used for the ECRIT session
>>
>>Mr. Hasebe will wait for you in front of the room at the time.
>>
>>Thank you very much for your help.
>>Regards,
>>Jun Koshiko from NTT-East
>>
>>
>>>Jun Koshiko
>>>
>>>I can make this time for a meeting as well.
>>>
>>>Thank you for arranging this.
>>>
>>>As Paul said, I will assume this meeting is in the room to be used for the 
>>>ECRIT session unless I receive notification it is somewhere else.
>>>
>>>/James
>>>
>>>At 05:43 PM 3/7/2006 +0900, Jun KOSHIKO wrote:
>>>
>>>>Hi Dean,
>>>>
>>>>Thank you for your sparing time.
>>>>
>>>>0800-0900 on Tuesday before ECRIT is best for us.
>>>>If you can make it, I would like to fix it.
>>>>
>>>>I'm also arranging a meeting with your Cisco collegues, James and
>>>>Paul, and they told me that it is better to have a meeting with you.
>>>>If you don't mind, I would like to merge two meetings.
>>>>
>>>>At the meeting, two other members from NTT Lab., Mr. Sakaya and
>>>>Ms. Munakata will come to the meeting.
>>>>
>>>>Thank you for your support in advance in Dallas.
>>>>
>>>>Regards,
>>>>Jun Koshiko
>>>>
>>>>
>>>>>Tuesday, as you note, is very busy with SIP-related activity. I'm
>>>>>afraid there's an IETF-OMA liaison meeting already scheduled for the
>>>>>lunch break.
>>>>>
>>>>>It would be possible for me to meet before ECRIT at perhaps 0800, and
>>>>>it would be possible to meet in the evening.
>>>>>
>>>>>I understand that Miki Hasebe might also wish to meet with my
>>>>>colleague Paul Kyzivat.
>>>>>
>>>>>Perhaps we could combine both meetings into Tuesday evening? I would
>>>>>be pleased to make dinner arrangements for a small group. I actually
>>>>>live in the Dallas area, so I know a few places.
>>>>>
>>>>>Another option might be around 1700 on Monday, which I think would
>>>>>overlap the last few minutes of SPEERMINT and the following break.
>>>>>
>>>>>--
>>>>>Dean Willis
>>>>>
>>>>>
>>>>>On Mar 5, 2006, at 7:48 PM, Jun KOSHIKO wrote:
>>>>>
>>>>>
>>>>>>Hi Dean,
>>>>>>
>>>>>>As I told in the previous mail, I would like to adjust a meeting
>>>>>>time to discuss race condition examples draft. If possible,
>>>>>>I would like you to meet him on Tuesday, because the SIPPING
>>>>>>meeting is held on Wednesday.
>>>>>>
>>>>>>I would like you kindly to spare time to have a meeting with him.
>>>>>>
>>>>>>I guess lunch time, morning, or night time would be good for the
>>>>>>meeting, because Tuesday is filled with SIP-related meetings.
>>>>>>The following is the list of candidates.
>>>>>>
>>>>>>March 21 (Tue)
>>>>>>  0700-0800
>>>>>>  0800-0900
>>>>>>  1130-1300
>>>>>>  2000-2100
>>>>>>  2100-2200
>>>>>>
>>>>>>Please let me know when would be a good time for you.
>>>>>>
>>>>>>Thank you very much.
>>>>>>
>>>>>>Regards,
>>>>>>Jun Koshiko from NTT-East
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Jun KOSHIKO wrote:
>>>>>>>
>>>>>>>>Hi Dean,
>>>>>>>>
>>>>>>>>I'm Jun Koshiko from NTT-east, Japan.
>>>>>>>>
>>>>>>>>Thank you for your help in the past IETF meetings.
>>>>>>>
>>>>>>>You're very welcome. I have enjoyed meeting with you.
>>>>>>>
>>>>>>>
>>>>>>>>My collegue Miki Hasebe is going to attend IETF Dallas meeting,
>>>>>>>>and I would be grateful for your support to him.
>>>>>>>>(I'll not come to the meeting this time.)
>>>>>>>
>>>>>>>I'll look forward to talking with Miki Hasebe at the Dallas
>>>>>>>meeting, and
>>>>>>>hope to see you at a future meeting.
>>>>>>>
>>>>>>>
>>>>>>>>He is the main author of the Race Condition Example draft.
>>>>>>>>He'll submit an updated draft and start discussion on the
>>>>>>>>mailing list at some early date, and I hope you'll kindly
>>>>>>>>take time to discuss with him about proceeding of the draft in
>>>>>>>>Dallas.
>>>>>>>
>>>>>>>That's good news.
>>>>>>>
>>>>>>>
>>>>>>>>I hope you'll talk about the topic of "the VPN session
>>>>>>>>establishment by SIP" with him in Dallas, too.
>>>>>>>
>>>>>>>Yes, that is a very interesting topic. Very controversial, also. Many
>>>>>>>people wrote to me about it after the on-list discussion with wildly
>>>>>>>varying opinions on whether the supporters were insane or geniuses
>>>>>>>(or
>>>>>>>perhaps both) for considering it. I still believe I see substantial
>>>>>>>value in the concept for certain applications, and would be happy to
>>>>>>>discuss it.
>>>>>>>
>>>>>>>--
>>>>>>>Dean Willis
>>>>>>
>>>>>>---------------------------------------------------------
>>>>>>Jun KOSHIKO
>>>>>>Next Generation Strategy
>>>>>>Research and Development Center
>>>>>>NTT-east Corporation
>>>>>>
>>>>>>Telephone  +81 3 5359 5104
>>>>>>Facsimile  +81 3 5359 1236
>>>>>>E-mail: [email-masked]
>>>>>>19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
>>>>>>---------------------------------------------------------
>>>>>>
>>>>
>>>>---------------------------------------------------------
>>>>Jun KOSHIKO
>>>>Next Generation Strategy
>>>>Research and Development Center
>>>>NTT-east Corporation
>>>>
>>>>Telephone  +81 3 5359 5104
>>>>Facsimile  +81 3 5359 1236
>>>>E-mail: [email-masked]
>>>>19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
>>>>---------------------------------------------------------
>>
>>---------------------------------------------------------
>>Jun KOSHIKO
>>Next Generation Strategy
>>Research and Development Center
>>NTT-east Corporation
>>
>>Telephone  +81 3 5359 5104
>>Facsimile  +81 3 5359 1236
>>E-mail: [email-masked]
>>19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
>>---------------------------------------------------------
> 
> ---------------------------------------------------------
> Miki HASEBE
> Research and Development Center
> NTT-east Corporation
> 
> Telephone  +81 3 5359 5104
> Facsimile  +81 3 5359 1236
> E-mail: [email-masked]
> 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
> ---------------------------------------------------------
> 

_______________________________________________
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